AI Audit Trail: The One That Can Prove Something

Joe BraidwoodCo-founder & CEO

July 2026 · 7 min read

Every serious AI deployment already has an audit trail. The open question is whether it proves anything. When an insurer asks how the loss happened, when an auditor tests whether a control actually fired, when opposing counsel starts discovery, the AI audit trail you kept becomes the only account of events there is — and a trail built from application logs is an account you wrote about yourself.

Logs are claims. They record what your own software chose to write down, in a store you operate, editable by the same people — or the same compromised agent — the record may later need to incriminate. Signed, hash-chained receipts are evidence: minted at the moment of the action, silent about protected content, and checkable by a third party who never has to take your word, or ours, for any of it.

This guide is about that difference: what an AI audit trail is, why the usual kind fails exactly when it is needed most, and the five properties that separate a log from proof.

Why audit trails that can't prove anything fail at claim time

The phrase has been circulating for a reason — “the audit trail that can't prove anything” is an accurate description of the default. Most AI audit trails are log pipelines: the application emits lines, a collector ships them, a dashboard renders them. That is useful for debugging and operations. It was never built to survive an adversarial reader, and claim time is when the adversarial readers arrive.

Take a hypothetical — call the company nimbus. An agent with tool access approves a refund it should have escalated, and the customer dispute becomes an insurance claim. The insurer asks for the record of what the agent did and which controls fired. Nimbus exports its logs. The insurer's first questions are provenance questions: who wrote these entries, when were they written, and what prevented anyone from editing them after the incident? A database export has no answers. The trail exists, but it cannot prove anything, so the claim turns on credibility instead of evidence.

An auditor's version of the same moment: the control was configured, and the policy document says so — but configuration is intent. The auditor wants evidence that the control executed on the specific action in question. In litigation it is worse: a mutable record authored by the defendant is a gift to the other side.

None of this is an argument that better records would have stopped the refund. They would not have. We can't stop the next one either — no honest vendor can promise that. What can be built is a trail that makes what happened provable, so the argument after an incident is about facts rather than about whose logs to believe.

And it cannot be retrofitted. Provenance is not something you add to a record after the incident — by then the moment has passed, and anything you sign later only proves when you signed it. The integrity has to be there from the first action, written into the record as the record is made. That is the requirement claim time imposes, and it is worth taking seriously before claim time arrives.

What an AI audit trail actually is (and isn't)

An AI audit trail is the record of what an AI system did: the model calls, the tool invocations, the policy decisions — permit, deny, override, escalate — and the exceptions a human applied. To qualify as an audit trail rather than an operations log, that record has to carry enough integrity that someone other than the operator can check it. If the only way to trust the trail is to trust the party that produced it, it is a diary, not an audit trail.

Three things it is not. It is not a log aggregation layer — aggregation moves claims around; it does not strengthen them. It is not the governance dashboard — governance tools state intended behavior, and a green dashboard asserts that controls exist without proving any one of them fired. And it is not the policy document, which describes what should happen and is silent on what did.

The subject of the trail is the action boundary — the moment the model's output becomes a tool call that sends the email, runs the query, moves the money. That is where AI agent security has to live, and it is where the trail has to be written. A record written anywhere else is a recollection.

The five properties that separate a log from evidence

Five properties turn a record into evidence. Missing any one of them hands the adversarial reader a place to stand.

1. Signed at the moment of the action. The signature is minted inline, when the action happens — not batch-applied at export. A trail signed at export time proves when you exported it. Only a signature created at the moment fixes the record to the event.
2. Content-free. The trail carries hashes, counters, and labels — never prompts, outputs, or personal data. That is what lets the evidence cross the trust boundary: the content never does. An audit trail full of prompts is a data-liability incident waiting for a subpoena.
3. Hash-chained. Each entry commits cryptographically to the one before it. Remove an entry, reorder two, or rewrite one, and verification fails. This is the construction behind certificate transparency (RFC 6962), and it is what makes a trail tamper-evident rather than merely tamper-resistant.
4. Independently verifiable offline. Verification runs against a pinned public key, with no call to the vendor's API, no account, no permission — the check is math, not a phone-home. If checking the trail requires trusting the party that produced it, you have a claim with extra steps. Independence is a structural property of the attestation, not a marketing one.
5. Append-only. Nothing is edited and nothing is deleted; corrections are new entries that reference what they supersede. A trail that allows quiet edits allows a quiet history.

One limit, stated plainly: receipts prove faithful recording, not that every action was captured. Completeness is a coverage question — which actions were in scope, which were excluded, and the denominators behind any percentage you claim. An honest trail reports coverage as intervals and sample sizes an auditor can reproduce, not as the word “comprehensive.”

How a signed receipt works

The mechanism is a guard that sits in the action path — a proxy between the agent and its tools. Policy is applied inline: permit, deny, override, or escalate, decided at the moment of the tool call, not reviewed after it. Each decision mints a receipt. The receipt records that a control ran and what it decided.

What the receipt carries is deliberately thin: a hash of the action and its context, the policy decision, a sequence counter, and scope labels identifying which control fired. What it omits is the point — no prompt text, no response bodies, no personal data. The receipt proves a specific governed action occurred without disclosing anything the action touched, so the evidence can travel to an insurer, an auditor, or a courtroom while the content stays home.

Three standards do the work. The receipt's fields are serialized with JCS (RFC 8785), so the bytes being signed are deterministic — canonicalization is what lets a verifier anywhere reproduce exactly what was signed. The signature is Ed25519: compact, fast, and checkable against a 32-byte public key. And receipts are chained in a transparency log built on the RFC 6962 Merkle-tree construction, so the sequence itself is provable — not just each entry, but the order, and the absence of gaps where an entry used to be.

Verification runs against a pinned key — published once, fixed in the verifier — so no one needs to fetch key material from us at check time, and a compromised key server cannot substitute a different one. Anyone can verify offline, with no trust in Glacis: the evidence stands on the signature and the chain, not on our say-so.

What crosses the boundary is only ever hashes, counters, and labels — you can verify a receipt without exposing the data it describes. The format itself is OVERT, an open, royalty-free receipt standard published at overt.is, so the trail outlives any single vendor — including us.

How to check one yourself

The fastest way to understand the difference between a claim and evidence is to run the check. The verify page takes a receipt and checks the Ed25519 signature and the hash chain in your browser, against the pinned key. Nothing is uploaded; there is no account. If the receipt verifies, you hold proof that a specific control fired on a specific action at a specific time. If it does not, you have learned something the dashboard would never have told you.

To see what an auditor or an insurer would actually receive, the sample evidence pack assembles a signed runtime receipt into the artifact a review meeting consumes — the receipt, the verification result, and the coverage accounting that travels with it.

If your AI audit trail has to survive an insurer, an auditor, or a court, get runtime coverage and see what signed enforcement looks like against your own tool calls. The standard behind the receipts is open — read it at overt.is.