The short answer
What makes an agent audit trail real
An agent audit trail is the ordered, checkable record of what an agent did and produced. It only does its job if four things hold: it is saved as the work runs, not written up afterward; it is held outside the agent's own workspace and access; each step carries a verifiable receipt anyone can recompute; and the steps sit in a sequence, so a missing step shows as a gap. A log the agent keeps about itself fails the second test on day one, and the other three with it.
The failure mode: the agent is the keeper of its own record
Most agent setups record work the convenient way. The framework writes a log file, the agent summarizes its session into its own memory, the console keeps a history tab. All three live where the agent works. That placement fails in three ordinary ways, none of them exotic:
- The agent can delete it. An agent with file or shell access can remove its own logs, sometimes because it was told to clean up, sometimes because a long session prunes its own context. The record is gone exactly when a step goes wrong and the housekeeping runs.
- The agent can rewrite it. A summary written at the end of a session is the agent's account of itself. Steps that failed quietly get smoothed over, not out of malice but because summarization drops what did not matter to the summary. An edit leaves no mark in a plain log.
- Nobody else can check it. The log sits in the operator's console or workspace. A client, an auditor, or a teammate cannot open it, and if they could, they would have no way to confirm it was not adjusted before they saw it.
None of this needs a dishonest agent. It needs only a normal one, a long job, and a question asked a week later. If your setup has this shape, the companion page on agents deleting their own logs walks through the incident version of the same problem.
The four properties a trail outside the agent's reach has
- Saved at run time. Each step is recorded when it happens, by the layer that ran it, with the tool, the inputs, the saved result, and the time. Nothing is reconstructed from notes afterward.
- Held by someone else. The record lives with a separate service, not in the agent's workspace. The agent can add steps by doing work. It cannot reach back and adjust steps that already closed.
- Checkable by a stranger. Every step carries a verifiable receipt: the exact saved bytes and their SHA-256 digest, in the open AER-1 format (draft-zambo-aer1-26), so anyone with the link can recompute the check without an account and without trusting the operator.
- Ordered, with visible gaps. Steps sit in a sequence under the job. A step that never got recorded shows as a break in the order, which is information a flat log file never gives you.
Stated exactly: a receipt proves the saved result was not changed since it was saved. It does not prove the result was right. The trail gives the checker a record that holds still while they judge the work, instead of a story they have to trust.
How to set one up
- Add the record layer. Point your agent at the Zambo MCP endpoint, https://zambo.dev/mcp. It works with the agent you already run: Claude, ChatGPT, Gemini, Cursor, Grok, and other MCP clients. Setup is one step at zambo.dev/add.
- Run the work. Every call through the endpoint leaves a verifiable AER-1 receipt as it runs, including calls that fail or get refused, and the receipts gather under the job in order. That growing record is the audit trail. Zambo is the verifiable work layer for AI: 153 tools behind the one endpoint, 20 free calls per day, then they upgrade, a $0.99 Day Pass for 24 hours, or the Zambo Pass at $29 for 30 days, one payment.
- Hand the trail over. When the job ends, the trail closes as one record. With HANDOVER, Zambo's handover tool, the trail and the state of the job pass to the client, the auditor, or the next agent as a single link, and anyone holding it can recheck any step at zambo.dev/verify.
What this settles, and what it does not
It settles the record questions: what ran, in what order, with what inputs, what came back, and whether the saved record still matches what was saved. Those are the questions a dispute, a refund fight, or an audit actually turns on, and a self-kept log cannot settle any of them against a skeptic. It does not settle the judgment questions: whether the agent chose well, whether the output was good, whether the job was worth doing. Those stay with the reader, which is where they belong. The full definition, the seven field checklist, and the log versus trail comparison live on the AI agent audit trail page, and the step by step checking flow lives on how to verify AI work.
Questions, answered
What is an agent audit trail?
An agent audit trail is the ordered, checkable record of what an AI agent did and produced on a job. Each step is saved when it runs, with the tool called, the inputs, the saved result, and the time, and each step carries a verifiable receipt a stranger can recompute later. A receipt proves the saved result was not changed since it was saved. It does not prove the work was correct.
My agent can delete its own logs. How do I keep a record it cannot change?
Move the record outside the agent's reach. When the work runs through a separate record layer, each call is saved by that layer as it happens, not written up by the agent afterward. The agent never holds the only copy, so it cannot delete or rewrite the trail without the change showing. On Zambo, every call through the MCP endpoint at https://zambo.dev/mcp leaves a verifiable AER-1 receipt under the job, and anyone with the link can recheck it at zambo.dev/verify with no account.
Where should an agent audit trail live?
Outside the system being audited. A trail that lives in the agent's own workspace, console, or database is controlled by the party the trail is meant to check. A useful trail is held by a separate service, saved at run time, readable by the people who need to check it, and written in an open format, which is why Zambo receipts follow AER-1 (draft-zambo-aer1-26), an open IETF Internet-Draft format anyone can implement a checker for.
Can an agent audit trail prove the agent did good work?
No, and a trail that claims otherwise is overselling. The trail proves what ran, what it returned, and that the saved record was not changed after it was saved. Whether the work was good is a judgment a person makes against that fixed record. The trail's job is to make sure the record they judge is the record that was actually produced.