Category · AI action evidence
AI Action Receipts: Cryptographic Proof of What an Agent Was Authorised to Do
When an autonomous system moves money, “our logs say it was fine” is not evidence. A receipt is: signed at decision time, chained to its predecessor, and verifiable by someone who does not trust you.
The short answer
An AI action receipt is a signed, tamper-evident record created at the moment a policy decision is made about an agent action, containing the action, its arguments digest, the identity chain that authorised it, the policy version applied, any approval, and a hash linking it to the previous receipt. Unlike a log entry, it can be verified by a party who does not trust the system that produced it. That last property is the entire point. Evidence you control and can silently edit is not evidence in any dispute that matters.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸A receipt is created before execution, at decision time, and signed. A log entry is written after the fact by the system that performed the action, and can be edited by anyone who can edit logs.
- ▸Twelve fields: receipt id, timestamps, principal chain, agent identity, capability and tool, arguments digest, decision outcome, rule and policy version, approval reference, upstream result reference, previous receipt hash, and signature.
- ▸Hash chaining makes deletion and reordering detectable. Periodic anchoring of the chain head to an external timestamp makes wholesale rewriting detectable too.
- ▸Arguments are recorded as a salted digest plus a classified summary, never in full. A receipt must be retainable for years without becoming a personal-data liability.
- ▸Receipts answer four specific disputes: did this action happen, who authorised it, was it within policy at the time, and has the record been altered since.
Source: Mark Alex, Real Biz Digital — AI Action Receipts: Cryptographic Proof of What an Agent Was Authorised to Do (https://realbizdigital.net/insights/ai-action-receipt/). Reproduce with attribution.
Key takeaways
- 01Sign at decision time, before execution. A record created after the effect cannot prove what was authorised, only what was reported.
- 02Include the full principal chain: human, agent, and every intermediate agent in a delegation. Multi-agent estates lose accountability exactly here.
- 03Record the policy version, not just the rule. Reconstructing a decision requires knowing what the rules were on the day.
- 04Digest the arguments with a per-tenant salt. You get integrity and comparability without retaining sensitive values for seven years.
- 05Anchor the chain head externally at intervals. Internal chaining detects tampering by anyone who cannot rewrite the whole chain; anchoring closes that gap.
- 06Publish the verification procedure. Evidence nobody outside your team can check is a claim, not proof.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- What is an AI action receipt?
- A signed, tamper-evident record created at policy-decision time for an agent action, containing the action, arguments digest, identity chain, policy version, approval and a hash link to the previous receipt.
- How is it different from an audit log entry?
- Timing and verifiability. A receipt is created before execution and signed so a third party can verify it; a log entry is written afterwards by the system that acted and is editable by whoever administers logging.
- What does non-repudiation mean here?
- That the party who authorised an action cannot credibly deny having authorised it, because the record binds identity, action and time in a way that cannot be produced retrospectively.
- Do I need receipts for every action?
- No. Receipts are for consequential actions: money movement, irreversible changes, regulated data, and anything a human had to approve. Routine reads need ordinary logging.
- What goes in the signature?
- A canonical serialisation of all receipt fields including the previous hash, signed with a key held by the decision point, not by the executing system.
- How do I stop receipts becoming a privacy problem?
- Store a salted digest of arguments plus a classified summary rather than raw values, so a receipt proves integrity without retaining the sensitive content.
- Who verifies a receipt?
- Anyone given the public key, the chain and the verification procedure — an internal auditor, an external auditor, a counterparty, or a regulator.
Why a log entry fails the test
Every organisation already logs agent actions. Almost none can prove what those logs say.
Consider the sequence of questions that follows a disputed autonomous action. Did the action happen? Who authorised it? Was it permitted by policy at that moment? Has the record been altered since? Ordinary application logging answers the first with reasonable confidence and struggles with the remaining three.
The structural problem is not log quality. It is that the log is produced after the fact, by the system that performed the action, in a store administered by the same organisation being asked to prove something. That is fine for debugging and inadequate for a dispute.
| Property | Application log | Audit log | Signed receipt |
|---|---|---|---|
| Created before execution | No | Sometimes | Yes — at decision time |
| States what was authorised | No | Partially | Yes — outcome, rule, policy version |
| Includes approval evidence | No | Sometimes | Yes — approval reference and approver |
| Tamper detectable | No | Sometimes | Yes — hash chain and signature |
| Verifiable without trusting the operator | No | No | Yes — with the public key |
| Full principal chain in multi-agent flows | Rarely | Rarely | Yes — by design |
The distinction matters most in exactly the situations you least want to be in: a disputed payment, a regulator asking how an automated decision was authorised, a customer claiming an action was taken without consent, or an insurer asking what controls were in force.
The twelve fields of a receipt
Key facts
- ▸
result_refis the only field written after execution. It must be appended as a linked second record rather than by mutating the signed receipt, or the signature is void. - ▸
principal_chainis what makes receipts work in multi-agent systems. A receipt naming only the acting agent proves that a service account did something, which is rarely the question being asked. - ▸
args_digestplusargs_summaryis the compromise that makes long retention possible. You can prove which arguments were used without holding the values for seven years.
| Field | Content | Why it must be there |
|---|---|---|
receipt_id | ULID, monotonic per emitter | Ordering and unambiguous reference in later disputes |
ts_decision, ts_signed | RFC 3339 with millisecond precision | Establishes that the record predates the effect |
principal_chain | Ordered list: human, agent, intermediate agents | The single field multi-agent estates most often lose |
assurance | Authentication assurance level at decision time | Whether the authorisation met the strength policy required |
capability, tool, tool_version | Business capability plus concrete implementation | Lets an auditor reason in business terms, not tool names |
args_digest | Salted hash of canonicalised arguments | Proves which exact arguments, without retaining them |
args_summary | Classified, thresholded summary | Enables review without exposing sensitive values |
decision | One of the deterministic outcomes | What was authorised, in the engine’s own vocabulary |
rule, policy_version | Rule identifier and repository commit | Reconstructing the rules as they stood that day |
approval | Approval id, approver identity, expiry, single-use flag | Human accountability for consequential actions |
result_ref | Upstream identifier and status, added post-execution | Links authorisation to what actually happened |
prev_hash, signature | Hash of the previous receipt; signature over all fields | Tamper evidence and third-party verifiability |
Twelve fields, of which eleven are known before execution. That is what makes the receipt a statement about authorisation rather than a report about an outcome.
Chaining, anchoring and what each actually protects against
Integrity mechanisms are frequently described loosely. It is worth being precise about which attack each one defeats, because the gaps are not obvious.
- Signature over each receipt
- Defeats: modification of a single record by anyone without the signing key. Does not defeat: deletion of a record, or reordering.
- Hash chain (
prev_hash) - Defeats: deletion, insertion and reordering, because any change breaks the chain from that point onward. Does not defeat: rewriting the entire chain from the point of interest forward, if the attacker holds the signing key.
- Periodic external anchoring
- Publishing the chain head hash to an independent, timestamped location at intervals. Defeats: wholesale rewriting, because the rewritten chain will not match a previously published head. Does not defeat: fabrication going forward from now.
- Independent counter-signature
- A second party signs the chain head periodically. Defeats: collusion-free repudiation, since two independent keys must be compromised. Cost: an operational relationship with the second party.
- Write-once storage
- Object storage with immutability or legal hold. Defeats: administrative deletion within the retention window. Does not defeat: anything done before the record was written.
A practical, proportionate configuration
per-receipt signature (decision point key, rotated quarterly) + hash chain per emitter + chain head anchored hourly to an RFC 3161 timestamp authority + write-once storage with a legal-hold retention policy verification: recompute chain from any anchored head forward
This combination is defensible to an auditor without requiring a blockchain, a consortium, or any novel infrastructure. Hourly anchoring bounds the window in which undetected rewriting is possible to one hour.
Note what is deliberately absent: a distributed ledger. Anchoring a hash to a timestamp authority achieves the property that matters — an independent party attests that this chain head existed at this time — without operating consensus infrastructure.
Signing keys: the part that undermines everything if done casually
- 01The decision point holds the key, not the executing system. A receipt signed by the system that performed the action proves that the system says it did the action, which is where you started.
- 02Use a hardware-backed or KMS-held key with non-exportability. A signing key that can be copied is a signing key that can be used to rewrite history.
- 03Rotate on a schedule and publish the rotation record. Verifiers need to know which key was valid when, so key validity periods must themselves be part of the published record.
- 04Never share the key across environments. Staging receipts signed with the production key are indistinguishable from production receipts, which is a problem you discover during an audit.
- 05Log every signing operation count. A signature count that exceeds the receipt count means something signed things you cannot see.
- 06Have a compromise procedure written down. On suspected key compromise, anchor immediately, rotate, and record the boundary; receipts after the boundary are verifiable, receipts before it are questionable, and pretending otherwise is worse than the compromise.
Key management is the least interesting and most consequential part of this design. A perfect receipt schema signed with a key sitting in an environment variable is a decorative security control.
The verification procedure, written for someone who does not trust you
Publish this. Evidence that only your team can check is a claim. The procedure below should be executable by an external auditor with the public key and the receipt set.
Obtain the public keys and their validity periods
From a published location independent of the receipt store, so that a compromise of the store does not compromise the verification material.
Verify each signature against the key valid at ts_signed
Any receipt whose signature fails, or which was signed by a key outside its validity window, is not evidence.
Recompute the hash chain
For each receipt, hash the canonical serialisation and compare with the following receipt’s prev_hash. Any break localises tampering to a specific point.
Reconcile against anchored heads
For each anchoring interval, confirm the computed chain head matches the externally timestamped value. This is what rules out wholesale rewriting.
Verify the argument digest against a claimed value
Given a claimed argument set and the tenant salt, recompute the digest and compare. This is how a specific disputed action is proven, without arguments having been retained.
Reconstruct the policy in force
Check out the recorded policy_version commit and confirm the recorded rule produces the recorded outcome for those arguments. This answers “was it within policy at the time”.
Step six is the step that distinguishes a governance programme from a logging programme. It requires policy to be in version control, which is why receipts and policy-as-code are the same project seen from two directions.
Four disputes receipts are designed to settle
Key facts
- ▸In all four cases the value comes from the record being unfalsifiable rather than from being detailed. A rich log you could have edited answers none of these well.
- ▸Receipts are worth the cost only for consequential actions. Applying them to every read is expensive theatre; applying them to money, deletion and regulated data is proportionate.
- ▸The moment to introduce receipts is before the first dispute, because a receipt series that begins after an allegation has limited value for the period in question.
- A disputed financial action
- A customer or counterparty asserts an unauthorised payment or refund. The receipt supplies the principal chain, the approval, the policy in force and the argument digest. Without it, the answer is an assertion about log integrity.
- A regulatory inquiry into automated decision-making
- A regulator asks how a specific automated action was authorised and what human oversight applied. Receipts answer directly; log extracts invite follow-up questions about who could have edited them.
- An insider-action allegation
- Someone is alleged to have used an agent to do something they could not do directly. The principal chain and assurance level either support or refute that, and the chain integrity means the record cannot have been curated after the allegation.
- An insurance or contractual claim
- An insurer or customer asks what controls were in force at a specific time. The policy version on the receipt, plus the repository, evidences the control set as it stood rather than as it stands now.
That last point is the practical argument for doing this early: the value of the mechanism is retrospective, and it cannot be created retrospectively.
Next step
Hash-chained evidence, produced at decision time
BarzelVault writes a tamper-evident record for every one of its four policy outcomes, with the approval reference and policy version already in the record — which is what makes a later verification possible at all.
What receipts do not prove
Cryptographic evidence is narrower than it sounds, and overclaiming here damages credibility with exactly the audience receipts exist to satisfy.
- 01A receipt proves what was authorised and that the record is unaltered. It does not prove the action was correct, wise or lawful.
- 02It does not prove the upstream system did what it was asked. That requires the linked result record, and reconciliation against the upstream’s own state.
- 03It cannot cover actions that bypassed the decision point. A receipt series is complete only for the paths that pass through the engine, which makes credential consolidation part of the evidentiary story.
- 04Anchoring bounds but does not eliminate the window for undetected rewriting. Hourly anchoring means one hour, and that residual should be stated rather than glossed over.
Frequently asked questions
What is an AI action receipt?
A signed, tamper-evident record created at the moment a policy decision is made about an agent action, containing the action, an arguments digest, the full identity chain that authorised it, the policy version applied, any approval, and a hash link to the previous receipt.
How does a receipt differ from an audit log entry?
In timing and verifiability. A receipt is created before execution and signed with a key held by the decision point, so an external party can verify it. A log entry is written after the fact by the system that performed the action, in a store the same organisation administers.
What does non-repudiation mean for AI agents?
That whoever authorised an action cannot credibly deny having authorised it, because the record binds principal identity, the specific action, the policy in force and the time in a way that could not have been produced retrospectively.
What fields should an AI action receipt contain?
Twelve: receipt id, decision and signing timestamps, principal chain, authentication assurance, capability and tool with version, arguments digest, classified argument summary, decision outcome, rule and policy version, approval reference, upstream result reference, and previous hash with signature.
How does hash chaining protect an audit trail?
Each receipt includes a hash of its predecessor, so deleting, inserting or reordering any record breaks the chain from that point forward and localises the tampering. It does not by itself prevent wholesale rewriting by a holder of the signing key, which is what external anchoring addresses.
What is chain anchoring and why is it needed?
Periodically publishing the chain head hash to an independent timestamped location, such as an RFC 3161 timestamp authority. It makes wholesale rewriting detectable, because a rewritten chain will not reproduce a previously published head, and it bounds the undetected-rewriting window to the anchoring interval.
Do receipts require a blockchain?
No. Anchoring a chain head hash to an independent timestamp authority achieves the property that matters — an external party attests the chain existed in this state at this time — without operating consensus infrastructure or a distributed ledger.
How do I keep receipts from becoming a privacy liability?
Record a salted digest of canonicalised arguments plus a classified, thresholded summary rather than raw values. A specific disputed action can still be proven by recomputing the digest from a claimed argument set, without the sensitive values having been retained for years.
Who should hold the signing key?
The decision point, in a non-exportable hardware-backed or KMS-held key, never the system that executes the action. A receipt signed by the executing system proves only that the system reports having acted, which is the problem receipts exist to solve.
How does an external auditor verify a receipt?
Obtain public keys and validity periods from a location independent of the receipt store, verify each signature against the key valid at signing time, recompute the hash chain, reconcile computed heads against anchored values, recompute the argument digest against a claimed value, and check out the recorded policy version to confirm the rule produces the recorded outcome.
Should every agent action get a receipt?
No. Receipts are proportionate for consequential actions — money movement, irreversible changes, regulated data, and anything that required human approval. Routine internal reads should use ordinary structured logging, which is cheaper and sufficient.
What do receipts not prove?
That the action was correct, wise or lawful; that the upstream system did what it was asked, which requires the linked result record and reconciliation; and anything about actions that bypassed the decision point entirely.
Glossary
- AI action receipt
- A signed, chained record of a pre-execution authorisation decision about an agent action.
- Non-repudiation
- The property that an authorising party cannot credibly deny having authorised an action.
- Principal chain
- The ordered list of human and agent identities through which authority flowed to an action.
- Arguments digest
- A salted hash of canonicalised argument values, proving which arguments were used without retaining them.
- Hash chain
- A sequence in which each record contains a hash of its predecessor, making deletion and reordering detectable.
- Anchoring
- Publishing a chain head hash to an independent timestamped location at intervals.
- Counter-signature
- A second independent signature over a chain head, raising the bar for repudiation.
- Canonical serialisation
- A deterministic byte representation of a record, required for reproducible hashing and signing.
- Key validity period
- The published window during which a signing key was legitimate, needed for verification.
- Result reference
- A linked post-execution record connecting an authorisation to the upstream outcome.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · IETFRFC 3161 — Time-Stamp Protocol ↗How a third party attests that a record existed at a point in time.
- 02 · WikipediaMerkle tree ↗The structure behind append-only logs whose history cannot be silently rewritten.
- 03 · Certificate Transparency projectCertificate Transparency ↗A working example of tamper-evident public logs at internet scale.
- 04 · NISTNIST SP 800-92 — Log Management ↗Baseline expectations for log content, retention and integrity.
- 05 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 06 · EU AI Act (unofficial consolidated text)EU AI Act — full text ↗Obligations around logging, human oversight and traceability for higher-risk systems.
- 07 · U.S. SECSarbanes-Oxley Act — Section 404 ↗Where segregation of duties becomes an externally audited control.
- 08 · ISOISO/IEC 27001 — Information security management ↗The ISMS baseline that agent-layer controls have to fit inside rather than beside.
- 09 · OWASP GenAI Security ProjectOWASP Agentic AI — Threats and Mitigations ↗Threat taxonomy specific to tool-using agents rather than to chat completions.
- 10 · PCI Security Standards CouncilPCI DSS v4.0 ↗Where payment-adjacent agent actions inherit real, externally audited requirements.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). AI Action Receipts: Cryptographic Proof of What an Agent Was Authorised to Do. Real Biz Digital. https://realbizdigital.net/insights/ai-action-receipt/
Try the mechanics on a live server
To see what a tool-call envelope actually looks like before you write a policy that has to decide about one — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
BarzelVault is the pre-execution decision point, sold as a running product
Nine tools, 12 static resources, 3 resource templates and 9 prompts. Four deterministic outcomes — allow, deny, dry-run, require approval — with approval workflow, hash-chained audit and guardrail data protection. Streamable HTTP, JSON-RPC 2.0.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Dev | Free | 10,000 policy decisions/mo · 9 tools, 4 outcomes, hash-chained audit | A first regulated workflow: one agent, one high-consequence system |
| Team | $199/mo | 75,000 decisions/mo · approval workflow, spend and action limits | Several agents acting on money, records or customer-visible systems |
| Business | $799/mo | 750,000 decisions/mo · exact HTTPS execution, credential isolation, emergency controls | Enterprise-wide pre-execution enforcement under audit |
| Enterprise | $3,999/mo | 5,000,000 decisions/mo · everything in Business, scaled | Group-wide rollout across many teams and systems |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.