What an auditable agent run actually contains
Every vendor says their platform is auditable. Very few can show you a single run, six months later, and answer what the agent did, what it was looking at, and who allowed it. This is what the record has to hold.
Srini Sandaka
Chief Technology Officer, MOURI Tech
· 10 min read
"Is it auditable?" is the question that decides whether an agent reaches production in a regulated enterprise, and it is almost always answered too quickly. Every platform logs something. The distance between logging and evidence is where programmes stall, usually about four months later than anyone expected.
This paper sets out what a run record has to contain to survive a real review, why reconstruction is not the same as replay, and where the cost of getting it wrong actually lands.
The question a reviewer is really asking
When a risk function asks whether an agent is auditable, they are not asking whether it produces logs. They are asking whether, at an arbitrary point in the future, you can answer four questions about one specific decision:
- What did the agent actually do — every action, in order, including the ones that failed?
- What was it looking at when it decided? Not which documents exist, but which passages were in front of the model at that moment.
- Who allowed it? Which policy permitted the action, and if a human approved it, which human and on what basis?
- Would it do the same thing again, and can you show that rather than assert it?
Application logs answer the first question partially and the other three not at all. That gap is not a tooling detail. It is the difference between a control you can evidence and a control you can only describe.
The anatomy of a defensible run record
A run record that holds up under examination contains, at minimum, the following — captured as the run happens, not assembled afterwards.
The trigger and its identity
What started the run, on whose behalf, and under which agent version and policy pack. Version matters more than teams expect: an agent that behaved correctly in March may be a different agent by June, and evidence that cannot name the version it describes is evidence about nothing in particular.
Retrieved context, with citations that resolve
Not "the agent searched the knowledge base" but the specific passages returned, ranked, and passed into the prompt — each traceable to its source document and location. A citation that names a file is weak. A citation that opens at the page the claim came from is evidence.
Every tool call, with arguments and results
Each invocation recorded with what was sent, what came back, how long it took and what it cost. Including the calls that errored, and the calls the model attempted but policy refused. A record that only contains successful actions is a record of a story, not of a run.
Policy evaluations as first-class events
Every point at which the platform checked an action against the agent's policy pack, and what it decided. This is the part most implementations miss. If policy is enforced but not recorded, you can tell a reviewer the control exists; you cannot show it firing.
Human interventions, attributed
Which approvals were requested, who they went to, what they saw when they decided, what they chose, and how long it took. An approval workflow with no record of what the approver was shown is not an approval workflow; it is a delay.
Reconstruction is not replay
Most teams that say they have audit have reconstruction: logs across several systems that a capable engineer can piece together into a plausible account of what happened. This works, slowly, until it matters.
Reconstruction has three failure modes under scrutiny. It depends on the person doing it, so two engineers can produce two accounts. It silently loses whatever was not logged — usually the model's intermediate reasoning and the context it was given. And it degrades with time, because log retention policies were set for debugging, not evidence, and the useful detail expires first.
If producing the evidence requires an engineer, an afternoon and a judgement call, it is not a control. It is an investigation.
Replay is different in kind. The record is complete at the moment it is written, structured, and addressable, so retrieving it is a lookup rather than a project. That property is what makes evidence something the platform produces rather than something the team assembles.
Retention: two obligations pulling opposite ways
Audit evidence and data minimisation are in direct tension, and this surfaces late. Your risk function wants records kept long enough to answer questions about past decisions. Your privacy obligations require that personal data is not kept longer than necessary. A run record contains both the decision trail and, frequently, the personal data the decision was about.
The workable answer is retention configured per space and enforced automatically, so records expire on a defined schedule rather than accumulating until someone notices. The unworkable answer — and the common one — is indefinite retention that nobody has reviewed, which converts an audit asset into a liability.
What this does not give you
It is worth being precise about the limits, because overclaiming here is how trust is lost with exactly the audience this is meant to convince.
- A complete record does not make a decision correct. It makes a wrong decision explicable, findable and fixable, which is a different and lesser thing.
- It does not explain the model's internal reasoning. It records what the model was given, what it produced and what it attempted — not why the weights produced that output.
- It does not substitute for evaluation. Knowing what happened in production is not the same as knowing the agent performs well across the cases it has not met yet.
- It does not remove the need for human judgement on which actions warrant approval. The platform enforces the policy; it does not write it.
Build or buy
Everything above is buildable. Teams do build it, and the first version usually takes a quarter. The cost that is consistently underestimated is not the build — it is that this becomes an internal product with a permanent owner, a schema that has to evolve as agents gain capabilities, a retention mechanism, a query surface, and a UI that non-engineers can actually use during a review.
That is a reasonable thing to choose deliberately. It is an expensive thing to choose by accident, and most organisations choose it by accident — by starting with primitives, shipping the first agent, and discovering the evidence requirement only when the second one goes near a regulated process.
Srini Sandaka
Chief Technology Officer, MOURI Tech
Chief Technology Officer at MOURI Tech, responsible for the architecture behind MouRio and how it is deployed inside customer environments.
