Why cryptographic execution receipts will change the way you audit AI agents
The era of trusting AI logs is over.
We argued in Logs are not receipts that logs are written by the system under investigation, which disqualifies them as evidence in any serious dispute. This post goes further: what comes next, what Sequesign actually builds, and what regulators are likely to ask for once "I have logs" stops being a defensible answer.
What's wrong with logs, in four properties
Audit logs lack four properties that evidence needs:
Integrity. The system that wrote the log can rewrite the log. Standard log storage solutions add tamper-resistance to the storage layer, but the original writer is still the system being audited. That's not integrity in the evidentiary sense.
Attribution. When a log says "agent decided X," it does not prove which specific agent instance, which specific key, or which specific principal authorized X. The string in the log is the agent's claim about itself.
Continuity. A log can omit a step, reorder steps, or insert steps after the fact, and the result still parses as a valid log. Nothing about the log format forces the sequence to be intact.
Authenticity. There is no cryptographic link between the agent's stated intent at the start of a task and the actions the agent actually took. The agent's narrative of what it did is just text the agent produced.
A Sequesign receipt addresses each of these by construction, using primitives that have existed for decades. The novelty is the application, not the cryptography.
The protocol, in primitives you already know
Sequesign uses SHA-256 for hashing and Ed25519 for signatures. Both are widely deployed, well-audited, and don't require anyone to trust Sequesign's choice of cryptography. The receipt format is canonicalized JSON, hashed at the canonical-byte level so two implementations agree on what was signed.
Every action an agent performs generates a canonical record. The record commits to:
- The evidence the agent acted on (hashed, not embedded in the record itself).
- The previous chain state (the cumulative hash of every prior action in this chain).
- The new chain state (a deterministic function of the previous state and the current action).
The agent signs the record with its own Ed25519 key. An independent witness service signs the chain extension. If a human approval is required, the human signs separately with their own key. Each signature is over a canonical message that includes the action's evidence hash and the chain state transition, so the signature cannot be detached from the specific work it attests to.
The receipt that results is a package: a receipt envelope, a journal of action records, the underlying evidence, and the public keys needed to verify everything. The package is portable. A reviewer with no relationship to Sequesign and no internet connection can still verify it, because verification is local and deterministic.
What a receipt commits to
A Sequesign v0.5 receipt is a directory or zip file with a fixed structure:
receipt.sequesign/
receipt.json receipt envelope with metadata, chain id, schema bindings
actions.jsonl one action record per line
evidence/ hashed evidence content
act_001_task_created.json
act_002_policy_checked.json
...
attestations.json agent, witness, human, counterparty signatures
keys/ public keys for verification
agent.pub.pem
witness.pub.pem
verification-report.json output of the last verifier run (optional)
The envelope at the top declares the chain id, the receipt mode (freeform, schema-validated, or profile-constrained), the schemas and profile in use if applicable, and the final chain state. Everything else in the package is content the envelope references by hash. Change a single byte of evidence after the fact and the hash no longer matches; the verifier rejects the receipt with a specific reason and the action that failed.
Verification, with no service to call
The verifier walks the package and produces a structured report:
{
"valid": true,
"receipt_id": "rcpt_8f3a4c2e91d7b6a8",
"chain_id": "chn_7f3a4c2e91d7b6a8",
"verification_level": "L4_HUMAN_APPROVED",
"mode": "profile_constrained",
"profile": "sequesign.invoice_payment.v0.1",
"flags": {
"hash_integrity": true,
"sequence_integrity": true,
"schema_validation": true,
"workflow_profile": true,
"agent_identity_bound": true,
"witness_verified": true,
"policy_bound": true,
"human_approval_verified": true,
"counterparty_confirmed": null
},
"warnings": [],
"reason": null
}
The flags are the truth. The verification_level is a summary label derived from the flags. A null flag means the receipt did not request that property, not that the property failed.
When verification fails, the report identifies the action and the reason:
{
"valid": false,
"reason": "evidence_hash_mismatch",
"action": {
"sequence": 3,
"action_type": "llm_invoice_reviewed"
},
"expected_evidence_hash": "a3f7b8c2e91d4f6a2c8e1f3b9d6c5e7f",
"computed_evidence_hash": "b2e8f4a7c93d5a1e3b7c9f2d8a4e6c1b"
}
There is no model inference, no heuristic, no scoring. The verifier is deterministic by design: every implementation, given the same inputs, produces the same report.
What a receipt proves, and what it does not
Honesty about scope is the difference between a usable trust primitive and a marketing claim.
A valid Sequesign receipt proves:
- The evidence has not been changed since the receipt was constructed.
- The action sequence is intact: no steps were removed, reordered, or inserted after the fact.
- The agent signed each action with the key the receipt declares.
- The witness signed each chain extension with its published key.
- If the receipt was bound to schemas, every piece of evidence conforms to the declared shape.
- If the receipt was bound to a workflow profile, the sequence satisfies the profile's rules.
- If the workflow required human approval, the approval was signed by the right key.
A valid receipt does not prove:
- That the agent told the truth. The agent's natural-language summary of what it did is committed to, but unattested. The receipt makes the gap visible; it does not close it.
- That external data the agent acted on (an invoice, a contract, a vendor record) is itself authentic. That requires separate attestations from the upstream parties, which the receipt can include but does not generate.
- That an LLM provider attested to its own output. No major provider does this today. When they do, the protocol can include their signature in the chain; until then, LLM outputs are agent-asserted.
- That a downstream system (a payment processor, a clearing house, an API) confirmed receipt of the action. That's a separate proof-of-settlement that lives in its own chain.
The receipt's job is to make the trust gap visible, not to pretend it doesn't exist. A receipt with no external attestations on content-level claims is still defensible against the "agent rewrote its own logs" attack, the "agent skipped a required approval" attack, and the "evidence was modified after the action" attack. Those are the attacks that matter for cryptographic auditability.
What's on the roadmap
Two protocol-level features are in design that extend what a receipt commits to.
Delegation manifests. Today, a receipt commits to what an agent did. A delegation manifest commits to what an agent was authorized to do, signed by the delegator before execution begins. The manifest is witnessed at delegation time, which means the rules the agent operated under cannot be rewritten after the agent's behavior is known. This is the cryptographic answer to "the agent's policy was suspiciously well-suited to its outcome."
Self-describing receipts. The receipt wire format already reserves optional fields for schemas to be carried in the receipt package itself, rather than resolved from a central registry. When that activates, a relying party can verify a custom-schema receipt offline with no dependency on Sequesign's registry or even Sequesign existing. The primitive stays open; the operational layer (hosted registries, schema curation, signed manifests) is what Sequesign offers as a paid service.
Neither of these is required for the trust properties the receipt already provides. Both extend the protocol in directions that customer use cases are pulling toward.
Why this matters now
In sectors where AI-mediated decisions are starting to carry regulatory weight, "I have logs" is the entry-level answer. Within the next 18 months, the bar will move. Regulators are already asking for proof-of-process, not narrative. Counterparties are already asking how to verify what an agent did without trusting the agent's platform. Insurers are already asking what evidence holds up in an arbitration. None of these audiences are satisfied by a log file produced by the system they are investigating.
A Sequesign receipt is the artifact that travels. It is verifiable offline by anyone who has it. It separates what the protocol can prove from what is agent-asserted. It is the smallest unit of cryptographic auditability that an AI workflow can produce.
The protocol is open. The reference implementation is public. The infrastructure (hosted witness, evidence storage, receipt library, billing) is what Sequesign offers as a service.
If you are building AI agents, evaluating them, or have to defend their decisions to someone else, this is the trust primitive your stack is missing.