<!-- md twin of ai-agent-audit-trail (machine-readable, generated 2026-09-19) -->

Audit trail · PG-17


# What did your agent do? A trail that proves it

Proposal, approval, posting: every agent action on the ledger is an attributable event — who, when, where — with an export your auditor can check independently.

An agent audit trail is the record of what an AI agent did inside a financial system: which agent, acting under which credential and delegating principal, proposed, edited, submitted or was refused what, and when. In Ledgerbook, every commit — material or micro — emits an event carrying who/when/where, and writes move through a proposal → approval → posting ladder where approvals are bound to a content hash and any edit voids them. Agents can propose but cannot approve, finalize or correct. The trail exports as OCEL 2.1 JSON that loads in independently runnable verifiers, so an auditor can check it without ledger access.

Verified 2026-09-19 · provenance envelope PH-1 · full agent-actor registry Roadmap (PH-2)


## The write path an agent actually gets

Governance first: the audit trail is only as good as the gate in front of it.

- **Scoped, per-tool credentials.** A credential resolves to a scope set, and every allow/deny decision is itself a provenance event. Read and propose are grants; approve, post and correct are not available to agents at all. FR-800/801/803/220 · PH-1

- **Proposals, not posts.** Agent writes land as provisional entries with full provenance. Nothing reaches the books until policy approves and finalization runs.

- **Approvals are hash-bound.** An approval names the entry revision and content hash it decides on — and any material edit voids it, returning the entry to provisional. An approval cannot be reused across revisions. FR-215/216 · PH-1

- **Materiality tiers T0/T1.** Tier is computed server-side from stored policy — source, actor kind, document type, amount, account class, period state — and stamped on the entry with its inputs. T2/T3 and auto-reversal accruals are ◇ Roadmap. FR-217–219 · PH-1 T0/T1

- **No write path is exempt.** Batch, streaming, connector and MCP writes all pass through the same append path; missing provenance is a hard failure, and no event defaults to a system actor. FR-234/146 · PH-1


## A trail, step by step

An illustrative fixture — an agent proposes an accrual, policy wraps it, and a later reversal keeps the record whole. Times and ids are examples, not customer data.

- **Agent proposes** 2026-09-18 09:14:02Z · seq 18431 actor: agent · credential "close-bot-7" (hashed) · on_behalf_of: controller@acme · model id recorded · event entry.proposed. The entry lands provisional; the proposal carries a content hash.

- **Tier evaluated, approval requested** 09:14:03Z · seq 18432 Tier T1 computed from stored policy and stamped with its inputs; approval request bound to (entry, revision, content hash). FR-215/217 · PH-1

- **Human approves; entry finalizes** 2026-09-18 10:02:41Z · seq 18439 Approver ≠ creator. Finalization is transactional and one-way: the entry gains its chain hash and the books move. Event entry.finalized, attributed to the approver, with the agent as attributed_to. FR-211/205 · PH-1

- **Later correction, as a new entry** 2026-09-30 16:20:07Z · seq 19704 A typed reversal — never an edit. The original stays Final and independently verifiable; the trail shows original → correction with both sides attributable. FR-123–125/205 · PH-1

**Export and verify.** The same window exports as OCEL 2.1 JSON; a verifier recomputes the chain and the balances from the export alone — no ledger access, no vendor trust. See [Provenance &amp; OCEL 2.1](/provenance-ocel2) and [Immutable ledger](/immutable-ledger#verify). Bundled export formats and packaged evidence sets are ◇ Roadmap. FR-905 (JSON) · FR-121/813 · PH-1


## Agent audit FAQ

Read the provenance trail. Each ledger event names the actor — human, agent or system — plus identity, hashed credential id and the delegating principal, with server-assigned time and sequence. Proposals, approvals, finalizations and refusals are all events on the same append path, so an auditor can reconstruct exactly what an agent proposed and what policy did with it.

No. Agent credentials carry propose and read scopes, and approval, posting, correction and restatement scopes cannot be granted to actor kind agent. Creator ≠ approver holds for agent-originated entries in all cases, and blocked attempts fail closed and are recorded as events. Enforced at the credential, not just instruction.

OCEL 2.1 JSON of the event and object history, scope-filtered, reproducible, and carrying who/when/where per event. It validates against the standard's schemas in CI and can be loaded by an independent verifier. Bundled export formats and packaged evidence sets arrive in PH-2 and are labelled Roadmap.

Yes. The MCP read/propose surface runs inside the deployment with the same semantics and error taxonomy as HTTP, so agents reach the ledger through a local model with zero egress. Provenance capture and OCEL 2.1 export are part of the core, not a cloud service — the audit trail never depends on a network path.


## Show your auditors the trail, not a promise

Design partners get the governance walkthrough: credentials, tiers, the fixture trail and the export.
