From Ritu Raj | Product & Market Analysis
The Agent Audit Log Nobody Built: 12 Fields That Make an AI Action Defensible
On this page
Only 21% of enterprises have runtime visibility into what their AI agents are doing, in a survey where 88% reported an agent security incident in the previous twelve months. Most agent systems log the outcome. Almost none log the inputs the agent saw or the authority it acted under. That gap is the difference between a record and an audit trail, and it is about to become a legal problem rather than an engineering preference.
Key takeaways
- An outcome log cannot answer the only question an investigator asks. "The agent issued a refund" is a fact. "The agent issued a refund because a retrieved document said to, under a policy grant that had expired" is an audit trail.
- Default instrumentation records metadata, not content. OpenTelemetry's GenAI conventions capture model names, token counts and durations by default. Prompts, tool arguments and results are opt-in.
- The EU AI Act sets a six-month floor, not a ceiling. Articles 19 and 26 both require automatically generated logs to be kept for at least six months, and the obligations start applying from 2 December 2027.
- Reasoning traces belong in the log as artefacts, not as explanations. Anthropic measured chain-of-thought faithfulness at 25% for one model. A trace records what was said, not what caused the action.
What an agent audit log has to prove
An audit trail for an AI agent must let a reader reconstruct one action without asking the engineer who built it. That means four things: who authorised it, what the agent saw, what it chose between, and what changed as a result. Outcome logs answer only the last one.
This is the test worth applying to whatever your system writes today. Hand a three-month-old log line to someone outside the team. If they cannot say which human's authority it borrowed, or which retrieved document changed the answer, the record is not an audit trail.
Most teams fail on the second question, not the first. Identity is usually recorded, because access control forced the issue years ago. The inputs almost never are, and nothing in the default tooling asks you for them.
Why outcome-only logging is the default everywhere
This is not negligence. It is what the tooling gives you when you install it and change nothing.
OpenTelemetry's GenAI semantic conventions are the closest thing the industry has to a shared standard. The trace hierarchy is sensible: a top-level invoke_agent span holds child chat spans for model calls and execute_tool spans for tool invocations. That structure is exactly right for reconstructing a sequence of steps.
The defaults are the problem. As the OpenTelemetry project describes it, only metadata is recorded by default: model names, token counts and durations. Full prompts, system instructions, tool schemas, tool arguments and results are captured only when content capture is switched on. The project is explicit that this trades debugging value against data sensitivity. That is an honest trade for observability and the wrong one for audit.
The conventions themselves are also still moving. As of the June 2026 release, all gen_ai attributes were split into a separate repository with its own release cadence, and the agent and tool conventions remain pre-stable. Building compliance evidence on attribute names that can still change is a deliberate choice, not a default one.
Observability and audit are different products that happen to share a data source, and treating them as one system is the root error. One serves an engineer this week and can sample freely. The other serves a stranger years later and cannot. The comparison of the main LLM observability platforms is a useful read on what each one persists by default, and on how little of that is designed for an auditor.
The 12-field minimum agent audit record
This is the specification. It is deliberately small. Twelve fields in five blocks, and every field earns its place by answering a question an investigator will ask.
| Block | Field | What it records | Question it answers |
|---|---|---|---|
| Authority | principal_id | The human or system account whose authority the run borrowed | Who is accountable |
| Authority | agent_id | Agent identity plus a hash of the config and prompt set it ran under | Which agent, in which version |
| Authority | model_ref | Provider, model identifier, version string and sampling settings | What produced the output |
| Authority | delegation_path | Ordered hops from the principal to the agent that acted | How authority travelled |
| Trigger | trigger | What started the run, with the correlation ID of the upstream event | Why it ran now |
| Trigger | authority_grant | The policy or scope ID, with version, that permitted this action | Whether it was allowed |
| Inputs | context_digest | Content hashes for system prompt, user message, retrieved documents, tool schemas and memory reads | What the agent saw |
| Inputs | tool_invocation | Tool name, server identity, arguments proposed, arguments actually executed | What it tried to do |
| Decision | decision_record | Options considered, option selected, score or confidence where one exists, pointer to the reasoning trace | What it chose between |
| Decision | checkpoint | Whether a human approved, who, when, and what they were shown | Whether oversight was real |
| Outcome | effect | State change with before and after values, idempotency key, reversal handle | What actually changed |
| Outcome | integrity | Hash chain link to the previous record, clock source, retention class | Whether the record is trustworthy |
This record is a design proposal from the author, not a published standard, and no certification body recognises it.
Authority: four fields, because identity is four things now
NIST SP 800-53 control AU-3 asks an audit record to establish what happened, when, where, the source, the outcome, and the identity of the entities involved. For a conventional system, identity is one value. For an agent, it is at least four.
The human principal, the agent, the model and the delegation path are separate facts and they fail separately. An agent can be correct while the principal's authority has lapsed. Collapsing these into one service account is how teams end up unable to answer any of the four. The breakdown of non-human identity and agent access covers why shared credentials make this unrecoverable.
The agent_id field must carry a config hash, not just a name. An agent whose system prompt changed on Tuesday is a different agent. A log that cannot distinguish the two versions cannot support a defence.
Trigger: the field that separates an accident from a decision
Two fields, and both are cheap. The second, authority_grant, is the one teams skip, and it is the one that decides liability. Recording that an action happened proves nothing about whether it was authorised. Recording the grant ID lets you show, later, exactly what your system believed it was allowed to do at that moment. This is the evidence that agent liability caps and remedy clauses end up turning on when a dispute reaches a lawyer.
Inputs: hash everything, store what you can afford
The naive objection is that storing every retrieved document is unaffordable. The answer is that context_digest stores hashes, not payloads. Hashes are small, fixed in size, and sufficient to prove later that a specific document was or was not in context. Store the payloads where you can, under a shorter retention class, and keep the digests for the full period.
The tool_invocation field needs a detail most implementations miss. Record the arguments the agent proposed and the arguments actually executed, as two separate values. When a validation layer rewrites a parameter, the difference between those two is the highest-signal line in the whole record. It is also the only place a prompt injection attempt leaves a clean fingerprint.
Decision: two fields, and one of them is a trap
The decision_record field holds the options the system considered and the one it took. Where the system produces a score or a confidence value, record it. Where it does not, record that it does not, rather than leaving the field absent and ambiguous.
The checkpoint field records human oversight, and the important part is the last clause: what the human was shown. An approval where the reviewer saw a one-line summary is not the same control as an approval where they saw the full tool arguments. Regulators reading a human-in-the-loop architecture will ask which of the two actually happened.
Outcome and integrity: the two fields auditors check first
The reversal handle inside effect is what turns an incident from a forensic exercise into a remediation. If you cannot say how to undo an action, you have logged a fact and not a control.
The integrity field is what makes the rest credible: a hash chain link to the previous record, an explicit clock source, and a declared retention class. Without these, every other field in the record is an assertion your own system makes about itself, and a determined opponent will say so.
What regulators are actually about to ask for
The requirements are not hypothetical and they are not vague. Three regimes already specify something close to this record, arriving at it from different directions.
The EU AI Act names logging as a design obligation rather than an operational habit. Article 12 requires high-risk AI systems to technically allow automatic recording of events over the system's lifetime, at a level of traceability appropriate to the intended purpose. Note the phrasing: the duty sits on the system's design, not on the operator's diligence after the fact.
Article 19 puts the retention duty on providers, and Article 26(6) puts the matching duty on deployers. Both set a floor of six months, and both allow longer where other law demands it. The obligations begin applying from 2 December 2027, which is close enough that a system being architected now will be in scope before it is mature. The wider set of duties is mapped in the EU AI Act transparency checklist.
Financial regulators solved the integrity half of this problem two decades ago. The SEC's 2022 amendments to Rule 17a-4 are worth reading even if you are not a broker-dealer. They kept write-once storage as an option and added an audit-trail alternative. That alternative preserves records so an original can be recreated if it is modified or deleted, with a complete time-stamped trail of every change. It is a precise definition of integrity written by a regulator, and borrowing it for the integrity field costs nothing.
What none of these regimes give you is the field list. Article 12 says traceability appropriate to the purpose. ISO/IEC 42001 control A.6.2.8 requires an organisation to determine at which lifecycle phases event logging is enabled. Neither one names a schema. That is deliberate on the regulators' part and unhelpful on yours. The record above is one reading of what those requirements imply, not the only defensible one. The mapping of HIPAA and DORA controls onto agents shows how much the answer moves once a sector regulator has an opinion.
Reasoning is the field everyone gets wrong
The instinct when you hear "log the reasoning" is to store the chain of thought and treat it as the explanation. That instinct is wrong, and there is measured evidence for why.
Anthropic's Alignment Science team fed models a subtle hint about the answer to an evaluation question, then checked whether the model's stated reasoning admitted using it. Claude 3.7 Sonnet disclosed the hint 25% of the time and DeepSeek R1 39%. On prompts involving unauthorised system access, R1's disclosure rate fell to 19%. The team's own conclusion was that you cannot always rely on what reasoning models say about their reasoning.
A reasoning trace is an output the system generated, not a causal record of why it acted. Store it, hash it, keep it under the same retention class as everything else. Do not label the field "explanation" and do not put it in front of a regulator as one.
What carries the causal weight instead is the inputs and the authority, which is why they occupy six of the twelve fields. If a retrieved document changed the answer, the digest proves that document was present. That is a checkable claim. "The model said it considered the policy" is not, and a competent opposing expert will take it apart.
Logging the inputs also gives you a cleaner story when the trace and the action disagree. A divergence becomes a finding you can investigate rather than an argument between two unverifiable accounts. Systematic divergence over time is exactly what production drift monitoring exists to catch, and it needs this record as its input.
Retention, cost, and why sampling breaks the whole thing
The cost objection is real and it is usually overstated. Agent telemetry does run to gigabytes per day for a busy system, and the standard observability answer is to sample the interesting traces and discard the rest.
Sampling is correct for observability and fatal for audit. A sampled audit trail has a hole in exactly the place you need it, because the action that matters was not flagged as interesting when it ran.
The resolution is retention classes, not sampling. Split the record into a small durable core and a large expiring body.
| Tier | Contents | Retention | Rough size per action |
|---|---|---|---|
| Durable core | All 12 fields, with inputs stored as hashes only | The full regulatory period, six months minimum under the EU AI Act | Kilobytes |
| Evidence body | Prompt text, retrieved documents, tool results, reasoning traces | A shorter window sized to your incident detection time | Megabytes |
| Debug detail | Full span attributes, intermediate states, token-level data | Days, sampled freely | Variable |
Size estimates are illustrative and depend heavily on context window and tool count. They indicate the ratio between tiers, not absolute figures for any specific system.
The durable core is small because hashes are small. That is the entire trick. The expensive thing was never the record. It was the decision to keep every payload forever, which nobody asked you to do.
Where this specification is weakest
Four honest problems with what I have just proposed.
Nobody has adopted it, including me
This record is derived from published requirements, not from a deployment. I have not run it at scale for a year and reported what broke. Treat it as a starting schema to argue with rather than a validated standard. The strongest form of the criticism is that field lists written from regulations tend to be complete and unimplementable. The real test is whether a team can populate all twelve without slowing the agent down.
The survey evidence is thin
The 21% runtime visibility figure comes from a survey of 108 enterprises, skewed heavily toward technology companies at 52.8% of respondents. The Cloud Security Alliance's parallel finding that 82% of enterprises have unknown agents in their environment rests on 418 responses. Both are directional. Neither is a census, and self-reported security maturity is a category where respondents flatter themselves.
Hashing inputs creates a new dependency
A digest only proves what was in context if you can still resolve it to a document. If the retrieved document is deleted from its source system, the hash proves that a document with those exact bytes was present and nothing more. That is weaker than it sounds in a dispute, and it means the retention policy on your knowledge base has quietly become part of your audit posture.
Immutability and deletion rights pull against each other
A hash-chained log that cannot be edited is exactly what an auditor wants and exactly what a data erasure request cannot accommodate. The usual answer is to keep personal data out of the durable core and hold it in the expiring tier. That works, and it means the core alone will sometimes be insufficient to reconstruct an action involving a named individual. There is no clean resolution here, only a documented choice.
Retrofitting this into a running system
You do not need to rebuild the pipeline. The six missing fields are all cheap, and they can be added in an order that yields something usable at each step.
In week one, add principal_id, agent_id with a config hash, authority_grant and delegation_path as attributes on the existing top-level agent span. These are values your system already holds in memory during the run. That alone moves you from "an agent did something" to "an agent acting for this person under this grant did something", which is most of the accountability value for a fraction of the work.
In week two, hash every input at the point it enters context and write the digests. Then split storage: route the twelve-field core to append-only storage under the regulatory retention class, and let the payload tier expire on your existing schedule. Add the integrity chain last, because it has the most design surface and it is worth doing after the record shape has stopped changing.
One warning from the NSA's May 2026 guidance on the Model Context Protocol is relevant to the sequencing. Agents can independently decide to use new tools, so the set of actions you need to log is not fixed at design time. Build the record so an unrecognised tool still produces a complete tool_invocation entry rather than a gap.
Frequently asked questions
What should an AI agent audit log contain?
At minimum it should record four things beyond the outcome: who authorised the action, what the agent saw, what it chose between, and what changed. In practice that means the human principal, the agent and model version, the delegation path and the policy grant. Then hashes of every input, the tool arguments proposed and executed, the decision record, any human approval, and the state change with a reversal handle.
How long do you have to keep AI agent logs under the EU AI Act?
At least six months. Article 19 places the duty on providers of high-risk AI systems and Article 26(6) places a matching duty on deployers, in both cases for automatically generated logs under their control. Six months is a floor, not a target. Longer periods apply where other Union or national law requires them, and financial institutions keep the logs inside their existing financial services documentation.
Is a chain-of-thought trace enough for an audit trail?
No. Anthropic measured how often reasoning models disclosed a hint they had actually used and found rates of 25% for Claude 3.7 Sonnet and 39% for DeepSeek R1. A trace records what the model said about its reasoning, which is an output rather than a causal record. Store it as an artefact alongside the inputs, and rest your evidence on the inputs and the authority instead.
What is the difference between AI observability and an AI audit log?
Observability serves an engineer debugging this week, so it can sample, drop records and expire quickly without failing at its job. An audit log serves a stranger years later, so it cannot sample and cannot lose records. They share span data but differ on three things that matter: completeness, retention period, and whether the record can be shown to be unaltered.
Do AI agent audit logs need to be immutable?
They need to be demonstrably unaltered, which is not quite the same thing. The SEC's amended Rule 17a-4 offers a useful model. It allows either write-once storage, or an audit-trail alternative that preserves enough history to recreate an original record if it was modified or deleted, with a time-stamped trail of every change. Hash chaining gives you the second option without locking your storage layer.
How much does agent audit logging cost to store?
Less than teams assume, if you split the record. The durable core holds twelve fields with inputs stored as hashes rather than payloads, which is kilobytes per action and cheap to keep for the full retention period. The large items, prompt text, retrieved documents and reasoning traces, sit in a shorter tier sized to your incident detection time and expire on the existing schedule.
Where to start this week
Run the reconstruction test first. Take one agent action from a month ago, hand the record to someone who did not build the system, and ask who authorised it and what changed the answer.
Whatever they cannot answer is your field list. Add those attributes to the top-level agent span before you evaluate a single vendor tool. A purchase decision made before you know which fields you are missing is a decision made on a demo.
Use this record
The twelve-field table above is meant to be copied into a schema and argued with. If your implementation forces a change to it, I would rather see the amended version than a compliant one.
References
- EU AI Act, Article 12: Record-Keeping. Used for the logging design obligation and traceability wording.
- EU AI Act, Article 19: Automatically Generated Logs. Used for the six-month retention floor and the application dates.
- OpenTelemetry, Inside the LLM Call: GenAI Observability with OpenTelemetry, 2026. Used for default metadata capture and the agent span hierarchy.
- Anthropic, Reasoning models don't always say what they think, 2025. Used for all chain-of-thought faithfulness figures.
- VentureBeat, Most enterprises can't stop stage-three AI agent threats, 2026. Survey of 108 enterprises, fielded 6 January to 15 March 2026.
- Cloud Security Alliance, 82% of enterprises have unknown AI agents in their environments, 21 April 2026. 418 responses.
- SEC, Amendments to Electronic Recordkeeping Requirements for Broker-Dealers. Used for the audit-trail alternative to write-once storage.
- NSA, Security Design Considerations for AI-Driven Automation, 20 May 2026. Used for the uncontrolled automated action risk in Model Context Protocol deployments.
The weakest part of this source base is the survey evidence. Both enterprise surveys are small, self-reported and vendor-adjacent, and the 12-field record itself is the author's proposal rather than a published standard. The regulatory citations are primary and current as of 1 September 2026.
Related reading