An AI agent audit log is a timestamped, tamper-evident record of every action an agent takes: the human it acted for, the context it retrieved, the tool it called, the arguments it passed, the decision that permitted the call, and what came back. Most production agent telemetry captures roughly half of that, and the half it drops is the half an investigation needs.
That is not an accusation of carelessness. It is the documented default of the standard everyone is converging on.
What should an AI agent audit log capture?
Start with what a bad action in an agent actually looks like, because the answer determines the field list.
In a classifier, cause and effect sit next to each other. An input arrives, an output leaves, and a record of both explains what happened. In an agent, the causal chain runs longer: a human intent, a system prompt, retrieved context that may have been written by an attacker, a model plan, a tool selection, an authorization decision, the arguments actually sent, an external side effect, and a result that re-enters the context and shapes the next step.
Break any link and the incident stops being reconstructable, because the cause of a bad agent action is usually a piece of retrieved text rather than a user instruction. A log that records the action without the context that prompted it records the symptom.
Here is the field list, mapped to names published in real specifications rather than invented for this article.
| Forensic question | Published field | Where it is defined |
|---|---|---|
| Which human principal? | Session identity carried from the OAuth or JWT context | OWASP Securing Agentic Applications Guide |
| Which agent, which version? | gen_ai.agent.id, gen_ai.agent.name, gen_ai.agent.version | OpenTelemetry GenAI conventions |
| What was the delegation chain? | acs.subagent.parent_session_id; W3C traceparent inside the MCP message | OWASP ACS; OpenTelemetry MCP conventions |
| What context was retrieved? | gen_ai.data_source.id, acs.source.type, acs.results.count | OpenTelemetry; OWASP ACS |
| What tool ran, with what arguments? | gen_ai.tool.name, gen_ai.tool.call.id, gen_ai.tool.call.arguments | OpenTelemetry GenAI conventions |
| Who authorized it, and on what basis? | acs.decision, acs.evaluator, acs.reasoning, policy_references, reason_codes | OWASP ACS only |
| What came back? | gen_ai.tool.call.result, acs.exit_status | OpenTelemetry; OWASP ACS |
| Where did the instruction originate? | acs.provenance.origin, acs.provenance.lineage_depth | OWASP ACS |
| Can the record be trusted? | Rolling SHA-256 session chain hash, per-entry request hash | OWASP ACS Audit profile |
Last verified: September 2026.
One row in that table exists in only one place. The authorization decision and its reason, with the policy identifier and version that produced it, is specified as a first-class required field by the OWASP Agent Control Standard, published September 1, 2026, and by nothing else we could find. Everything else records what the agent did. That row records why it was allowed to.
The default that makes most agent telemetry useless
The OpenTelemetry GenAI semantic conventions are where vendors are converging, which makes their defaults the industry's defaults. Two details deserve a place in your design review.
First, in the execute-tool span, gen_ai.tool.call.arguments and gen_ai.tool.call.result both carry the requirement level Opt-In, the weakest tier the specification defines. Second, on capturing prompts and outputs, the documented default usage pattern is stated plainly: "[Default] Don't record instructions, inputs, or outputs."
Read those together and the consequence is concrete. A team that adopts standard GenAI instrumentation, sees spans flowing, and marks the observability requirement complete will have a span saying the agent called send_email, and no record of the recipient. The two fields that decide an investigation are the two the specification marks optional.
There is a reason for the default, and it is a good one: arguments and results carry customer data, so recording them everywhere by default would be a privacy failure shipped as a feature. But the default was chosen for telemetry, and you are building evidence. Those are different jobs with different requirements, and nobody will tell you when you have confused them.
Worth knowing alongside that: the GenAI conventions moved to their own repository in May 2026, and every agent and MCP convention in it carries status Development. None of it is stable. Attribute names you build against can still change, so put the mapping in one place rather than scattering field names through your pipeline.
How is an agent audit log different from an application log?
An application log answers what the system did. An agent log has to answer why the system decided to, and the difference shows up in three places.
The delegation chain crosses process boundaries. An agent calling a tool over MCP may be handing work to a different process, a different host, or a different vendor. HTTP trace headers do not solve this, and the OpenTelemetry MCP convention says why: trace context propagated at the HTTP layer "only covers the HTTP request, but not the individual messages client and server exchange within the request/response streams." The convention instead injects W3C trace context inside the JSON-RPC message metadata. If your tracing stops at the HTTP hop, your chain breaks exactly where a subagent picks up the work.
The interesting input is not from the user. Application logs rarely record what a system read, because reads are not usually the attack. For an agent, the retrieved document is the attack surface, so the retrieval has to be in the record with enough identity to find it again.
Self-reported telemetry has a trust problem. The OWASP standard states it better than a vendor would: "Trace events are self-reported observations produced inside the environment being observed; they become evidence only when a party outside the emitting runtime attests to them." An agent that has been prompt-injected is precisely an agent whose own account of events you cannot rely on. That is the argument for recording at an enforcement point outside the agent rather than depending solely on in-agent instrumentation, and it comes from a standards body rather than from someone selling one.
Does SOC 2 or the EU AI Act require AI agent audit logs?
Less directly than most articles claim, and in the EU AI Act's case the obligation is real but frequently described wrongly.
SOC 2 first, because the answer is short. The Trust Services Criteria have five criteria in the CC7 series, CC7.1 through CC7.5, and none of them mentions logging. The word appears in the CC7 series only inside a point of focus under CC7.2, as "(3) logging of unusual system activities." The AICPA is explicit that points of focus are not a checklist: "Use of the trust services criteria does not require an assessment of whether each point of focus is addressed." So there is no SOC 2 field list, no SOC 2 retention period, and no SOC 2 log-integrity requirement. What your auditor tests is whether your stated controls meet CC7.2 through CC7.5 in your environment, which means the log you design is the thing being audited rather than the thing being prescribed.
The EU AI Act is where the obligation is concrete, with three corrections worth making.
Correction one. Article 12, titled Record-keeping, is a product requirement on the high-risk AI system, which binds the provider. It says that such systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system." It is not an operational duty on the deployer, and the deployer duty lives elsewhere.
Correction two, and this is the most common error in writing on this subject. Article 12(3) does contain a minimum field list, covering the period of each use, the reference database, the input data that produced a match, and the natural persons involved in verification. That list applies only to systems referred to in point 1(a) of Annex III, which is remote biometric identification. It is not a general field list for high-risk systems, and quoting it as one will be caught by anyone who opens the regulation.
Correction three, on dates. Retention is split across two articles with near-identical wording. Article 19(1) puts it on providers, and Article 26(6) puts it on deployers, each "to the extent such logs are under their control," each for "a period appropriate to the intended purpose of the high-risk AI system, of at least six months." So one log has two independent retention owners, divided by a control test that a SaaS agent deployment forces you to answer explicitly. And the timeline moved: Regulation (EU) 2026/1744, the Digital Omnibus on AI, adopted July 8, 2026, replaced the application dates so that Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I. Anything telling you these obligations bind from August 2026 is out of date. The substance of Articles 12, 19 and 26 was not amended, only the date they apply.
The exposure is not trivial. Article 99(4) places non-compliance with deployer obligations under Article 26, which includes that retention duty, in the tier attracting fines up to EUR 15 000 000 or 3% of total worldwide annual turnover, whichever is higher.
The clause to put in your vendor contract
This one is underused and costs nothing to invoke.
Article 13(3)(f) requires that the instructions for use supplied with a high-risk system contain "where relevant, a description of the mechanisms included within the high-risk AI system that allows deployers to properly collect, store and interpret the logs in accordance with Article 12."
The provider has to tell you how to read their logs. Pair that with Article 26(6) making you responsible for retaining logs under your control, and Article 21(2) requiring providers to hand logs to a competent authority on a reasoned request, and log accessibility stops being an engineering preference and becomes a procurement term. Put Article 13(3)(f) language into agent vendor contracts now, well ahead of December 2027, because the vendors who cannot satisfy it are easier to identify before you have integrated them.
ISO/IEC 42001 is worth a sentence of precision here too, since it is often cited loosely. Its Annex A is normative and offers a reference control for recording AI system event logs, but the standard operates through a Statement of Applicability, documented as "all necessary controls and justification for inclusion or exclusion of controls." So "ISO 42001 requires AI event logging" is not quite right. The accurate version is that excluding that control obliges you to justify the exclusion in writing, which in practice is harder than implementing it.
How do you make an agent audit log tamper-evident?
Three properties, in increasing order of effort.
Append-only storage with writes going to a store the agent runtime cannot modify. If the process being audited can rewrite the record, you have telemetry rather than evidence.
A chain hash across the session, so removing or altering an entry is detectable rather than merely discouraged. The OWASP standard specifies a rolling SHA-256 over the session context and a per-entry request hash for exactly this.
External attestation, meaning something outside the emitting runtime signs or co-witnesses the record. This is the property that survives the case where the agent itself is the compromised component.
There is a retention design problem sitting behind all three. Six months of full-fidelity capture of prompts, retrieved documents and tool results, for a high-volume agent, is a large and highly sensitive corpus, and it is now a target in its own right. Both OpenTelemetry and OWASP arrive independently at the same answer: keep two tiers. A cheap, immutable, chain-hashed spine of metadata and decisions, and a separately access-controlled content store referenced by pointer. OpenTelemetry's own recommended production pattern is to "store content externally and record references on the spans," noting that this "enables separate access controls." Build it that way and retention, access control and cost stop fighting each other.
How do you get agent logs into your SIEM?
Briefly, because we have covered the integration side in depth in AI audit trails and SIEM integration, and the point worth making here is about mapping rather than plumbing.
The OWASP Agent Control Standard maps its event classes onto OCSF, which is what lets agent events land in an existing pipeline without a bespoke parser. Tool calls map to Process Activity. Deny, modify, ask and defer decisions map to Detection Finding. Knowledge and memory operations map to Datastore Activity. Session and subagent lifecycle events map to Authentication. If you are choosing a schema now, choosing one with a published OCSF mapping saves the integration work that usually consumes the project.
Why this is worth building before you need it
Two pieces of evidence, pulling in opposite directions, and both should shape the design.
The case for logs comes from the July 2026 compromise of Hugging Face infrastructure by autonomous evaluation agents, recorded by MITRE ATLAS as AML.CS0068 and documented publicly by both organizations. Roughly 700 agent runs produced approximately 17,600 attacker actions. Agents executed code on 41 production dataset workers, obtained root on at least one production Kubernetes node, and downloaded four private source repositories. Exfiltration ran for about four and a half days before detection. What made the reconstruction possible afterward was the agent action log in the code sandbox. Not network telemetry. Not data loss prevention.
The case against relying on logs for detection comes from the same incident and from Anthropic. In that intrusion the staged data was chunked and encoded so that, in the reporting organization's words, a naive text scan of the logs would miss it. And Anthropic, writing in May 2026 about containing agents, put the general problem cleanly: "once a poisoned tool return has steered the agent into exfiltrating data, the log just shows a successful, authorized API call. There's no after-the-fact signal to find."
Both are true, and together they give you the design rule. A log is not a detection control, because at the API layer the malicious action was authorized and looks it. A log is a reconstruction control, and it is the only one that works after the fact. Which means the record has to be structured and decodable rather than a text blob you hope to grep, and detection has to happen at the moment of the action, where the policy verdict that fired on each call is still available to record alongside it.
Where to start
Four steps, in the order that makes each next one cheaper.
Define the event taxonomy before the schema, because the schema follows from what you decided is an event. Session start and end, agent trigger, retrieval, tool call request, authorization decision, tool result, subagent start and stop, and memory writes is a reasonable starting set, and it is roughly the set OWASP arrived at.
Fix the identity fields next, because they are the ones that are impossible to backfill. Every event carries the agent, the agent version, and the human the agent is acting for. Attributing every agent action to a named person is what turns a log into an accountable record, and an audit trail without it answers the wrong question.
Instrument at the enforcement point, not only inside the agent, so the record survives the agent being the thing that went wrong. Capture arguments and results deliberately, since the standard will not do it for you.
Then make it immutable and set retention against the six-month floor, with the two-tier split above so the sensitive half can be governed separately. If you are specifying this for a vendor rather than building it, the audit and logging questions in our agent security RFP cover what to ask and what a weak answer looks like, and replaying an agent session end to end is the capability to test in the demo rather than take on trust.
The honest summary is that the standards are converging fast and none of them will hand you a finished answer before December 2027. The field list above is buildable now, and the parts of it that are hardest to add later are the identity and the decision, which happen to be the two a regulator and an incident responder both ask for first.