1. What a verifiable execution receipt is
When an AI agent calls a tool, a verifiable execution receipt is a record of that exact call, captured at the moment it happens. It carries a stable ID, a timestamp, which tool ran and who called it, the canonical bytes of the observed result, and a SHA-256 commitment over those bytes. Think of it as a tamper-evident stub for every consequential thing an agent does.
Why it matters to an auditor: ordinary logs are written by the system under review and can be edited after the fact with no trace. A receipt is different because anyone can recompute the hash from the canonical bytes and check it against the stored commitment. If one byte changed after the fact, verification fails. That property is what turns a log into evidence.
2. Anatomy of a complete audit trail
One receipt proves one action. An audit trail is the complete ordered set of receipts for a period, each carrying a sequence position so a missing action is a visible gap, not an invisible absence. Here is what each receipt contains, field by field:
| Field | What it is | Why the auditor cares |
|---|---|---|
| id | Stable unique identifier for the receipt | Every action is addressable and citable |
| created_at | Timestamp of capture, at execution time | Ordering and timing are bound to the event, not reconstructed later |
| tool / caller | Which tool ran and which agent called it | Attribution: who did what |
| canonical_bytes | The exact observed result in canonical form | The ground truth the hash commits to |
| output_hash | SHA-256 commitment over the canonical bytes | Tamper evidence: recompute and compare |
| sequence position | Where this action sits in the run | Completeness: gaps are visible |
| provenance_class | How the receipt was produced (e.g. executed by the platform) | Bound inside the receipt hash, so the claim cannot be swapped |
The open format is AER-1, published as an IETF Internet-Draft. An open format means the evidence does not depend on any single company's survival or goodwill: the auditor checks math, not marketing.
3. A real receipt, check it yourself
Below is a genuine receipt issued today through the public Zambo MCP server. Open the verify link and confirm it resolves. This is the same check your auditor would run on every receipt in the trail.
Sample receipt
f14a093a-24cd-45ca-86e8-7795d48a7512
Issued 2026-10-06 for a real tool execution (zambo_universal). Canonical result: 3,181 bytes. Output commitment: sha256:47b4ed6d...
View the receipt · Verify its fingerprint
The verifier recomputes the SHA-256 commitment from the canonical bytes and reports whether it matches. For this receipt the commitment check passes.
4. The honest boundary
A verifiable receipt proves the saved result was not changed. It does not prove the model was right, the policy was wise, or the outcome was fair. Evidence establishes what happened; whether it should have happened is a governance judgment built on top. Hand an auditor both layers, labeled, and the first one carries the second.
Any vendor who tells you their receipts prove correctness is selling theater. The checkable claim is integrity of the record. That claim is exactly what makes the rest of the audit possible.
5. How this maps to audit requirements
Most AI governance obligations, however they are phrased, reduce to the same demands. Here is the mapping:
- Activity records. "What did the agent do?" The receipt set is the record, one entry per tool execution, in sequence.
- Integrity. "Can the record be trusted?" The SHA-256 commitment makes silent alteration detectable by anyone, no vendor account needed.
- Attribution. "Who did what?" Tool, caller, and timestamp on every receipt.
- Completeness. "Is anything missing?" Sequence positions make omissions visible.
- Reproducibility. "Can we check it again later?" The open AER-1 format and public verifier mean the check does not expire with a contract.
6. The auditor's checklist
Work through this list against the receipt set under review. Every box should be checkable without asking the operator for anything beyond the receipts themselves.
- Coverage. Does the receipt set span the full review period with no unexplained date gaps?
- Sequence. Is every receipt numbered in order, with no missing positions?
- Commitments. Recompute the SHA-256 commitment for a sample of receipts. Do all of them match?
- Timestamps. Do the capture timestamps fall inside the review period and order consistently with the sequence?
- Attribution. Is the tool and caller identified on every receipt?
- Format. Do the receipts conform to the published AER-1 draft, so the check is independent of any vendor?
- Scope honesty. Does the accompanying documentation state the honest boundary (integrity of the record, not correctness of the model)?
7. Hold one in your hands
The fastest way to understand this packet is to hold a receipt yourself. It takes about 30 seconds, no signup, no account:
Further reading: the audit trail guide, compliance evidence, the AER-1 draft.