Key takeaways
- Connect the sources, agent actions and human decision under a shared case identifier.
- Retain recorded explanations and stated confidence as outputs to evaluate, not proof of internal model reasoning.
- Test whether someone can reconstruct a case, and set retention periods with your legal and compliance teams.
When an agent supports a regulated or consequential decision, your record needs to be good enough to reconstruct that decision after the fact, not just prove the system ran. In practice, that means seven things: the session, the prompt and policy version that were live at the time, every source the agent read and when it read it, every tool call and what each sub-agent did, the agent’s recorded explanation and stated confidence, where available, every action that was refused, and the named human decision with its reason. Refused actions and the human decision deserve explicit attention when you design that record.
Why “we have logs” is not an answer
You probably do have logs. Request logs, application logs, maybe a trace viewer, and an audit table in the case management system. Consider an illustrative review: someone asks why a particular case was approved months ago, and your engineers have to reconstruct the answer across several systems.
The problem is that the evidence is spread across systems that were never designed to be read together, and the joins between them are weak. The trace viewer knows a model was called and how long it took. The case system knows a person clicked approve. Nothing in between records what the agent actually read, what it concluded, which version of your policy it was working from, or what it tried to do and was stopped from doing.
Your existing record-retention schedule already tells you how long to keep decisions in the workflows you are putting agents into. What it does not tell you is what an agent-supported decision is made of. That is the gap.
On retention periods: The schedule depends on the underlying activity, record category and jurisdiction. Your legal and compliance teams should determine the applicable period, access restrictions, deletion rules and legal holds. The checklist here is a proposed design, not a universal retention standard.
The seven things worth retaining
Start from the question you will eventually be asked, which is some version of “why did this happen and who decided it.” Work backwards from there and the list is short.
- Session identifier: One ID covering the whole run, from trigger to human decision. Without it you have events, not a case.
- Prompt and policy version: Which instruction set was live that day, and which version of your procedure it referenced. When you upgrade a model or edit a policy and behavior shifts, this is how you explain the difference.
- Sources read, with retrieval timestamps: Not just which systems, but what relevant data the agent retrieved and when it retrieved it. A registry value that has since been restated should not silently rewrite what the agent saw in March.
- Tool calls and sub-agent work: If an orchestrator dispatched specialists, each specialist’s inputs and outputs belong in the record. “The agent looked it up” is not evidence.
- Recorded explanation and confidence: The explanation it supplies for the finding and any confidence measure your workflow records. These are outputs to evaluate, not proof of its internal reasoning. Low confidence recorded honestly is worth more than a clean-looking answer.
- Refused and blocked actions: Anything the agent attempted that its permissions did not allow. This helps show how a control responded to an attempted action.
- The human decision: Which named person decided, what they decided, on what basis, and at what time. If they rejected something, the reason code.
Why refused actions matter as much as successful ones
They provide evidence of how a control responded to an attempted action.
Say your policy is that the agent cannot approve a customer, book a correction, or clear an alert. You can write that in a design document, put it in the system prompt, and say it in every demo. None of that proves anything to a person reviewing your controls twelve months later. Evidence of the control operating in a particular case is a record showing that on 14 March something attempted the posting action through the agent, the call failed, and the attempt was logged with a timestamp.
A log with no refusals in it is ambiguous. Maybe the boundary held. Maybe nothing ever pushed on it. Maybe the boundary was never wired up, and you would not know until the day it mattered.
This also changes how you should think about where the boundary lives. A rule enforced only through a system prompt is a weaker control: a sufficiently crafted input may talk the model past it. A boundary enforced at the orchestration layer means the action is not in the agent’s permitted set at all, so an attempt produces a hard failure you can point to. The second kind generates evidence. The first kind generates hope.
What breaks when you change the model or the prompt
Your history breaks, unless you version both. Here is the scenario that catches teams out. You ship an agent in January. In May you move to a newer model because it is cheaper and scores better. In September, someone reviews a January case and a May case side by side and asks why two similar situations produced different findings. If your records do not carry which prompt version and which model handled each case, you cannot explain the difference, which makes the review harder.
Treat the prompt like code. Version it, keep the old versions readable, and stamp the version onto every session. Do the same with the policy document the agent cites, because procedures get rewritten more often than anyone expects and the clause numbering moves.
There is a second-order benefit. Once you can group outcomes by prompt version, you can actually tell whether a change helped. Versioned records give your team a basis for comparison.
How to know your evidence is good enough
Run the reconstruction test before anyone external asks you to.
As an illustrative exercise, pick a closed case from an earlier reporting period. Hand it to someone who was not involved. Give them a fixed time, say an hour, and ask them to answer five questions from the record alone:
- What triggered this case?
- What did the agent read?
- What did it conclude, and how confident was it?
- What was it prevented from doing?
- Who made the final call, and why?
If they can answer all five in an hour, your evidence is in better shape. If they cannot, you have found your gap while it is still cheap to fix.
Do this quarterly, not once. Systems drift, integrations get added, and a record that was complete in March quietly stops being complete in July when someone adds a new data source that nobody wired into the session record.
Who is the record actually for?
Three audiences want different things from the same evidence, and your record needs to serve all three.
Internal audit and compliance want to see that the control operated as designed across a population, not just in one case. That means the record has to be queryable, not merely retrievable. “Show me every case in Q2 where the agent’s confidence was low and the officer approved anyway” is a reasonable audit question and a painful one if your evidence is a pile of JSON blobs in object storage.
An examiner wants a specific decision explained end to end, with the accountable person named. They are less interested in your architecture than in whether a human with authority reviewed the right evidence and left a reason.
Your own engineers want to debug. When an agent starts producing worse findings on one entity type, the record is where you look. This audience is usually the reason the evidence exists at all, which is why it tends to be shaped for engineers and not for the other two. Widening it costs little at build time and a lot afterward.
What does this look like in one workflow?
Take a commercial onboarding case where two sources disagree about an ownership percentage.
The record holds the session that started when the analyst triggered the evidence run. It holds the prompt version live that day and the version of the onboarding procedure the agent cited. It holds each source it read, the corporate registry and the tax extract among them, with the value each returned and the time it was retrieved, so the disagreement itself is preserved instead of resolved into an average. It holds the specialist agents that ran and what each returned. It holds the finding and the confidence attached to it.
It holds the fact that nothing approved the customer, because the approval action was never available to the agent, and if anything reached for it the attempt sits there as a failure.
And it holds the analyst who chose which source to trust, what they wrote in the rationale field, and the compliance officer who approved with a reason code, at a time.
Read that back in a year and you can answer the question. That is the whole test.
Where does a control plane fit into this?
Between your application and the models and tools your agents call, where it can connect activity routed through it.
The reason retention is hard today is that the evidence is produced in several layers and nothing joins them. The application knows the business case. The model provider knows the call. The tool knows the query. The case system knows the click. A control plane sitting at the orchestration layer can connect the portions of the run routed through it, which is what lets it write one structured decision record with a single session identifier while your existing logs carry on doing what they do for engineers.
Controls at this layer can enforce access boundaries and record their decisions. If an agent calls a tool that is not in its permitted set, the call is blocked there and the refusal can be written into the record. A rule living in a prompt cannot do that, because there is nothing to catch the attempt.
Two things follow that are worth asking any vendor about. Can you run population-level queries, not just retrieve one case? “Show me every session this quarter where confidence was low and the human approved anyway” is a reasonable internal audit question. And is the record readable by your own team without a support ticket, in your own cloud? Audit evidence you have to request from a vendor is a dependency you probably do not want in the middle of an examination.
The moring AI Control Plane is designed to sit at this orchestration layer, capturing policy decisions, tool calls, approvals, and evaluations in one reviewable record that runs inside your environment. For a deeper look at what that architecture involves, see Enterprise AI Architecture: Where an AI Control Plane Fits and Observability for AI Agents: Metrics, Traces, and Guardrails That Matter.
Capabilities to verify before deployment
Ask your implementation team to demonstrate which identities are recorded, where permissions are checked, and which actions can bypass the control path. Verify these against the version and integrations you intend to deploy. A product description is useful context; the deployed behavior is what your evidence record needs to establish.
Retention checklist
- Every session has a single identifier that ties the trigger to the human decision
- Prompt version and policy document version are stamped on each session
- Every source the agent read is recorded with its returned value and retrieval timestamp
- Every tool call and sub-agent invocation is logged with inputs and outputs
- The agent’s recorded explanation and any stated confidence are retained alongside the supporting evidence
- Every refused or blocked action is logged with a timestamp
- The human decision names the person, the basis, and the time; rejections carry a reason code
- The record survives model upgrades and redeployments without resetting
- Audit logs are queryable by session, agent, confidence level, and approval status, not just retrievable
- Retention period matches the underlying regulated activity for your workflow and jurisdiction
Reconstruction test (run quarterly)
As an illustrative exercise, take a closed case from an earlier reporting period. Give it to someone who was not involved. One hour, five questions from the record alone. If they cannot answer all five without messaging an engineer, you have a gap.
For related reading on the accountability side of this picture, see Who is accountable when an AI agent makes a bad decision?
Frequently asked questions
What is an AI agent audit trail?
An AI agent audit trail is a structured record that captures everything needed to reconstruct an agent-supported decision after the fact: the trigger, the sources read, every tool call and sub-agent action, the agent’s recorded explanation and any stated confidence, any actions that were refused, and the named human decision with its reason. It is different from an application log because it links all of these into a single reconstructable case, not just a sequence of system events.
What evidence do regulators expect when an AI agent supports a decision?
The evidence required depends on your regulator, the underlying activity and the records involved. The proposed checklist in this article covers: the session, the prompt and policy version in force, the sources read and when, the tool calls and any sub-agent work, the agent’s recorded explanation and any stated confidence, any actions that were refused, and the human decision with its reason. Your legal and compliance team should confirm which frameworks apply to your specific workflows and jurisdictions.
Why should refused agent actions be logged?
Because they show how the control responded to an attempted action. A record containing only successful actions cannot distinguish a control that held from a control that was never tested or never wired up. A logged refusal, with a timestamp, demonstrates the permission model operating.
Do we need to version system prompts for audit purposes?
For regulated or consequential workflows, yes. Version the system prompts and the policy documents the agent cites alongside them. Without a version stamped on each session you cannot explain why two similar cases months apart produced different outcomes, and you cannot tell whether a prompt change improved anything. Treat the prompt as code: versioned, readable, and recorded on every run.
Is an application log enough for AI agent auditability?
Rarely on its own. Application and trace logs record that a model was called and how long it took. They typically do not record what the agent read, what it concluded, how confident it was, which policy version applied, or what it was prevented from doing. Those gaps are exactly where the audit questions land.
How do we test whether our agent audit trail is complete?
As an illustrative exercise, take an older closed case, hand it to someone who was not involved, and give them an hour to answer five questions from the record alone: what triggered it, what the agent read, what it concluded and how confident it was, what it was prevented from doing, and who decided and why. Any question they cannot answer identifies a gap to investigate. Repeat quarterly, because coverage drifts as integrations change.
To scope what your agent-supported workflows currently retain and where the gaps are, book a discovery workshop with moring.
Sources and scope
- NIST AI Risk Management Framework 1.0: Voluntary risk-management framework. Its accountability and transparency discussion provides background for documentation and traceability. It does not mandate this seven-part checklist or a universal retention period.
- moring AI Control Plane: Product context for connecting policy decisions, tool calls and approvals. Verify coverage against the integrations and version you deploy, including paths outside the control plane.
The seven-part checklist and reconstruction exercise are the author’s proposed design, not a regulatory retention standard.