AI Agent Transparency Log: A Checkable Record of Every Action

Why this matters now

AI agents increasingly act through tool calls: they query prices, send messages, modify files, and invoke services on a principal's behalf. When something later needs checking, the parties involved usually have only vendor-specific logs, screenshots, or the agent's own summary. None of these is portable across implementations, and none lets an independent third party recompute what was recorded.

The accountability pressure is arriving too. Reporting in 2026 has described a California Attorney General subpoena touching agent governance and legal accountability, and AI regulation is steadily adding transparency obligations for automated systems. The question "show me what the agent did" is moving from nice-to-have to compelled. A transparency log is the artifact that answers it.

The three layers of a real transparency log

1. One verifiable receipt per action

The atomic unit is a verifiable execution receipt: a small record for one agent tool call carrying the tool name, the canonical bytes of the result, a SHA-256 output commitment, a timestamp, a provenance class bound inside the receipt hash, and a stable public URL. The open format for this is AER-1 (draft-zambo-aer1-23, an open IETF draft). Each receipt answers one narrow question: what did this system record for this execution?

2. Hash-chained ordering

Individual receipts are not enough; their order must be checkable too. AER-1 defines hash-chained job timelines: each entry's digest binds the sequence number, the job identifier, the receipt identifier, and the output commitment, so relabeling or splicing attacks against the timeline are detectable by recomputation. Multi-step sessions get workflow receipts sealed under a single Merkle root over the step sequence.

3. Public anchoring

The log must survive the operator. Receipts are anchored to public relays with an envelope binding the receipt identifier, the output hash, and the evidence hash. An anchored receipt can be checked by a third party who never trusted the system that produced it. That is what separates a transparency log from a log file.

What the log does and does not prove

A transparency log built this way proves the saved record was not changed: the bytes the system recorded are the bytes you are checking. It does not prove the model was correct about the outside world, and any honest log format says so explicitly. A log that claims to prove correctness is selling something; a log that proves integrity is infrastructure.

The test

Ask of any "agent transparency" product: can an independent third party recompute the record without the vendor's help? If the answer is no, it is a dashboard, not a transparency log.

See it running

Zambo's receipt API emits a verifiable receipt for every tool call, each one retrievable at a public URL and checkable at zambo.dev/verify. Read how the receipt API works, or run the trust checklist against any agent you rely on.

AI agent execution ledger

A ledger is a log with a memory it cannot rewrite. An AI agent execution ledger is the ordered record of an agent's executed calls where each entry is a verifiable receipt and the order itself is committed, so entries cannot be inserted, dropped, or rearranged afterward without breaking the record. That is the difference between a ledger and a log file with good intentions: a log records what its keeper chose to write, while a ledger's entries and sequence are checkable by a receiver who was not there.

The construction is the three layers on this page: one verifiable receipt per action, hash-chained ordering across the run, and public anchoring of the result. Zambo is the verifiable work layer for AI, and its workflow records are exactly this ledger at the scale of one job: every step receipt accounted for, in order, at close. For the per-record checks, see how to verify an AER-1 receipt.

One job's ledger, served live. On October 16, 2026, a three-call run closed as workflow receipt fa512cd8-6af4-4d7c-ae30-174a8bae66e8: entry 0d1b711a (live_price BTC $81,959.00, output digest sha256:4ee6e206ed138866a9cf36c5c42cab4ea90e38b044d514b0b2fd69b8146b3076), entry 6c632066 (live_price ETH $2,451.70, output digest sha256:420db5c7129f84d2f119f037d39397fa07e1202bb9055359977f9d91d97364d7), and entry bab0fb22 (live_price SOL $105.97, output digest sha256:7b67d40bccb9e8c5bd3fd798a296b8ae692ab7bc6ab966c2b6c5969723fff8e3), each verified on the public endpoint, the run closed at 10:22:42 UTC under Merkle root 7939977021a4ee0b2c7e24679609a7b79e1dd14025c57e4d85b23e906b268111. Recomputing that root from the three receipt identifiers under the construction in Section 8.1 of draft-zambo-aer1-20 reproduces it exactly. That is the ledger property at job scale: not that the entries are listed, but that the listing cannot be quietly edited afterward, because the order and completeness the ledger claims are the order and completeness a stranger can derive.

