Key takeaways
- A decision record captures one decision. This post is about the trail those records sit in, which is what a CISO or internal auditor tests. For the control layers that feed the trail, see our risk and control framework.
- The trail has to be correlated, time-consistent, protected from alteration, kept for the right period and readable only by the right people. Each property maps to a NIST SP 800-53 AU control.
- One correlation ID should travel from the user’s request through the agent, the gateway and tool calls, the human approval, and into the downstream system change.
- Test the trail directly: reconstruct a past action backwards from the system it changed, and try to alter a record to confirm the change is detected.
When an agent changes something in a regulated system, two questions follow. The first is what happened in that case: what the agent read, what it did and who decided. Our companion piece, What to Retain When an AI Agent Supports a Decision, covers that content in detail, and this post does not repeat it.
The second question comes from the CISO, internal audit, or an examiner who has already seen your decision records: why should I believe them? Could someone have edited a record after the fact? Do the timestamps from five systems agree? Can you join the agent’s activity to the change it made in the core system? Who can delete these records, and has anyone? Those are questions about the trail as a system, and they are the subject here.
What an auditor checks about the trail
Security teams already have a vocabulary for this in the AU (Audit and Accountability) family of NIST SP 800-53 Rev. 5. Nothing in the catalog is specific to AI agents, which is useful: you can hold agent activity to controls your organization has already selected and parameterized, instead of inventing a separate standard.
| Property of the trail | SP 800-53 Rev. 5 controls | What to check for agents |
|---|---|---|
| Complete | AU-2 Event Logging; AU-12 Audit Record Generation | The event list covers model calls, tool calls, refusals, approvals and downstream writes, and each component in the path generates them |
| Attributable | AU-3 Content of Audit Records; AU-10 Non-repudiation | Each record names the agent identity and the person or service it acted for; approvals are tied to a named, authenticated individual |
| Correlated | AU-6(3) Correlate Audit Record Repositories; AU-12(1) System-wide and Time-correlated Audit Trail | One ID joins records across the case system, agent runtime, gateway and target system |
| Time-consistent | AU-8 Time Stamps; SC-45(1) Synchronization with Authoritative Time Source | Timestamps in UTC or with an explicit offset, clocks synced to an authoritative source |
| Intact | AU-9 Protection of Audit Information, with (2) separate storage and (3) cryptographic protection | Records cannot be quietly changed or deleted, and any attempt raises an alert |
| Kept and governed | AU-11 Audit Record Retention; AU-9(4) Access by Subset of Privileged Users | Retention set by policy, and only a small, named group can manage logging |
The rest of this post works through the rows that cause most of the trouble with agents: correlation, integrity, time, and retention and access.
Correlation: one ID from request to system change
A single agent action can leave records in five places: the case or ticketing system where the request started, the agent runtime, the model gateway, the tool or MCP gateway, and the system the agent ultimately changed. Each keeps its own log with its own identifiers. AU-6(3) asks you to analyze and correlate records across repositories, and AU-12(1) asks for a system-wide trail that is time-correlated within a tolerance you set. With agents, the practical form of both is a correlation ID.
Mint the ID where the work starts, usually the case or request, and pass it on every hop: into the agent run, on every model and tool call as a header or parameter, into the approval request, and onto the downstream write. Record a parent ID on each event as well, so you can rebuild the order of sub-steps when an orchestrator fans work out to several specialist agents.
Correlation tends to break in the same three places:
- Asynchronous hand-offs. A queue or scheduled job drops the ID because nobody added it to the message schema.
- Human approval in another tool. The reviewer approves in a chat app or a separate queue, and the approval record carries that tool’s ID rather than yours.
- The downstream system. The core banking or policy system writes its own audit entry with its own transaction number and no reference to the agent run.
The fix for the third is two-way: write the correlation ID into a reference field on the downstream change where the system allows it, and record the downstream transaction number back into the trail. Then an auditor can start from either end.
Worked example: one KYC action through the trail
Illustrative. The systems, field names and values below are invented to show the pattern, and the hash columns show what a hash-chained store would add (see the next section). They do not describe a specific customer or Moring’s record format.
A commercial onboarding analyst asks a KYC evidence agent to reconcile a new corporate applicant. The agent reads registry and filing data, finds that two sources disagree on a shareholder’s percentage, tries to move the case forward, is stopped, and the analyst decides. Every event carries the same corr_id.
seq ts (UTC) source actor event outcome hash prev
101 2026-10-14T14:02:07.114Z case-system analyst j.ortiz request: reconcile case C-4471 accepted a91f 77c0
102 2026-10-14T14:02:07.390Z agent-runtime agent kyc-evidence (build 3f2e) run started for C-4471 started 0be4 a91f
103 2026-10-14T14:02:09.002Z ai-gateway agent kyc-evidence model call, guardrail check allowed 5d13 0be4
104 2026-10-14T14:02:11.876Z mcp-gateway agent kyc-evidence tool: registry.lookup (read) 200 c27a 5d13
105 2026-10-14T14:02:14.240Z mcp-gateway agent kyc-evidence tool: filings.fetch (read) 200 e840 c27a
106 2026-10-14T14:02:19.517Z agent-runtime agent kyc-evidence exception: ownership 28% vs 25% raised 19bb e840
107 2026-10-14T14:02:19.802Z mcp-gateway agent kyc-evidence tool: case.set_status (write) refused 6f05 19bb
108 2026-10-14T14:31:44.061Z case-system analyst j.ortiz exception resolved, reason TX-SRC recorded d3c9 6f05
109 2026-10-14T14:31:44.300Z core-onboard svc onboarding-api status -> pending officer review txn 8812044 2a60 d3c9
All rows: corr_id = C-4471-r1Read it the way an auditor would. Row 102 ties the run to a specific build, so you can show the agent that ran was the version that was approved. Row 107 shows the boundary holding: the agent tried a write it had no grant for, and the gateway refused it. Row 108 is the human decision, and row 109 is the change in the system of record, carrying its own transaction number. Starting from transaction 8812044 in the onboarding platform, someone can walk back to the analyst’s original request without asking an engineer.
What the rows deliberately leave out is the content of each step: the full sources, the agent’s explanation, the analyst’s rationale. That belongs in the decision record, referenced by the same ID.
Integrity: making alteration detectable
AU-9 asks you to protect audit information from unauthorized access, modification and deletion, and to alert someone when it happens. For an agent trail there are three common ways to do that, and they combine well.
Append-only and WORM storage. Write-once-read-many storage, such as object storage with a retention lock, refuses changes and deletions until a retention date passes. The protection lives in the storage layer, so it is only as strong as the controls on whoever administers that layer. Corrections become new records that reference the original, which is how most audit teams want errors handled anyway.
Hash chaining. Each record stores a hash computed over its own contents plus the previous record’s hash, as in the hash and prev columns above. Change record 106 and its hash no longer matches what record 107 claims came before it; delete it and the chain shows a gap. NIST SP 800-92 describes the file-level version of this, computing a message digest for each log file and storing it securely so later changes are detected, though its examples use MD5 and SHA-1, which you should replace with a current algorithm. A chain only proves something if a known-good hash is held somewhere the writer cannot reach, so publish the latest chain head periodically to a separate store or a different team.
Digital signatures. Signing records or batches with a key held outside the logging system lets you show who produced them. AU-9(3) covers cryptographic protection of audit integrity in general. AU-10, non-repudiation, is narrower: it is about irrefutable evidence that a particular individual, or a process acting for one, performed an action. For agents that matters most at the approval step, where you want the reviewer’s decision bound to their authenticated identity.
Whichever you choose, follow AU-9(2) and keep the trail on a system separate from the one being audited. The agent’s identity should be able to append records and nothing more.
Clocks: getting the order right
Agent steps happen milliseconds apart and across several hosts, so a few hundred milliseconds of clock drift can put a tool call before the request that caused it. AU-8 asks for timestamps in UTC or with an explicit offset, and SC-45(1), which absorbed the old AU-8(1), covers synchronizing clocks to an authoritative time source. SP 800-92 makes the same recommendation for log sources, using NTP.
Two habits help. Record a sequence number alongside the timestamp, as in the example, so ordering within a run does not depend on clocks alone. And set the AU-12(1) tolerance explicitly, then check drift between the hosts in the agent path against it.
Retention, reading and deletion
AU-11 leaves the retention period to you, tied to after-the-fact investigation and to regulatory and organizational requirements. For agent trails, match it to the regulated activity the agent supports and let legal and compliance set the number. SP 800-92 makes a distinction worth keeping: routine retention on a schedule, and preservation of specific records when an investigation or legal hold requires it.
Access needs as much thought. Agent trails often contain prompts, retrieved documents and customer data, so the trail is sensitive in its own right. Under AU-9(4), keep management of logging to a small named group. Separate the people who can read records from those who can change retention settings, and make sure nobody whose work is being logged can do either. Deletions should happen only through the retention process, and each deletion should itself be logged.
Where Moring fits
Moring runs in your own cloud account or on-premises, and several records in the example come from it directly. Each agent gets its own identity, and its key reaches only the models granted to it. The AI Gateway records every model call with user, team, model, tokens, cost, latency and the guardrail verdict. The MCP Gateway applies per-server guardrails, including human approval and blocked patterns, and refuses unapproved tools, which is where a refusal like row 107 would come from. Agents are built by exact image fingerprint and promoted against a certificate naming exactly what went to production, which is what lets a trail show that the agent that ran was the one approved. When someone uses Stop agent, the gateway refuses every call and the record says who, when and why. The identity and grant model is covered in more depth in AI agent identity and permissions, and the platform overview is on the AI Control Plane page. How these records fit the wider operating model — the registry, approvals and human sign-off around them — is described on the AI agent governance page.
Moring is not a SIEM, and the long-term store, its integrity protection and its retention schedule are decisions made in your environment. Signed agent requests and cross-session traces are on the roadmap and not shipped today. Activity that bypasses the gateways is not in Moring’s record, so check which paths are routed.
Test the trail
The decision-records post suggests handing a closed case to someone uninvolved and asking them to explain it. The trail needs two further drills.
Reconstruct backwards, against a clock. Pick a change in the downstream system, one the agent made weeks ago, and have someone from internal audit or the security operations team trace it back to the originating request using only the trail. Set the time limit before you start, matched to what your incident response process promises. Note every point where they had to guess a join or ask an engineer; each is a correlation gap.
Try to break it. On a restored copy or a test segment, with the exercise approved and recorded, change one record, delete one and insert one. Confirm the integrity check fails at the right place and that the AU-9 alert reaches the people named to receive it. While you are there, compare clocks across the hosts in the agent path against your AU-12(1) tolerance.
If you would like a second pair of eyes, pick one agent workflow and we will walk its trail with you, from request to system change. Get in touch.
Frequently asked questions
How is an AI agent audit trail different from a decision record?
What is the difference between hash chaining and WORM storage?
Which NIST SP 800-53 controls apply to AI agent audit logs?
Should the agent's own logs be the system of record for audit?
How do you test tamper-evidence without damaging the real record?
Sources
NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations: Source for the AU control names and statements cited here (AU-2, AU-3, AU-6(3), AU-8, AU-9 and enhancements (2), (3) and (4), AU-10, AU-11, AU-12 and AU-12(1)) and SC-45(1), which replaced the withdrawn AU-8(1). Publication page; control text browsable in the NIST CPRT catalog. A control catalog, not an AI-specific requirement.
NIST SP 800-92, Guide to Computer Security Log Management (2006): Source for log file integrity checking with message digests, synchronizing log source clocks with NTP, and the split between log retention and preservation. Publication page. Its hash algorithm examples (MD5, SHA-1) are dated; use a current algorithm.
Moring AI Control Plane: Product context for the gateway, identity, certificate and stop records described in this post. Product page. Coverage depends on which paths are routed through the gateways in your deployment.
Governing Autonomous AI Agents in Production
Moring provides the runtime control layer, identity verification, human-in-the-loop approvals, and audit records needed to deploy production-grade AI agents safely.
About the author
Arya SharanProduct Marketing & GTM, Moring AIChennai
Owns product marketing and go-to-market at Moring AI across positioning, demand and enablement. Works with regulated buyers on how governed AI agents are scoped, evaluated and bought. Writes about the operating questions that decide whether an agent reaches production.
LinkedIn profile
