Research question
When an AI agent proposes a consequential action, the organisation needs a durable answer to four questions: what was requested, which policy evaluated it, what verdict was returned, and what evidence lets a verifier reproduce that answer later?
Application logs are not enough. Logs are usually service-local, mutable, incomplete, and coupled to the vendor that produced them. An execution receipt is a smaller and stricter artifact: a signed, portable decision record for one attempted action.
Method
This paper draws from three mature patterns:
- Cryptographic canonicalization and signatures, especially JCS and EdDSA.
- Supply-chain provenance systems such as in-toto and SLSA, which bind artifacts to build inputs and verifiable statements.
- AI risk-management guidance that asks organisations to govern, map, measure, and manage model risks with accountable evidence.
The result is not a new general-purpose provenance standard. It is a constrained receipt model for AI action governance.
Receipt role
The receipt sits after planning and before dispatch. A framework or agent runtime proposes an intent: actor, target tool, action, arguments, context, and risk metadata. The boundary evaluates that intent against a policy snapshot. The receipt records the resulting verdict.
The receipt is not the trace of the whole conversation. It should not include private chain-of-thought, every token, or every retrieved document. It should record enough to verify the decision without becoming an unbounded privacy and retention problem.
The minimum receipt role is:
- prove that evaluation happened before dispatch;
- bind the verdict to the intent and policy snapshot;
- identify the evaluator and signer;
- preserve reason codes and evidence references;
- allow offline verification by an auditor who does not trust the live service.
Minimum fields
A receipt for governed agent execution should include:
- Receipt identity. A stable receipt identifier, format version, creation time, and tenant or deployment scope.
- Intent digest. A digest of the canonicalized intent envelope, including actor, action, target connector, tool arguments, and risk labels.
- Policy digest. A digest of the policy bundle, plus a human-readable policy version or release label.
- Verdict. Allow, deny, or escalate; a reason code; and the boundary component that produced it.
- Evidence references. Pointers or digests for artifacts needed to replay the decision, such as schema versions, connector manifests, approval records, or threat-detector outputs.
- Signer metadata. Key identifier, signature algorithm, and signing envelope.
- Verification hints. The verifier profile and any required external trust roots.
This field set mirrors the discipline of supply-chain attestations: record the inputs that matter, bind them to an evaluator identity, and make downstream verification explicit.
Canonicalization
Receipts fail if two systems compute different bytes for the same semantic event. JSON is common for agent systems, but ordinary JSON serialization is not stable enough for signatures. RFC 8785’s JSON Canonicalization Scheme provides a standard way to produce deterministic JSON bytes for hashing and signing.
The boundary should canonicalize the intent, policy digest envelope, and final receipt payload before computing hashes. The canonicalization step must reject ambiguous or invalid values rather than repairing them silently. A repaired receipt is not evidence; it is a new interpretation of evidence.
Signature envelope
Ed25519 is attractive for receipts because signatures are small, fast, and widely implemented. RFC 8032 specifies EdDSA, including Ed25519. The specific algorithm matters less than the operational rule: the receipt signature must cover the canonical payload that includes the verdict and evidence bindings.
Multi-signature formats such as DSSE show a useful pattern: separate the signed payload from the signature envelope and include a payload type. Execution receipts can follow the same discipline even if they do not adopt DSSE directly. Payload type prevents one signature from being replayed as a different class of statement.
Offline verification
The verifier should be able to answer:
- Is the receipt structurally valid for its declared version?
- Does the receipt signature verify against a trusted key?
- Do the intent and policy digests match the referenced artifacts?
- Does replaying the policy against the intent return the same verdict?
- Are timestamps, signer status, and trust roots acceptable for the verifier’s policy?
Steps 3 and 4 are what separate receipts from ordinary logs. A log says a service returned a verdict. A receipt lets someone recompute whether that verdict follows from the policy and inputs that were in force.
Failure modes
The receipt system must fail closed on at least seven conditions:
- missing policy snapshot;
- stale policy snapshot beyond the deployment’s freshness window;
- unknown required receipt field;
- non-canonical payload;
- invalid signature;
- unresolvable evidence reference for a required artifact;
- replay verdict mismatch.
A verifier may still emit a diagnostic report for each failure, but it should not treat the original action as proven.
Design implications
Receipts should be small enough to emit on every allow, deny, and escalation. Deny receipts matter as much as allow receipts because they show policy coverage and failed attack attempts. Escalation receipts matter because they preserve the chain between machine evaluation and human approval.
Receipts should also survive framework migration. If the old agent framework is gone, the organisation should still be able to verify what happened. That pushes framework-specific traces into referenced evidence and keeps the receipt envelope stable.
Limitations
A receipt does not prove that the model reasoned correctly. It proves that a proposed action passed or failed a policy boundary. It also does not prove that every relevant risk was encoded in policy. Poor policy can produce valid receipts for bad actions.
Finally, offline verification depends on retaining the referenced evidence. If a deployment stores only the receipt and deletes required policy bundles, connector manifests, or approval artifacts, the receipt becomes a signed pointer to missing context.
Conclusion
The execution receipt is the smallest durable proof unit for governed agent action. It turns agent authority from a runtime assertion into a verifiable artifact. In production systems, that artifact should be emitted for every consequential action before the action leaves the boundary.