AI agent transparency log

The request that creates the need: someone with a right to ask wants to know what the agent did last week. A client, an auditor, or your own incident review asks, and the honest answer has to come from a record, not from the agent's account of itself. An AI agent transparency log answers that request with an append-only sequence of verifiable receipts that a third party can recompute entry by entry, without an account and without asking the operator to vouch for the log.

Build one by running the work where every call leaves a receipt and the run closes under a workflow record: the receipts fix what each step recorded, the chain fixes the order, and anchoring keeps the record readable after the session ends. Zambo is the instrument: every tool call through zambo.dev/mcp leaves a verifiable receipt, and multi-step jobs close as one ordered record. For $0.99, run one real job under a Day Pass and hand the resulting log to whoever asked: zambo.dev/day-pass. Ongoing use is the Zambo Pass at $29 a month or $290 a year, $19 a month for $ZAMBO holders.

Verifiable agent action log

The problem: the agent acted in the world, and later someone asks for the log of what it did. It sent the message, changed the file, placed the order, called the API. The export you can produce, a dashboard view, a copied activity feed, a screenshot, is a file the operator controls, and a reader who was not there has no way to check whether it was edited on the way out. A verifiable agent action log is the version built for that reader: an ordered record where every action entry is a verifiable receipt, fixed when the action ran, and the order of entries is committed too.

Handing one over changes the conversation. The reader picks the actions that matter, recomputes each entry from its saved result, and walks the sequence for gaps, with no account on your system and no need to take your word for the export. What the log proves is narrow and stated plainly: the saved record of each action was not changed since it was saved. Whether the actions were the right ones is a separate judgment, and it is a judgment the reader can finally make against a record that holds still. The construction is the three layers above: one receipt per action, chained ordering, and anchoring outside the operator's system.

An action log like this exists only if the actions ran where each one leaves a receipt. Zambo is the instrument: every tool call through zambo.dev/mcp leaves a verifiable receipt, and a job closes as one ordered record. For $0.99, run the next job that someone will ask about under a Day Pass and keep its action log: zambo.dev/day-pass. Ongoing use is the Zambo Pass at $29 a month or $290 a year, $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402.

Questions, answered

What is an AI agent transparency log?

An AI agent transparency log is an append-only, ordered record of an AI agent's actions where each entry is a verifiable receipt: the tool that ran, the time, the recorded inputs, and the saved output under a hash commitment computed at execution time. The order of entries is committed too, so an entry cannot be inserted, dropped, or rearranged later without breaking the record. Anyone can recompute the entries and the order without an account on the system that produced them. The log proves the saved record was not changed since it was saved; it does not prove the agent's decisions were correct.

How is an AI agent transparency log different from a normal activity log?

A normal activity log is a file its keeper can edit, export selectively, or lose when a session ends, and a reader has to trust the keeper that nothing was changed. A transparency log is built so the reader does not have to: each entry carries a commitment computed when the action ran, the sequence is chained, and the record is anchored outside the operator's own system. If an entry or the order were altered afterward, recomputation would show it. The check belongs to the reader, not the operator.

What is a verifiable agent action log?

A verifiable agent action log is an ordered record of an AI agent's actions where each entry is a verifiable receipt: the tool that ran, the time, the recorded inputs, and the saved output under a hash commitment computed when the action ran, with the order of entries committed as well. Anyone can recompute an entry and check the sequence without an account on the system that produced the log. An entry that was edited afterward fails its recompute, and a dropped entry shows as a gap. The log proves the saved record was not changed since it was saved; it does not prove the actions were the right ones to take.

AI agent transparency log: a checkable record of every agent action