Cryptographic Audit Trails: Evidence a Regulator Can Inspect

Ask a team how they will explain an agent's decision after the fact, and the usual answer is "we log everything." Logs feel like accountability. There is a timestamped record, it goes to a central store, and when someone asks what happened you can go and read it. For a lot of systems, that is genuinely enough.

However, an ordinary log does not survive the one moment it exists for: a regulator, an auditor, or a court asking "prove this record was not altered after the decision, and prove nothing is missing." A standard log cannot answer that. It is writable, so entries can be changed. It is often written after the action, so it can lag or drop. And it has no internal structure that would reveal tampering, so a deleted or edited entry leaves no trace. When the stakes are an enforcement action, "trust our logs" is not evidence. It is an assertion, and the whole point of the exercise is that your assertion is exactly what is in question.

The reframe is to stop thinking about logging and start thinking about evidence: a record built so that its own integrity is provable, produced in a way that makes "we changed it later" or "an entry went missing" detectable rather than deniable. That is a different engineering target, and it has a well-understood shape.

Append-only and hash-chained: tampering becomes visible

Two properties turn a log into evidence, and they work together.

The first is append-only. Records can be added but never edited or deleted in place. There is no update operation and no delete operation, only append. That alone removes the most common way a record becomes untrustworthy, quiet after-the-fact editing, because the operation that would do it does not exist.

The second is hash chaining, and it is what makes append-only provable rather than merely promised. Each record includes a cryptographic hash of the record before it, so the entries form a chain where every link commits to its predecessor. Organize those hashes into a Merkle structure, a tree in which each node is the hash of its children, and you get a single root hash that summarizes the entire history. Change one field in one record, and its hash changes, which changes every hash above it, which changes the root. The alteration cannot hide. Anyone holding the old root can prove, mathematically, that the history was modified, and can prove it without trusting you at all.

That is the shift from "believe our log" to "verify our evidence." The integrity of the record no longer rests on your good word or your access controls. It rests on cryptography that an outside party can check independently.

WORM storage: the medium enforces what the software claims

Append-only in software is a strong discipline, but a sufficiently privileged operator, or a sufficiently determined attacker, can sometimes reach underneath it. For evidence that has to hold up under adversarial scrutiny, the storage medium itself should enforce the property.

WORM, write-once-read-many, storage does exactly that. Once a record is committed, the storage layer physically prevents it from being overwritten or deleted for a defined retention period, regardless of the caller's privileges. The guarantee no longer depends only on the application behaving correctly. It is enforced below the application, where even an administrator cannot quietly rewrite history. Combine WORM with hash chaining and you have both belt and braces: the medium refuses to let the record change, and the cryptography would reveal it if the medium somehow failed.

Written before the decision commits: no evidence, no decision

Here is the design choice that separates real evidence from a reconstruction, and it is the one most teams get backwards.

The evidence must be written before the decision takes effect, not after. This inverts the usual order, where a system acts and then, as a side effect, records what it did. In that usual order the record is an afterthought, and afterthoughts can fail: the action succeeds, the logging call throws, and now you have a decision with no evidence behind it. In a regulated process that is the worst of both worlds, a consequence in the world and no record of why.

So the sequence is enforced the other way. The system assembles the decision record and commits it to the evidence store first. Only once that write succeeds is the decision allowed to take effect. If the evidence store is unavailable, or the write fails, the decision does not proceed. No evidence store, no decision. The system fails closed: when it cannot prove what it is about to do, it refuses to do it. That single rule guarantees a property regulators care about deeply. There is no such thing, in this architecture, as a consequential action without a matching, tamper-evident record, because the record is a precondition of the action, not a byproduct of it.

What a decision record has to contain

Integrity is worthless if the record is empty of meaning. A tamper-proof log of "decision made: approved" proves only that you cannot alter a record that says nothing useful. So the content matters as much as the cryptography. A decision record fit for inspection should capture, at minimum:

• The decision and its verdict. What was decided, and under which explicit outcome (allow, allow-with-conditions, deny, or require-human).
• The inputs. The specific documents, data, and context the decision was made on, referenced so the exact evidence base can be reconstructed.
• The authority. Which agent identity acted, at which autonomy level, and under which version of policy.
• The policy evaluation. Which rules were applied and what each returned, so the "why" is explicit rather than inferred.
• The reasoning and grounding. The agent's justification and the cited sources behind each material claim.
• The human, where there was one. If the decision required a person, who they were and what they approved, closing the accountability loop.
• Time and chain position. When it happened and where it sits in the hash chain, so it can be located and verified.

A record with those fields answers the question an inspection actually asks: not just "what did the system decide?" but "on what basis, under whose authority, against which policy, and can you prove this account is intact?"

EU AI Act Article 12, and why this is not optional

This architecture is not gold-plating. For high-risk AI systems, it is moving toward being the baseline the law expects.

EU AI Act Article 12 requires high-risk AI systems to keep records, automatically logging events over the system's lifetime to a degree appropriate to their intended purpose, so that the system's functioning is traceable and its risks can be monitored after the fact. Read that requirement against an ordinary, editable, best-effort log and the gap is obvious. "Traceable" and "appropriate record-keeping" are not satisfied by a store whose integrity you cannot demonstrate and whose completeness you cannot guarantee. Append-only, hash-chained, WORM-backed evidence, written before the decision commits, is not a stricter-than-necessary interpretation of that article. It is a straightforward reading of what "records a supervisor can rely on" has to mean when the system is probabilistic and the decisions carry weight.

So the question to bring to your next review is not "are we logging our agents?" Everyone is logging something. It is can we hand a regulator a record of any single agent decision and prove, without asking them to trust us, that it is complete and was not altered after the fact? If the honest answer is no, you have logs. You do not yet have evidence, and evidence is what an inspection is for.

If you want to see what an inspectable decision record looks like on one of your real processes, book a meeting.