Execution receipts explained
An execution receipt is a signed record of one agent action: what was attempted, which policy permitted it, who approved it, and what the provider actually returned. It differs from a log in one decisive way — it is designed to be relied on by someone who does not trust you.
Get an Agent Trust Gap BriefA log is not evidence
Application logs are written for engineers debugging their own system. They are mutable, incomplete by design, rotated aggressively, and record what the code chose to mention. None of those properties survive contact with an auditor, a regulator or a disputing customer.
| Property | Application log | Execution receipt |
|---|---|---|
| Written for | Your engineers | Someone who does not trust you |
| Mutable | Usually | Append-only, integrity-protected |
| Records authority | Rarely | Always — policy and approver |
| Records refusals | Almost never | Yes, with equal weight |
| Retention | Days to weeks | Matched to obligation |
| Provider response | Sometimes | Always — distinguishes sent from accepted |
What a receipt contains
- Action identity — a stable id, which is also the idempotency key. One id, one effect, forever.
- Agent identity — which agent, acting for which principal, under which passport.
- Intent — what it proposed to do, captured before it did it.
- Policy decision — which policy version was evaluated, against which inputs, with what outcome.
- Approval — if required, the approver's identity bound to this action id, signed.
- Provider response — what the downstream system actually returned, so "we sent it" and "it was accepted" stay distinguishable.
- Integrity — a signature, and a chain reference to the previous receipt so deletion is detectable.
- Algorithm identifier — a named field, not an assumption, so the scheme can change without invalidating the format. See post-quantum agent evidence.
A worked sample is published at /.well-known/sample-execution-receipt.json, and the schema at ApexClaw Receipts.
What replay proves, and what it does not
Replay re-evaluates a recorded decision against a recorded policy and confirms the outcome matches. It must never re-fire the action. A replay that sends the email again is not verification, it is a second incident.
Replay proves the decision was consistent with the policy as recorded. It does not prove the policy was correct, and it does not prove the inputs were true. Those are separate questions and conflating them is how organisations overstate what their evidence shows.
Common questions
What is an execution receipt?
A signed record of one agent action containing what was attempted, which policy permitted it, who approved it, what the provider returned, and an integrity mechanism proving it has not been altered.
Why are application logs not enough?
They are mutable, rotated on operational schedules, rarely record authority, and almost never record refusals. Evidence that only shows successes cannot demonstrate that a control exists.
What is a receipt chain?
Each receipt references the previous one, so removing a record breaks the chain and the deletion becomes detectable. Without it, absence of a record and absence of an event look identical.
Does replay re-execute the action?
It must not. Replay re-evaluates the decision against the recorded policy and compares outcomes. Re-firing the side effect turns verification into a second incident.
How long should receipts be retained?
Matched to your longest applicable obligation — often years. The common failure is infrastructure log rotation silently deleting governance evidence on an operational schedule.
Last verified 2026-08-07. Sources are named inline. Not legal advice.
By Julian Joseph, Founder, ApexClaw. Written from direct work operating autonomous systems under governance. Reviewed against the claims policy: sourced, first-party, or labelled.