The short answer
Keep a per-call record that a third party can check without trusting you: the tool, the caller scope, the time, the exact saved result, and a digest of that result. That is the layer both frameworks probe. Article 12 of the EU AI Act requires automatic recording of events for high-risk AI systems so outcomes can be traced and incidents reconstructed; SOC 2's change and operations criteria ask for audit trails that show what happened and support investigation. A plain server log answers on trust. A verifiable receipt answers by recomputation: 44,485 receipts sat in the production record as of October 16, 2026, every one checkable by anyone at a public endpoint, and 2,536 more were issued on October 24, 2026 alone.
Scope, stated once and applied everywhere on this page: an agent receipt is a record of one ai agent tool call that anyone can check: it keeps the exact saved bytes and their sha-256 digest, and it proves the result was not changed since it was saved, not that it was right. It also does not prove a call was authorized, appropriate, or wise. Those judgments stay with the operator and the auditor.
The checklist, mapped
| Audit question | Where it comes from | What an AER-1 receipt shows | What you still need elsewhere |
|---|---|---|---|
| What ran, exactly? | EU AI Act Article 12 (events recorded over the system's lifetime); SOC 2 CC7 operations criteria | The tool name, the saved result bytes kept with the receipt, and the receipt's stable public URL | Input retention policy: the receipt commits to the output; keep inputs under your own retention rules where the audit scope requires them |
| When did it run? | Article 12 traceability; SOC 2 incident investigation | A timestamp on every receipt, plus hash-chained job timelines that order a session's calls in sequence | Clock discipline on your own systems for records the receipt does not cover |
| Who or what called it? | Article 12 (identification of involved parties where relevant); SOC 2 CC6 access criteria | A caller scope and a provenance class on every receipt, separating who ran or reported the action from the record itself | Identity and access control are yours. A receipt records the caller scope it was given; authenticating callers is your auth layer's job, and the format says so in its own security considerations |
| Can the record be trusted afterwards? | The question underneath both frameworks: a record the operator can quietly rewrite is weak evidence | The SHA-256 digest of the exact saved bytes, kept with the receipt. Verification is a recomputation anyone can run at the public endpoint: if the saved result changed after the fact, the digest no longer matches and the check fails in the open | Nothing, for this layer. This is the one question the receipt answers completely, and it is the question a log file cannot answer at all |
| Can an incident be reconstructed? | Article 12 (post-incident reconstruction); SOC 2 CC7.3/CC7.4 recovery and investigation | Workflow receipts bind an ordered sequence of step receipts to one goal under a single root digest, so a whole job can be replayed step by step and any single altered step shows | Your incident process itself: who reviews, who decides, who notifies. The record supports the investigation; it is not the investigation |
| How long are records kept? | Article 12 (logs kept for a period appropriate to the purpose, at least six months unless other law provides otherwise) | Receipts resolve at stable public URLs and are kept server-side by the issuer | Your retention schedule and deletion policy for everything outside the receipt: prompts, files, and your own application data |
Two rows in that table carry the honest weight of this page. Identity is yours: AER-1's own text discloses that issuer authentication is a separate layer, and a receipt presented as proof of authorization would be an overclaim. And no row, singly or together, adds up to a compliance verdict: classification of your system, and whether these records satisfy your auditor, are judgments for you and them.
The numbers an auditor can re-run
- 126 conformance vectors, 129 checks in the published AER-1 corpus (kit v1.5.7). The evaluated-set digest is published with the corpus, so a claimed conformance pass can be checked as a set difference rather than believed.
- Seven bundled kit runners (Rust, Go, TypeScript, Python, Java, C#, Swift), each verified against the full corpus, plus independent implementations built from the draft text alone.
- 153 tools on the live endpoint, every call receipted, including calls that are rejected: the record exists for the failures an investigation asks about first.
- 2,536 receipts on October 24, 2026 and 44,485 in the production record as of October 16, 2026, each retrievable at its public URL without an account.
The draft states its own scope in one sentence: "This document specifies AER-1, a small vocabulary for recording one AI agent tool call as a portable, independently checkable execution receipt." (draft-zambo-aer1-26, Abstract). Small vocabulary, narrow claim, checkable record: that is the shape audit evidence should have. For citing the draft and the dataset in your own compliance documentation, use how to cite AER-1.
Questions, answered
Does an AER-1 receipt make my MCP server compliant?
No, and any tool that tells you otherwise is overclaiming. A receipt covers one layer: the per-call record, kept with the exact saved bytes and a digest anyone can recompute, so the record can be checked after the fact. Compliance also needs identity and access control, retention policy, incident process, and human oversight, and those stay the operator's job. What the receipt removes is the weakest layer in most MCP audits today: a log the operator could have edited, that nobody outside can check.
What does EU AI Act Article 12 require for record-keeping?
For high-risk AI systems, Article 12 requires record-keeping: the system must technically allow automatic recording of events (logs) over its lifetime, so that outcomes can be traced, the system's operation can be monitored, and incidents can be reconstructed. The logs must be kept for a period appropriate to the intended purpose, at least six months unless other law says otherwise. Whether a given MCP deployment falls in the high-risk class depends on its use, not on the protocol, and that classification is a legal question for the operator.
How is a receipt different from a server log?
A log is a file the operator keeps and can edit; an auditor reads it on trust. A receipt keeps the exact saved bytes of the call's result together with its SHA-256 digest, and verification is a recomputation anyone can run: recompute the digest of the saved bytes and compare. If the record was changed after the fact, the digest no longer matches and the check fails in public, for the auditor exactly as for the operator.
What does it cost to add receipted records to an MCP workflow?
Calls that run through Zambo carry a receipt by default, at no separate charge: 20 free calls per day, then a $0.99 Day Pass for 24 hours of higher limits, or the Zambo Pass at $29 for 30 days, one payment, $290 for 365 days, and $19 for 30 days for $ZAMBO holders. People pay by card through PayPal; agents pay in USDC on Base through x402. For an MCP server you operate yourself, the AER-1 format is public and the conformance kit is free to run.