A QAR reviewer sits down with a control test workpaper. The conclusion says "no exceptions noted." The reviewer asks the audit lead the simplest possible question.
Why did it pass?
In a pre-AI world, the answer is in the workpaper. The procedure is documented. The samples are listed. Each sample has an evidence reference. The preparer's notes record any judgment calls. The reviewer's signoff confirms the chain held together.
The reviewer can re-perform any sample, walk back to the source document, and rebuild the conclusion from scratch if they want to. The defensibility chain is intact because every link is visible.
Now imagine the same workpaper, except an AI agent walked the samples instead of a human. The conclusion still says "no exceptions noted." The reviewer asks the same question.
Why did it pass?
If the AI's answer is "the model evaluated each sample and concluded no exceptions," the chain is broken. Not because the AI was wrong — maybe it wasn't — but because there is nothing to defend on if challenged. The reviewer can't re-perform a sample without retracing what the model actually did, and the model didn't keep notes.
The defensibility chain in agentic audit testing depends on one thing more than any other: the event log. Get it wrong and the audit isn't defensible regardless of how good the model is.
Why generic LLM logs aren't enough
Most AI tooling logs the model's inputs and outputs. Prompt in, completion out, maybe a timestamp and a model version. That's enough for debugging and not much else.
An audit event log needs to capture what the agent did inside the audit's data model — not just the model's prompt history. It needs:
- The audit entity the action touched (engagement, test step, sample row, evidence file)
- The actor (which agent, on whose behalf, under which auditor's session)
- The action class (executed test, recorded result, flagged exception, overrode prior result)
- The state before the action
- The state after the action
- The evidence the agent consulted (file IDs, row IDs, references)
- A timestamp the agent cannot rewrite
The model's prompt-and-completion log is useful context, but it's a sidecar — not the audit trail. The audit trail is the chain of state transitions inside the engagement's data model, with the actor, action, and evidence captured at each step.
Immutability is not a feature, it's a precondition
The most important property of the event log isn't structure — it's that nobody, not even the system that wrote it, can edit it after the fact.
This matters because the working theory of audit defensibility is that the trail of work is fixed. If an exception was flagged on day three of fieldwork and reversed on day five, both events must remain in the record. The reviewer needs to see that an exception was raised, who reversed it, and why. A trail that allows in-place edits removes that visibility.
Concretely:
- Event rows are append-only.
- Corrections happen by appending a new event ("override" or "reverse"), not by editing the prior event.
- The agent's actions cannot be retroactively redacted.
- Even deletes — when a piece of evidence is removed, say — leave an event behind that says "this was here, then it was removed, by this user, at this time."
Without these properties, the AI's actions become impossible to reconstruct. The convenience of a "clean" record after the fact is the same thing as the destruction of the defensibility chain.
What the ledger powers besides defensibility
The immutable event log has a primary purpose, which is auditability. It also has three secondary uses that justify the engineering cost on their own.
Replay. Given a sequence of events, the workpaper at any point in time can be reconstructed. If a reviewer asks "what did this look like before the manager's override," the answer is a query, not a rebuild. The chain is not just observable — it's traversable.
Anomaly detection. Patterns in the event log surface things that prose workpapers hide. If an agent is producing exceptions at an unusual rate, or accepting evidence the auditor would have rejected, the pattern is in the log. The same data shape that supports defensibility supports continuous quality monitoring of the agent itself.
Methodology evolution. Over time, the log accumulates a record of how the team's work has shifted — which test classes are most automated, where overrides cluster, how long review cycles take. That data feeds back into procedure design and training in a way that anecdotal review cannot.
These aren't selling points to be excited about. They are the natural consequence of building the trail correctly the first time. The teams that don't capture this data are doing the work and discarding the byproduct.
What goes wrong without it
Three failure modes recur in agentic AI audit deployments that skipped this layer.
Reviewer collapse. The reviewer cannot defensibly approve work they cannot trace. Once the reviewer realizes the trail is too thin, they either re-perform every AI sample (which defeats the leverage agentic execution was supposed to deliver) or sign off on faith (which is the failure mode that ends careers when a QAR comes through). Neither is sustainable.
Regulatory pressure. When a regulator asks "show me how the AI reached this conclusion," there has to be an answer that doesn't require an engineering team to extract logs from a black-box service. The answer should be a query against the workpaper, surfaced in the same UI the reviewer used. If extracting it requires a project, the regulator's confidence in the audit drops.
Loss of institutional knowledge. Audit functions accumulate knowledge in their working papers — what an exception looks like, what evidence is acceptable, which procedures are well-designed. When the AI's reasoning isn't captured, that knowledge accumulates in a place the audit team can't access. The vendor knows; the team doesn't.
What this looks like in practice
A clean agentic audit event log looks like a sequence of small, structured rows. Each row records one transition. Each row is immutable. Each row carries enough context — engagement, step, actor, action, before, after — that a reviewer can read it standalone and understand what happened.
It does not look like a chat transcript. It does not look like a prose summary. It does not look like a debug log from the AI vendor.
The ledger is the audit trail. The audit trail is the foundation of defensibility. The model's quality is a separate question — and a less important one in the regulator's eyes than most teams realize.
The AI doesn't have to be perfect. It has to be auditable.
That difference is the whole game.