ExecLayerDeterministic Execution Governance

Cryptographic Receipts

Receipts for AI Agent Actions

A signed record of what an agent was permitted to do, what it was refused, and which policy decided. Verifiable by someone who trusts nobody involved.

What is a cryptographic receipt for an AI agent action?

A cryptographic receipt is a signed, tamper-evident record produced at the moment a policy decision is made, binding the proposed action, the authority behind it, the policy version in force, and the resulting verdict into one artifact that a third party can verify without trusting the system that issued it.

The market calls these agent action receipts, signed audit evidence, or cryptographic audit trails. ExecLayer calls its implementation an authority receipt, because the thing it binds is authority rather than a transaction. The vocabulary varies. The requirement underneath it does not, and it is sharper than it first appears: the artifact has to be produced by the decision, not about it.

This page shows a real receipt emitted by the ExecLayer kernel, walks its fields, and explains how to verify one.

How is a receipt different from an audit log?

A log entry is a description of an action, written after the fact by the system that took it. A receipt is a product of the decision itself, created in the same step that authorized or refused the action and signed before the action was allowed to proceed. Nothing downstream can produce one retroactively, which is what makes it evidence rather than testimony.

The practical problem receipts solve is circularity. When an AI system takes an action nobody expected, the investigation usually depends on records written by that same system. If the behavior under review includes how the system reported on itself, those records are the thing in question rather than the answer to it.

There is a second failure that shows up later. Policy moves. Rules are edited, thresholds tightened, exceptions expire. Six months after an incident the question is never what the policy says, it is what the policy said at the moment of the decision. A log names a policy. A receipt carries the policy's content hash, so that question has one answer instead of an archaeology exercise across change tickets.

A real receipt

Below is an actual receipt captured from the ExecLayer kernel. The subject is a rover, the operation is a thrust adjustment, and the requested magnitude was nineteen times the granted bound. The verdict is a refusal. Identifiers are demo subjects, the cryptography is real.

{
  "envelope": {
    "receiptId": "rcpt-G1-msi6fhqi",
    "issuedAt": "2026-08-06T23:58:27.210Z",
    "parentReceiptHash": "f9ec732cc15af5d93d0b94f5a3621ae083cee10701fe8db39ed8c59ebd6dafa4",
    "sessionId": "GOV-SESS-11DC4A75BFF91814",
    "issuerKeyId": "5c12d55123f0a569",
    "baselineVersion": "3.0"
  },
  "decisionCore": {
    "decision": "REFUSE",
    "reasonCodes": ["PARAMETERS_INVALID", "EFFECT_BOUND_EXCEEDED"],
    "ruleTrace": [
      { "ruleId": "G-struct",    "result": "ALLOW"  },
      { "ruleId": "G-epoch",     "result": "ALLOW"  },
      { "ruleId": "G-temporal",  "result": "ALLOW"  },
      { "ruleId": "G-catalog",   "result": "REFUSE", "reasonCode": "PARAMETERS_INVALID",
        "facts": { "operation": "THRUST_ADJUST", "errors": ["$.delta_v: > maximum"] } },
      { "ruleId": "G-grant",     "result": "ALLOW"  },
      { "ruleId": "G-bounds",    "result": "REFUSE", "reasonCode": "EFFECT_BOUND_EXCEEDED",
        "facts": { "param": "delta_v", "bound": { "min": 0, "max": 0.5 }, "actual": 9.5 } },
      { "ruleId": "G-target",    "result": "ALLOW"  },
      { "ruleId": "G-invariant", "result": "ALLOW"  }
    ],
    "riskTier": "HIGH",
    "operation": "THRUST_ADJUST",
    "subject": "rover-7",
    "grantId": "G1",
    "grantContentHash": "dd92592c696b107f9786567951725d2d73af0cec3ea365ebf005934e9bf82d9d",
    "evaluationEpoch": 1786060706,
    "catalogVersion": "DEMO-CAT-1",
    "invariantSetId": "DEMO-INV-1",
    "intentHash": "6d3b2ebce1baa7891fdc4835cb998033e367622e4e3f613ba933bbc100eead71",
    "authorityHash": "187de586b814980dc27df75f0a973ca653ef10cd6a2e84c579ff7e501c7cd5c2"
  },
  "decisionCoreHash": "2c9f43e94821c35f5f5a650b3a347b4048fd6c87228afc3dc214aea96ac051d6",
  "signature": {
    "algorithm": "ed25519",
    "keyId": "5c12d55123f0a569",
    "publicKeySpkiB64": "MCowBQYDK2VwAyEA745445sbeB72Vjh20M0xM3XmOsZVGgYR8JZHYqbQFr8=",
    "value": "M5oCe9hihlTbeRdPZTbY4zw8D/j2Ax8rDAJGtAXRW76OdlRxnEmRavy4uZC54znBd7vtmp9zBGTdQQrzG299AQ==",
    "keyStatusAtIssue": "active"
  },
  "nextParentReceiptHash": "c84ee847e2d6b781f5182ba65cac23000c772fe367666acc1da4953fec410f3e"
}

Captured from the ExecLayer kernel on 2026-08-06. The rule trace is abridged for width; every gate shown ran in this order. You can generate your own on the live kernel.

Generate a receipt yourself The formal definition

What each field is for

