An execution receipt is a signed, tamper-evident record of one agent action and the authorization that permitted it.
It records who acted, under which policy, with whose approval, against which exact payload, and what the outcome was — then hashes itself into a chain so the record cannot be quietly edited later. Where a log tells you what an application chose to write down, a receipt proves what was authorized.
Get an Agent Trust Gap BriefAn audit log is not an execution receipt
This distinction is the whole product, so it is worth being precise about.
| Audit log | Execution receipt | |
|---|---|---|
| Written by | The application, after the fact | The gateway, at the moment of authorization |
| Can be edited | Yes, usually without trace | Not without breaking chain verification |
| Contains the authorization | Rarely — usually just the outcome | Policy version, gates passed, approval, payload hash |
| Proves who allowed it | No | Yes — the approval is bound into the record |
| Survives a hostile question | “How do we know this wasn't changed?” | Verify the chain |
What a receipt carries
Identity
Which agent acted, under which passport, and the human accountable for it.
Authorization
Policy version, which gates were evaluated, and how many passed.
Approval
Who approved it, bound to an exact payload hash, single-use, with an expiry that was still valid at execution.
Execution
The effect owner, the idempotency key, the provider response class, the timestamp.
Outcome
What actually happened, verified independently of the actor where possible.
Chain
The hash of the previous receipt and of this one, so tampering with any single record breaks verification.
Synthetic sample sample-execution-receipt.json — illustrative structure, clearly labelled, not a production record.
Replay: reconstructing what happened
Receipts are only half the value. Because each one carries the inputs and the authorization, a sequence can be replayed to reconstruct an incident — what the agent believed, what it proposed, what was allowed, and what actually landed. That turns a two-week forensic exercise into a query.
- Why did the agent choose this action over the alternatives?
- Was the policy at the time different from the policy now?
- Did a human approve it, or did it pass on autonomy?
- Did the same action fire twice, and if so why did idempotency not stop it?
- At which step did the chain break?
The BLOCK / APPROVE / TAMPER test
A receipt system that has never been tested against a hostile case is a claim, not a control. Three tests, and any vendor should be able to show all three:
- BLOCK — an out-of-scope action is refused before execution, and the refusal itself emits a signed receipt. Refusals must be evidence too, or your record only shows successes.
- APPROVE — an approval is bound to one exact payload and one time window. Modify the payload or let the window lapse and the same approval must refuse.
- TAMPER — alter a stored receipt. Chain verification must fail and identify where integrity broke.
Maps to ASI04 Agentic Supply Chain and ASI09 Human–Agent Trust Exploitation, NIST AI RMF MEASURE 2.8, and EU AI Act Article 12 record-keeping.
Common questions
What is in an execution receipt?
Action identity, agent identity, intent, the policy decision, the approval if required, the provider's response, and an integrity mechanism such as a signature and a chain reference.
Why are logs not enough?
Logs are mutable, rotated on operational schedules, and rarely record authority or refusals. Evidence that only shows successes cannot demonstrate a control exists.
What is a receipt chain?
Each receipt references the previous one so a deletion breaks the chain and becomes detectable. Without it, a missing record and a non-event look identical.
Does replay re-run the action?
No, and it must not. Replay re-evaluates the decision against the recorded policy. Re-firing the effect would be a second incident.
How long should receipts be kept?
Matched to the longest applicable obligation, which is often years. Do not let log rotation set governance retention.
An audit log can be edited; a signed receipt chain cannot be edited unnoticed. That difference is the entire evidentiary value.
Sources
Signed evidence is not a hypothetical here: Omega, the autonomous system ApexClaw governs itself with, has produced 0% real external sends across its entire history, verified at the network layer rather than inferred from logs — see the governed-run record for the receipts that back that number. The obligation to keep that kind of evidence is not abstract: the EU AI Act's penalty tiers run up to 7%, 3% and 1% of global turnover depending on the breach, and machine identities generating the actions a receipt has to cover already outnumber human ones by more than 80x in most enterprises. Standards this surface maps to:
- Signature mechanics for evidence objects: RFC 9421, HTTP Message Signatures.
- Structured, machine-readable evidence: JSON-LD 1.1, W3C Recommendation.
- Auditability and evidence controls for agentic systems: OWASP Top 10 for Agentic Applications.
A receipt that only records successes is not evidence of a control; it is a highlight reel. The refusal is the more load-bearing half of the record, because it is the one a vendor is tempted to leave out.