Signed execution receipts: a primer on why logs are not evidence

Every team running AI agents keeps logs. Almost none of them can answer the question that actually gets asked in a dispute: why should anyone believe them? A log is a record your system keeps about itself. It is useful for debugging, indispensable for operations, and — on its own — close to worthless as proof. This is a primer on the difference, and on what a signed execution receipt adds that a log cannot.

What evidence actually demands

Strip away the legal vocabulary and a record has to satisfy four things before a sceptical outsider should rely on it:

• Integrity. It has not been altered since it was created — and if it has, that fact is detectable.
• Attribution. Someone specific is on the hook for it. A record nobody vouched for commits nobody.
• Completeness. You are seeing the whole set, not a selection made after the fact by an interested party.
• Independence. The check can be performed by the doubter, without the cooperation of the party being doubted.

Note that admissibility is a much lower bar than any of this. English civil procedure will receive a business record in evidence without requiring a witness to speak to it (Civil Evidence Act 1995, s.9). Getting a log in front of a tribunal is easy. What the tribunal then decides it is worth is the entire question, and that is where ordinary logging collapses.

Where logs fail, property by property

An application log fails all four, and it fails them structurally rather than through bad implementation:

• Integrity: the log is a mutable file on infrastructure the operator controls. Anyone with disk or database access can rewrite history and leave no trace in the artefact itself. This is not a novel observation — computer-security guidance has said for two decades that log data requires explicit protection precisely because it is alterable by whoever holds the system (NIST SP 800-92), and the federal control catalogue carries a dedicated control, AU-9 Protection of Audit Information, for exactly this problem (NIST SP 800-53 Rev. 5).
• Attribution: the agent writes the log describing the agent. The witness and the accused are the same process. A misbehaving or compromised agent writes a clean log by construction.
• Completeness: what reaches an auditor is a filtered export — a date range, a grep, a dashboard screenshot. The absence of an entry is indistinguishable from an entry that was never emitted, dropped under load, or removed.
• Independence: verification means asking the operator for the file and believing what arrives. That is not verification; it is a courtesy.

The partial fixes, and where each one stops

The industry has good, real answers to pieces of this. It is worth being precise about what each one buys, because teams routinely believe they have solved evidence when they have solved storage.

• Centralised logging / SIEM. Moves the log off the machine that produced it, so a single compromised host cannot quietly rewrite it. Real improvement. But the collector is still operator infrastructure, so integrity now rests on the operator's word about the collector instead of about the host.
• Append-only and WORM storage. Prevents edits at the storage layer. Also a real improvement — and enforced by a policy the operator configures, can reconfigure, and is asking you to take on trust. It constrains the operator; it does not let an outsider check anything.
• Hash chaining. Each entry commits to the hash of the previous one, so removing or editing an entry breaks the chain — the idea behind digital timestamping since Haber and Stornetta (1991). This is genuinely strong, and it is why Traceseal keeps a hash-chained audit log underneath the receipts. Its limit: a chain proves internal consistency. Whoever holds the chain can rebuild it end to end and present a perfectly consistent alternative history, unless the chain is anchored to something outside their control.
• Trusted timestamps and transparency logs. The anchoring step. An RFC 3161 timestamp binds data to a time via a third party; a Merkle-tree transparency log in the RFC 9162 style makes it cryptographically awkward to show two different histories to two different observers. This is the piece that closes the "rebuild the chain" gap.

Read that list in order and a pattern emerges: each step moves a claim from "trust the operator's process" towards "check the maths yourself". A signed receipt is simply the end of that road, packaged so a single file carries the whole argument.

What the signature adds

An execution receipt is a self-contained JSON document recording one execution: which signed code ran, what it consumed and produced (as SHA-256 hashes, per FIPS 180-4, so the record proves integrity without exposing the data), the sandbox policy it ran under, and an Ed25519 signature (RFC 8032) over the lot.

Three design choices do the actual work:

1. The signature covers a canonical encoding. Keys sorted at every level, no whitespace, no booleans or nulls — so a given receipt has exactly one valid byte sequence. There is no room for a semantically identical but differently-encoded document to pass. Any edit anywhere breaks verification.
2. The public key travels inside the receipt. Verification is offline and self-contained: no key server, no API call, no account, no request to the operator. The doubter is not dependent on the doubted.
3. Hashes, not contents. Because inputs and outputs appear only as hashes, a receipt can be published without leaking the data it describes — and anyone holding the original data can recompute the hash and confirm the match.

Set against the four properties: integrity comes from the canonical signature, attribution from the operator key that signed it, independence from offline verification, and completeness from anchoring the record in a public transparency log. That last one is worth stating plainly, because it is the property most evidence schemes quietly skip.

The format is fully specified — the receipt specification is written so that a developer can implement a verifier in any language without touching our code, and the reference verifier is on PyPI. For a field-by-field walkthrough of a real receipt and what an [OK] does and does not prove, see how to verify what an AI agent actually did.

Why this is becoming a compliance question

The EU AI Act already distinguishes keeping records from being able to stand behind them. Article 12 of Regulation (EU) 2024/1689 requires high-risk systems to allow the automatic recording of events over their lifetime, to a standard appropriate for traceability. Article 19 requires providers to keep those automatically generated logs where they are under their control. The obligation is to produce a record that supports traceability — and a record that the producing party can silently rewrite supports it only as far as that party's credibility extends.

Nothing in the regulation mandates cryptographic receipts. But when the moment comes to demonstrate traceability to a regulator, an enterprise customer or an insurer, the difference between a log export and a signed receipt is the difference between asking to be believed and inviting a check.

What to ask of your own stack

• If an insider altered our records, how would we know? If the answer relies on that insider's access being correctly restricted, you have a control, not evidence.
• Can an outsider verify without our help? If verification requires you to hand over a file and be believed, the record proves nothing about your good faith to someone who doubts it.
• Is the record anchored outside our control? Internal consistency is not the same as an unrewritable history.
• Was it sealed at the time? Receipts only cover executions that were instrumented when they ran. Evidence collection that begins when the dispute begins proves nothing about what came before.