Short answer: the one-minute check
Do not ask the agent. Ask for its receipts. Every consequential tool call should have a verifiable execution receipt: which tool ran, which agent called it, the exact inputs and observed outputs in canonical bytes, and a SHA-256 commitment over those bytes that anyone can recompute. Then run three checks:
Recompute the hash
Take the receipt's canonical bytes, compute SHA-256, and compare the result to the receipt's committed output hash. Match: the record was not altered after execution. Mismatch: the record cannot be trusted, and you now know it was tampered with.
Confirm the sequence
Every receipt carries its position in the run's order. Confirm the positions form an unbroken chain. A missing step is a visible gap, and a gap is itself evidence that something is being hidden.
Confirm the origin
Confirm the receipt was captured at execution, inside the tool-call path, not reconstructed from a chat transcript afterward. A receipt generated from the agent's own summary is the same circular problem you are trying to escape.
The public verifier at zambo.dev/verify and the live demo do the first two checks for you. You can paste any receipt and get a verdict in seconds.
Why asking the agent fails
The summary and the evidence come from the same process. The agent that did the work is also the one telling you what it did. A model that misunderstood its task will misunderstand its own report of the task. A model that hallucinated an output will hallucinate the report of producing it. Asking the agent to verify itself is circular: there is no independent reference point, so there is no verification, only a second claim stacked on the first.
This is the trap most "trust your agent" tooling falls into. The activity feed, the run summary, the execution log: all of them are generated by the system under review. Verification needs an artifact that does not depend on the agent's honesty or accuracy. A receipt captured at execution, before the agent summarizes anything, is that artifact. When the summary drifts from the receipt, you catch the drift. When the receipt and the summary agree, you have something better than trust: you have evidence.
What a real receipt looks like
A verifiable execution receipt is not a blob of JSON you have to take on faith. It is a small, structured record with everything a stranger needs to check it:
- A receipt ID that uniquely identifies the record and never changes.
- Agent identity: which agent performed the action.
- The tool and the call: the exact operation that ran.
- Canonical bytes of inputs and observed outputs, so the hash is deterministic and recomputable by anyone.
- A SHA-256 output hash: the commitment that binds the record.
- An execution timestamp and a sequence position in the run.
The open format for these receipts is AER-1, an IETF Internet-Draft (draft-zambo-aer1). The fields, the canonical encoding, and the verification rules are public, and a public registry lists the independent implementations that pass the conformance kit.
Try it with a real receipt
The live demo runs a real agent call and hands you the receipt: raw JSON, the human-readable view, and the verification endpoint. Open the receipt, recompute the hash yourself, and confirm it matches. That is the whole check, and it takes less than a minute.
The honest limits
Verification proves the recorded actions happened as recorded and were not altered afterward. It does not prove the actions were correct, the outputs were right, or the policy was wise. And it has one more limit worth stating plainly: a receipt proves the committed bytes were unchanged. It does not prove the upstream capture was truthful. If the tool itself lied about its result, the receipt faithfully records the lie.
This is not a weakness of the mechanism. It is the boundary of what any record can do. Receipts move the dispute from "did it happen" to "was it right," and that move is enormous: the first question is now settled by computation instead of argument. The second question is where judgment, policy, and human review belong.
If the agent says "done" and you don't believe it
Ask for the receipt, not a longer explanation. A longer explanation is another claim from the same source. A verifiable receipt is the evidence the claim is supposed to rest on. If the vendor cannot produce one, that is your answer: there is no checkable evidence the work happened. If they can, run the three checks yourself. The dispute kit walks through the exact steps, with a message template to send.
Verifying your AI agent: FAQ
How can I verify what my AI agent actually did?
Check the verifiable execution receipt, not the agent's summary. Recompute the SHA-256 hash over the receipt's canonical bytes and compare it to the committed value. If they match, the record was not altered after execution. If they don't, the record can't be trusted.
Why can't I just ask my agent what it did?
Because the summary and the evidence come from the same process. A model that misunderstood its task will misunderstand its own report of the task. Asking the agent to verify itself is circular. Verification needs an independent artifact: a receipt captured at execution that the summary can be checked against.
What does a verifiable execution receipt prove?
It proves the committed bytes were not changed after the receipt was issued: the recorded inputs, outputs, tool, agent identity, and timestamp are exactly as they were at execution. It does not prove the agent was right or the upstream tool told the truth. Receipts establish what happened; whether it should have happened is a separate question.
How do I check an AI agent's receipt in under a minute?
Three checks: recompute the SHA-256 hash over the receipt's canonical bytes and compare it to the commitment; confirm the sequence positions form an unbroken chain with no missing steps; confirm the receipt was captured at execution rather than reconstructed later. The public verifier and the live demo do the first two checks for you, no signup required.
My agent says the work is done but I don't believe it. What do I do?
Ask for the receipt, not a longer explanation. If the vendor can't produce a verifiable receipt, there is no checkable evidence the work happened. If they can, recompute the hash and confirm the sequence yourself. The dispute kit walks through the exact steps and the message template to send.
Is there a standard format for AI agent verification?
The open AER-1 format (an IETF Internet-Draft, draft-zambo-aer1) defines verifiable execution receipts for AI agents: the receipt fields, the canonical byte encoding, and the verification rules, with an open conformance kit and a public registry of implementations. One-line collectors exist for major agent frameworks.