ZAMBO.

Direct answer

Your agent's audit trail is a story its own system wrote. Here is how to check it.

Open the trail from your last agent run and it reads clean: every step completed, nothing out of place. It would read clean even if the job had gone wrong, because the record was written by the same system that did the work, describing itself, in its own words, stored where its own operator can reach it. That is not an audit trail. It is a story with timestamps. The good news is that you do not need to take anyone's word for which one you have. There is a four point check you can run on any trail, including the one on this page, and it takes about two minutes.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup. Then run the check below on the receipt it gives you.

Updated October 29, 2026. First published October 29, 2026. The record quoted in the check section is real and public, and its verification result was read back from the live service while this page was written.

Three ways an audit trail lies without anyone deciding to lie

Most bad trails are not forged. They are just built in a way that makes them wrong on exactly the runs you needed them for. The first failure is the write-up: the trail is assembled after the run ends, from the agent's own summary of what it did. Steps that failed and were retried appear once, as successes. The hesitation, the wrong turn, the tool that returned junk and got called again, all of it is edited out by the simple act of writing the story afterward. The second failure is summarization: each entry holds a sentence about the step instead of the step. "Processed the invoices" tells you nothing when the dispute is about which invoices, what totals, and what came back. The third failure is reach: the trail lives in a console the operator controls, in a format the operator's tools read. Anyone with access can fix an entry, and nobody outside can check one. A 2026 study found 9 of 10 coding agents delete their own session records when asked, which is why the research page on this hub lands where it lands: a record the agent can reach is a record the agent can rewrite.

The four point check

Run these four questions against any audit trail, yours, a vendor's, or the one your framework prints. Each one is a yes or no, and the trail has to pass all four.

1. Was each entry saved when the step ran, or written up later?

A record saved at run time has no later write-up pass in which the failed attempt gets edited out, because at saving time nobody knew yet which attempt would matter. A record written afterward is a summary wearing a uniform. Ask when the entry was created relative to the step, and be suspicious of any trail whose entries were all created in the same second at the end of the job.

2. Does each entry hold the exact inputs and the saved result, or a sentence about them?

An audit is a recheck. You cannot recheck a sentence. The entry has to carry what went in and what came back, in full, in a fixed form, so that a later reader sees the same bytes the agent saw. If the entry says the step succeeded and nothing more, it is asking you to trust the step. That is the summary problem again, one level down.

3. Is there a digest over the saved result that you can recompute yourself?

This is the point that separates a trail from a log. Each saved result carries a digest, a short fingerprint computed from the exact saved bytes. Recompute it and compare. If they match, the saved result is the one that was saved at run time. If the entry was edited afterward, the digest changes, and the edit shows. No digest, or a digest you can only check inside the operator's dashboard, means the trail's answer to "was this changed" is "trust us".

4. Can a stranger verify an entry with no account and no help from the operator?

Hand the record to someone outside the team: a client, an auditor, the person who has to pay for the work. If checking it needs a login, a license, or the agent explaining itself, the trail only works for people who already trust the operator, which is precisely when a trail is not needed. A checkable record verifies in the open, in a browser, by someone who has never heard of the tool that made it.

Fail any one of the four and what you have is a log. Logs are useful for debugging. They settle nothing when the work is disputed, because the dispute is always about the record itself.

Run the check now, on a real record

Do not take this page's word for any of it. Here is a real record from the public Zambo stream, a whole job closing under one receipt, issued today. Check it the way you would check a stranger's.

The record

What came back when this page was written, and what you will get now: verification_status "verified", with the commitment check passing, meaning the SHA-256 digest of the saved canonical record matches the output_hash stored on the receipt, and the payload reconstruction check passing, meaning the stored output rebuilds the exact bytes the digest covers. The endpoint is equally plain about what it does not check: it returns issuer authentication as not checked, because a receipt URL alone does not authenticate who issued it. That honesty is part of the design. The check proves the saved result was not changed since it was saved. It claims nothing more, and nothing more is needed to settle the argument a trail exists to settle: whether the record in front of you is the record the run actually left. When you are done, pick any receipt off the live receipt stream and run the same two clicks on a record nobody chose for you.

What a trail that passes the check looks like

When work runs through Zambo, every call returns a verifiable receipt in the AER-1 format, published as IETF Internet-Draft draft-zambo-aer1-26. Each receipt is saved when the call runs, holds the call and its saved result in a fixed encoding, and carries the digest a stranger recomputes at the verify endpoint above, with no account. A job's steps sit in order in one trail, and the whole job closes under a single record, the way the receipt in the check section did, so a missing step shows as a gap instead of being quietly dropped. The format is not a claim you have to trust either: the public conformance corpus at zambo.dev carries 126 test vectors and 129 checks that any independent implementation can run, and independent verifiers have done exactly that against the same bytes. New users get 20 calls and 1 wrap-up free every day, and picking up work in another AI is always free, so you can run one real job through it and put your own trail through the four point check before you decide anything. For $0.99, a Day Pass is unlimited for 24 hours: get the Day Pass.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the work was correct, the output was good, or the agent made the right call. A trail that passes the four point check settles what happened. Judging whether what happened was worth paying for is still your job, and it gets much easier once both sides are arguing about the same record instead of two summaries.

Frequently asked questions

What is an AI agent audit trail?

An AI agent audit trail is the ordered, checkable record of what an agent did and what it produced, built so someone else can check it later. Each step is saved when it runs, with its exact inputs and its saved result, and carries a digest a stranger can recompute. The full definition, and what a complete trail contains, is on the AI agent audit trail page on this hub. The short test: if the record can be quietly edited afterward, it is a log, whatever it is called.

How can I tell if my agent's audit trail was edited after the fact?

Ask whether each entry carries a digest over its saved result that you can recompute without the operator's tools. If it does, recompute one: an entry edited after saving produces a different digest, so the edit shows. If the trail has no digests, or the only way to check it is a dashboard the operator controls, you cannot tell, and that is the answer: the trail asks for trust instead of offering a check.

Are my agent's logs enough for an audit?

For debugging, yes. For an audit, no. A log is written by the system being checked, often summarized or written up after the run, and it lives where the operator can edit it. An auditor needs a record that was saved at run time, holds the exact inputs and results, and can be rechecked by someone with no account and no help from the operator. Run the four point check on this page against your logs and count how many points they pass.

Does a verified receipt prove my agent did the work correctly?

No. A verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was right, the price was fair, or the work was worth paying for. That boundary is the point: the receipt settles what was saved, so the argument can move to whether the work was good, with both sides looking at the same record instead of two different stories.

Related

Start free: Add Zambo to your AI. 20 calls + 1 wrap-up free every day; picking up in another AI is always free.