How to choose an AI agent execution receipt format

How to read this guide

Every receipt format answers the same question: how can a third party verify what an AI agent did, without trusting the party that ran it? Judge every candidate on these six dimensions:

1. Integrity mechanism. Hash commitments (recompute and compare, no keys) versus digital signatures (verify against a public key, keys to manage). Both produce records whose edits are detectable; they differ in operational cost and in whether the record carries attribution.
2. Chaining. How steps link together so deletions and reorderings are visible: per-step chains, receipt-to-receipt references, or Merkle structures. A receipt format with no chaining story is a pile of loose records, not an audit trail.
3. Anchoring. Whether receipts are additionally committed to an external log or chain (transparency log, timestamping service, public relay). Anchoring protects against the operator rewriting their own records.
4. Verification model. Who can verify, with what tooling, and whether an account or vendor relationship is required. The strongest formats verify offline, with open tooling, no account.
5. Conformance and testing. Whether independent implementers can check their work against published vectors or criteria. A format nobody can independently test is a format nobody can trust.
6. Standards status. Open draft, IETF track, or project-defined format. Versioned public specifications outlive vendors.

The honest headline first: no single mechanism is right for everyone. The criteria below show the tradeoffs; the decision guide at the end maps your constraints to the right answers.

Criterion 1: integrity mechanism

This is the first fork in the road, and it shapes everything downstream.

The decision rule: if your threat model needs to prove WHO minted a record, signatures add real value. If you need to prove the record was NOT CHANGED, hashes suffice and are simpler to operate. Do not pay the key-management tax for attribution you do not need.

Criterion 2: chaining

A single verifiable record is evidence. A chain of them is an audit trail. Chaining is what makes deletions and reorderings visible: each step commits to the previous one, so removing a step breaks the chain at a detectable point.

• Per-step hash chains: every step hashes the previous step's hash. Simple, fine-grained, cheap to verify.
• Receipt-to-receipt references: each receipt names its predecessor. Good for decision logs and authorization evidence.
• Merkle structures: steps sealed under a Merkle root. Efficient for batching many steps into one anchored commitment.

Ask: what exactly becomes visible when a step is deleted, reordered, or edited? The answer should be mechanical, not "our system would notice." If the format cannot show you the detection procedure, it does not have one.

Criterion 3: anchoring

Anchoring commits receipt data to something outside the operator's infrastructure: a transparency log, a timestamping service, or a public relay. It answers the hardest question an auditor asks: what stops the operator from rewriting their own records?

• Mandatory anchoring: every receipt or batch is anchored by default. Strongest story, some latency and cost per anchor.
• Optional anchoring: plain records by default, anchoring layered on when an auditor asks. Lets you start simple and upgrade.
• No anchoring: the records live only in the operator's custody. Fine for internal debugging, weak as third-party evidence.

Ask: anchored to what, exactly, and who runs it? Two independent anchoring roots (for example a transparency log plus an independent timestamping service) beat one. "Anchored to our ledger" from the operator is not anchoring.

Criterion 4: verification model

The whole point of a verifiable receipt is that a skeptic can re-check it. The verification model tells you how much friction stands between the record and the skeptic.

• Open, offline: anyone verifies with open tooling, no account, no network call to the vendor. This is the gold standard.
• Open, online: verification needs a hosted verifier but no account. Good, with a availability dependency on the host.
• Gated: verification needs an account, a key, or a vendor relationship. The evidence is only as independent as the gatekeeper allows.

Ask: can a regulator, a counterparty, or a journalist verify a receipt five years from now with no relationship to any vendor? If the answer involves an account, the receipt is rented evidence, not owned evidence.

Criterion 5: conformance and testing

A format is only as trustworthy as its implementations, and implementations are only as trustworthy as their tests. Published attack-case vectors, known-answer tests, or conformance criteria let independent builders check their work instead of trusting it.

Ask: does the format publish test vectors an independent implementer can run? Are there multiple independent implementations, or just the reference one? A format with one implementation and no vectors is a demo, not infrastructure.

Criterion 6: standards status

IETF drafts and other open, versioned specifications outlive any single vendor. Project-defined formats can be excellent and can standardize later, but today their specification is the project's repository.

Ask: where is the specification, who can change it, and what happens to your old receipts if the project pivots? Weight the answer by how long you need your evidence to remain verifiable. Audit evidence with a seven-year retention requirement should not depend on a startup's roadmap.

How to choose: the decision guide

Match your constraint to the right answers. If none of these constraints bind you, start with the simplest operational model and add machinery only when an auditor demands it.

• You want verifiable records with the least to operate. Hash-based, no keys, no PKI, verification is recompute-and-compare. Try it live before you read further.
• Your receipts are authorization decisions and identity matters. Look for signature-based formats where the signing identity is a first-class property of the record.
• Compliance requires post-quantum signatures now. Look for ML-DSA or hybrid classical plus post-quantum options. Check which signature sizes your storage budget tolerates.
• You need an explicit EU AI Act or DORA mapping document. Some formats publish mappings; AER-1's Article 12 mapping is covered in our Article 12 guide.
• Your auditor wants the strongest public anchoring. Look for formats anchoring to a transparency log plus an independent timestamping root.
• Your audit posture demands verifier redundancy. Look for formats with two independent verifier implementations, so a bug in one does not silently pass bad records.
• You want attestation as an upgrade path, not a day-one requirement. Look for formats where the transparency-log layer is optional: start with plain hash chains, attest when an auditor asks.

What every serious format agrees on

Beneath the mechanism debates there is a real consensus, and it is the part that matters most:

• The agent cannot be its own witness. Every serious format mints receipts in the execution system, outside the agent's trust domain. An agent that writes its own audit log is writing fiction with good formatting.
• Verification must not require trusting the operator. The whole point is that a skeptic, an auditor, or a counterparty can re-check the record independently.
• Integrity is cryptographic or it is not integrity. Hash commitments, digital signatures, or both; "edit-detectable" means any later change leaves a detectable mark, verified mechanically.
• A receipt proves the record was not changed, not that the model was right. No honest format claims otherwise, and any vendor that does is selling something else.

If you take one thing from this page: pick the format whose tradeoffs fit your constraints, but do not ship an agent without any of them. The unauditable agent is the actual risk, not the choice of hash function.