Field What it binds Why an auditor needs it
intentHash The canonicalized action that was proposed Two differently worded requests for the same effect produce the same record, so intent cannot be laundered by rephrasing
subject The actor the decision was about Names who was acting, independently of which process happened to make the call
grantId and grantContentHash The authority relied on, by content rather than by name Answers what the grant actually said at the time, not what the grant with that name says now
authorityHash The full authority state in force at evaluation Covers the grants, bounds, and targets together, so a partial disclosure cannot misrepresent the picture
ruleTrace Every gate that ran, its result, and the facts it saw Turns a verdict into a reviewable derivation instead of an opaque outcome
decision and reasonCodes Allow, refuse, or escalate, with the rules that produced it Distinguishes a grant drawn too tightly from an agent behaving wrongly
evaluationEpoch The authority epoch the decision ran against Detects a decision replayed against stale authority after a revocation
decisionCoreHash A commitment to the entire decision content Any edit to any field changes this value
signature An Ed25519 signature over the record, with the key id and key status at issue Proves origin, and shows whether the signing key was active or already revoked when the record was made
parentReceiptHash The position of this receipt in the chain A deleted or reordered record breaks verification for everything after it, so removal is detectable rather than silent

Do refused actions get a receipt?

Yes, and this is the half most systems lose. A denied action leaves exactly the same class of artifact as an approved one. An organization that can only prove what it did, and not what it declined to do, cannot demonstrate that a control was working during the period when nothing went wrong.

Think about what an auditor is actually asking when they sample-test a control. Not "show me that nothing bad happened," which is unfalsifiable, but "show me the control firing." A receipt stream containing refusals is that demonstration. It shows the boundary rejecting attempts, with the reason codes and the facts, across the whole period under review.

The refusal record also carries operational value that has nothing to do with compliance. Refusal patterns are the highest-signal feedback available about the gap between what agents attempt and what authority covers. A grant that refuses constantly is drawn wrong. An agent that trips the same bound repeatedly is misconfigured. Both are visible only if the refusals were written down.

If there is no cryptographic receipt per decision, it is monitoring, not governance.

How do you verify a receipt?

Recompute the hash of the decision core and check the Ed25519 signature against the published key named in the receipt. Then confirm the chain: each receipt commits to the hash of the one before it, so a removed or reordered record breaks verification for everything that followed. None of this requires the issuing system to be online or trusted.

Three checks, in order:

  1. Integrity. Canonicalize the decision core and hash it. If the result does not equal decisionCoreHash, a field was edited after issue.
  2. Origin. Verify the signature over that hash against the key identified by keyId. The receipt carries that key as publicKeySpkiB64, so any standard Ed25519 implementation checks it today with no ExecLayer code involved. For adversarial review, resolve the key independently rather than trusting the copy inside the receipt, because a forged receipt can carry its own forged key. Check keyStatusAtIssue too, since a signature from a key that was already revoked is valid cryptography and invalid evidence.
  3. Position. Walk parentReceiptHash backwards. A gap means a record was removed. A mismatch means the sequence was altered.

ExecLayer's commitment is that verification is never metered and never gated, in any form we ship. That is not generosity. If verifying a receipt requires the issuer's account or invoice, the receipt stops being independent evidence and becomes a vendor assertion, which collapses the entire claim.

To be precise about what exists today rather than what is planned: the receipt format above is self-describing, so verification is already possible with off-the-shelf cryptography and no ExecLayer software. Published verifier libraries, a command line tool, and a key discovery endpoint that resolves a signing key without reference to the receipt are on the roadmap and are not shipped. Ask for them by name before assuming any vendor in this category, including this one, has them.

Why does verification have to work offline?

Because if checking a record means calling an API owned by the party whose behavior is under review, the record is a vendor assertion rather than independent evidence. Offline verification against a published key is the property that lets an auditor, a regulator, a counterparty, or opposing counsel reach a conclusion without taking anyone's word for it.

Apply the test to any vendor claim about AI audit trails, including this one. Can a party who distrusts the vendor, the operator, and the agent still reach a conclusion from the artifact alone? If the answer requires anyone to be online, cooperative, or honest, the artifact is documentation rather than evidence.

This is also why receipts matter more than dashboards in regulated settings. The EU AI Act's record-keeping obligations for high-risk systems, and the evidentiary expectations in financial and healthcare supervision, are all questions about what can be shown to someone outside the organization. A dashboard shows a state. A receipt survives being handed over.

Record-keeping under the EU AI Act How the chained ledger works

Receipts alone are not governance

Signed, hash-chained, offline-verifiable receipts are now table stakes in this category rather than a differentiator. Several open specifications and products ship them, and that is good for everyone: a format only one vendor can read is not an evidence standard.

The honest distinction is upstream of the artifact. A receipt is only as meaningful as the decision it records. Signing the output of a probabilistic classifier produces a cryptographically perfect record of a decision that would have come out differently on a different day. The evidence is unimpeachable and the control is not reproducible.

What makes an ExecLayer receipt worth verifying is the deterministic gate sequence behind it, the parameter bounds it evaluates, the fail-closed posture when the boundary is unreachable, and the fact that the decision replays: feed the same intent and the same authority state back through evaluation and you get the same verdict. Receipts are the evidence layer. Determinism is what makes the evidence mean something.

Evidence and further reading

The receipt architecture described here is published and citable. ExecLayer holds seven provisional patent filings covering deterministic governance enforcement, authority receipts, runtime policy bundles, and governed agent supply-chain control.

Request a demo Full research archive

Related reading