An AI agent reads a customer record, decides a refund is warranted, and calls the payments API. The trail it leaves looks nothing like a human doing the same job. The log says a user logged in, a service account made three API calls, and the transaction cleared. It doesn’t say why the agent decided on a refund, what it read first, which model version did the reasoning, or who gave the agent permission to act in the first place. That missing “why” is the whole audit problem.
This article covers what ISO/IEC 42001:2023 and the SOC 2 Trust Services Criteria expect from AI agent audit logs, where the two overlap, the fields a log needs to satisfy both, how long to keep records, what you shouldn’t record, and how to package it all for an auditor. It’s written for the CTO, platform lead, or founder who owns compliance for a product that now ships with autonomous agents and needs a certification and a Type II report without running two separate logging programs.
The Compliance Gap: Traditional Application Logs vs. AI Agent Audit Logs
Why Standard Logs Fall Short for Autonomous Agents
Application logs were built for deterministic software. Same input, same state, same output, so recording the input, the state change, and the result is enough to reconstruct what happened. A SOC 2 auditor sampling access logs can trace a database write back to a login, a role, and a change ticket without much effort.
Agents break that chain in a few places. They usually run under a shared service account or a borrowed OAuth token, so the log pins the action to a machine identity with no link to the human who set the task. The action itself was picked at runtime by a model rather than fixed in code, so there’s no source line to point at. The same prompt can produce a different tool call tomorrow, so a single sampled log entry proves almost nothing about how the system behaves in general.
The Shift from Deterministic State Logging to Intent and Reasoning Capture
Traditional logs answer “what changed.” Agent audit logs also have to answer “what was the agent trying to do, what did it consider, and what held it back.” That means capturing the task as delegated, the context the model was handed, the reasoning or planning steps it produced, the tools it picked and the arguments it passed, and every point where a guardrail stepped in. The unit of audit moves from the event to the decision, and each decision needs enough surrounding context that a reviewer can judge whether it was reasonable.
Unique Audit Challenges of Non-Deterministic AI Behavior
Non-determinism is the part auditors struggle with most. In a normal control test, the auditor re-performs the control and expects the same result. Re-run the same input through an agent and you may get a different path. The practical answer is to stop trying to prove that any single output was correct and instead prove that every output was recorded, attributed, bounded by policy, and reviewable. Logs show that the management system works. They don’t show the model is infallible, and nobody expects them to. ISO 42001 accepts this framing outright. SOC 2 auditors are still catching up, and you’ll spend some time educating them.
Insider Note: Auditors don’t expect you to explain the model’s weights. They expect you to show that when the agent did something unexpected, you could find it, see what it read, see what it did, and see who was accountable. Frame every logging decision around that reconstruction test.
What ISO 42001 Requires for AI Agent Audit Logs
ISO/IEC 42001:2023 is the certifiable standard for an AI Management System (AIMS). It follows the same Plan-Do-Check-Act structure as ISO 27001 and comes with 38 Annex A controls. The phrase “audit log” barely appears in it, but logging obligations run through the main clauses and at least three Annex A areas. Our ISO 42001 certification services map these to your existing controls where possible.
Clause 8: Operational Logging and Documentation Requirements
Clause 8 asks you to plan, run, and control the processes needed to meet your AI requirements, and to keep documented information showing those processes ran as planned. For an agent in production, the process is the runtime behavior, so documented evidence means logs of the agent operating, not a procedure document on its own. Clause 8.4 adds an AI system impact assessment whose results you have to retain. When an agent’s scope or toolset changes, the record of that change and the updated assessment are both Clause 8 evidence.
Clause 9: Performance Evaluation and Evidence of Monitoring
Clause 9.1 asks you to decide what to monitor and measure, how, and when, and to keep evidence of the results. An auditor will want the monitoring you defined for each agent (error rates, guardrail block rates, tool-call anomalies, how often humans override) and the records showing you reviewed it. Clause 9.2 internal audit and 9.3 management review both feed off those records. Without operational logs, there’s nothing to measure, and Clause 9 falls over.
Annex A.6: AI System Lifecycle Logging Obligations
Annex A.6 is where logging gets explicit. A.6.2.8, AI system recording of event logs, requires you to decide at which phases of the AI system lifecycle event logging is switched on, and the Annex B guidance ties this to traceability and anomaly detection. A.6.2.6, AI system operation and monitoring, requires ongoing monitoring in operation, including AI-specific threats like data poisoning and model theft. Read together, they mean logging can’t start at go-live. Design decisions, validation runs, deployment configs, and production behavior all need a record.
Annex A.9: Logging Requirements for AI System Operation
Annex A.9 covers responsible use: processes for responsible use (A.9.2), objectives for it (A.9.3), and intended use (A.9.4). The logging consequence is that you need to show the agent stayed inside its intended use. That takes logs of the tasks it was given, the actions it took, and any time it was pushed outside scope and what happened next. Policy enforcement events and guardrail blocks are your main A.9 evidence.
Annex A.5: Recording Impact Assessments and Decisions
Annex A.5 requires a documented AI system impact assessment process and retained results. Agent logs feed this in both directions. Assessment outputs (approved tool scope, approved data sources, thresholds for human oversight) become the policy the agent runs under. Operational logs then show whether the assessed risks actually showed up, which is what the next assessment cycle reviews. Auditors look for that loop, not just the document.
What SOC 2 Requires for AI Agent Audit Logs
The AICPA Trust Services Criteria don’t mention AI anywhere. A SOC 2 auditor looks at your agents through the same Common Criteria they’d apply to any system that touches customer data. What changes is the evidence they’ll accept.
CC7.2: Monitoring and Anomaly Detection for Agent Activity
CC7.2 requires you to monitor system components for anomalies that could point to malicious acts, errors, or natural disasters, and to analyze them to decide whether they’re security events. For agents, “anomaly” now includes behavior: an agent calling a tool it has never used, an unusual volume of data reads in one session, repeated guardrail blocks, or a prompt that matches an injection signature. Auditors will ask what your detection rules are for agent behavior specifically, and for proof that alerts fired and someone triaged them.
CC6.1–CC6.3: Access, Authentication, and Authorization Logging
CC6.1 through CC6.3 cover logical access: how identities get provisioned, authenticated, authorized, and removed. Agents need their own identities, their own credentials, and their own least-privilege scopes, and the log has to show which identity did what. An agent running on a human’s session token fails this test because the auditor can’t tell agent actions from user actions. Provisioning and removal of agent identities, and periodic access reviews that include agents, are all in scope. We cover the identity side of this in depth in our guide to managing AI agent access under compliance frameworks.
CC7.3 and CC7.4: Incident Detection and Response Evidence
CC7.3 requires you to evaluate security events to decide whether they’re incidents. CC7.4 requires you to respond and contain. Prompt injection is the incident type auditors increasingly poke at. Evidence means a logged detection, a ticket, a containment step (pulling the agent’s tool access, rolling back an action), and a post-incident review. The logs have to be rich enough to rebuild the sequence: which input carried the injection, what the agent did next, and where it got stopped.
Availability and Processing Integrity Log Considerations
If your report includes Availability or Processing Integrity, agent logs pick up two more jobs. Availability wants proof that agent failures, timeouts, and model outages were caught and recovered. Processing Integrity wants proof that agent outputs were complete, accurate, and authorized, which for an agent means logging the output, the validation applied to it, and any human sign-off before it took effect. If you have agents in billing or financial workflows, treat Processing Integrity as mandatory.
Where ISO 42001 and SOC 2 Log Requirements Overlap
Shared Controls: Access, Change, and Incident Logging
Roughly two-thirds of what an agent audit log needs serves both frameworks. Identity and access events, config and prompt changes, incident detection and response, and log integrity controls map cleanly onto ISO 42001 (A.6, Clause 9) and SOC 2 (CC6, CC7, CC8). If you already hold SOC 2 or ISO 27001, the logging infrastructure carries over. What changes is what goes into the events.Divergent Controls: AI-Specific Evidence Not Covered by SOC 2
ISO 42001 asks for evidence SOC 2 never does: impact assessment linkage, intended-use monitoring, human oversight records, lifecycle logging from design onward, and monitoring for AI-specific threats like drift and poisoning. A team that builds logging purely for a SOC 2 auditor will fail ISO 42001 Stage 2 on A.5, A.6.2.8, and A.9 evidence. Going the other way, SOC 2 auditors want sampling-friendly access reviews and change tickets that an ISO-only program may treat loosely.| Requirement | ISO 42001 | SOC 2 | Same Log Event? |
|---|---|---|---|
| Agent identity and access events | A.6, Clause 8 | CC6.1–CC6.3 | Yes |
| Prompt, config, and model changes | A.6.2.5, A.6.2.7 | CC8.1 | Yes |
| Anomaly detection and alerting | A.6.2.6, Clause 9.1 | CC7.2 | Yes |
| Incident detection and response | A.8.4, Clause 10 | CC7.3, CC7.4 | Yes |
| Log integrity and retention | A.6.2.8, Clause 7.5 | CC7.2, CC6.1 | Yes |
| Reasoning trace and decision context | A.6.2.8, A.9.4 | Not required | ISO only |
| Human oversight and override records | A.8.1, A.9.2 | Optional (PI) | Mostly ISO |
| Impact assessment linkage | A.5, Clause 8.4 | Not required | ISO only |
| Intended-use boundary monitoring | A.9.4 | Not required | ISO only |
Unified Log Schema for Dual Compliance
The efficient answer is one event schema with a superset of fields, tagged with the controls each event supports. Every event carries the shared core (identity, timestamp, correlation ID, action, outcome, integrity hash). The AI-specific fields (model version, reasoning trace reference, guardrail decisions, delegation chain) get filled in when they apply, and the SOC 2 evidence export just ignores them. You end up pulling two evidence packages from one pipeline instead of maintaining two pipelines.Required Fields in an AI Agent Audit Log
The field set below is the minimum that covers both frameworks. Vendors and frameworks name these differently. The OpenTelemetry GenAI semantic conventions are the closest thing to a neutral vocabulary and are worth adopting where they fit.
| Field group | Fields | Why auditors need it |
|---|---|---|
| Agent identity and session | agent_id, agent_version, session_id, deployment_env | Attribution to a distinct non-human identity (CC6.1, A.6) |
| Delegation chain | principal_user_id, delegating_identity, authorization_scope, approval_ref | Who authorized the agent to act, under what scope (CC6.2, A.9.2) |
| Prompt, input, context | system_prompt_hash, user_input_ref, context_sources[], retrieved_doc_ids[] | What the agent saw before deciding (A.6.2.8, incident forensics) |
| Model and reasoning | model_provider, model_id, model_version, temperature, reasoning_trace_ref, token_usage | Reproducibility and decision context (A.6.2.8, A.9.4) |
| Tool invocations | tool_name, tool_args_hash, tool_target_system, tool_result_status, mcp_server_id | What the agent actually did (CC6.3, CC7.2, A.6.2.6) |
| Data touched | data_read[], data_written[], data_classification, record_count | Access scope, DSAR support, minimization (CC6.1, A.7) |
| Policy and guardrails | policy_id, guardrail_decision, block_reason, override_by, override_justification | Intended-use enforcement, human oversight (A.9.4, A.8.1, CC7.2) |
| Output and effect | output_ref, action_taken, downstream_effects[], human_review_status | Processing integrity, downstream impact (PI1, A.8) |
| Trace context | timestamp_utc, trace_id, span_id, parent_span_id, correlation_id, integrity_hash, prev_hash | Reconstruction and tamper evidence (CC7.2, A.6.2.8) |
Agent Identity and Session Attribution
Every agent needs its own identity in your identity provider, separate from the humans who use it and from other agents. Session IDs group the events of one task run. Without this, an auditor sampling a database write can’t tell whether a person or an agent made it.
User and Delegation Chain (Who Authorized the Agent)
Agents act on someone’s behalf. The log has to carry the principal (the human or system that handed over the task), the scope of that delegation, and, where the chain runs through several agents, every hop. This is the field teams forget most often, and the one auditors ask about first when an agent does something surprising. Multi-agent systems need the full chain, not just the last hop.
Model Version, Parameters, and Reasoning Trace
Model provider, model identifier, version, and sampling parameters let the auditor establish which model was live during the observation period and whether changes were controlled. Reasoning traces (chain-of-thought, planning steps, tool selection rationale) belong in a restricted store, referenced by ID, rather than inline in the general log. That’s partly volume and partly confidentiality.
Tool Invocations and External API Calls
Log every tool or function call with the tool name, a hash or redacted form of the arguments, the target system, and the result status. Where agents connect through the Model Context Protocol (MCP), log the MCP server identity too, because a compromised or misconfigured MCP server is a supply-chain risk on its own. This is your direct evidence against OWASP’s Excessive Agency (LLM06:2025), still the risk auditors bring up most for agents.
Data Accessed, Retrieved, and Written
Log what the agent read and wrote at the level of record identifiers and data classification, not content. That covers access reviews, data subject requests, and minimization evidence. Record counts matter more than people expect. An agent reading 40,000 customer rows to answer one question is exactly the anomaly CC7.2 exists to catch.
Policy Decisions, Guardrail Blocks, and Overrides
Every time a policy engine evaluates an agent action, emit an event: allowed, blocked, or escalated to a human. Overrides need the identity of the person who overrode, their justification, and a timestamp. These records are the strongest ISO 42001 evidence you’ll produce, because they show human oversight working rather than just designed.
Output, Action Taken, and Downstream Effects
Store the output by reference, the action that ran, and the identifiers of any downstream systems it touched. Where a human reviewed the output before it took effect, log the reviewer and their decision. For Processing Integrity scope, this is your primary evidence.
Timestamp, Correlation IDs, and Trace Context
Use UTC timestamps from a synchronized clock, a trace ID that spans the whole task, span IDs for each step, and a correlation ID that ties the agent run back to the originating business transaction. Add an integrity hash per event and a hash of the previous event so tampering is detectable. Trace context is what turns a pile of events into a story you can actually follow.
Pro Tip: Build the Field Schema
Build the field schema first and validate every event against it at ingestion. Rejecting malformed events at the edge of the pipeline is far cheaper than finding out during audit fieldwork that three months of tool calls have no delegation chain.
Log Integrity, Retention, and Storage Requirements
Immutability and Tamper-Evidence Controls
An audit log sitting in the same application database the agent can write to isn’t audit evidence. Ship events to a write-once store (object storage with object lock, a WORM-capable log platform, or an append-only ledger) and chain the hashes so any edit or deletion shows up. Limit delete permissions to a break-glass role that has its own logging. Auditors for both frameworks will test whether an engineer could alter a record after the fact. Make sure the answer is no.
Retention Periods for ISO 42001 vs. SOC 2 Audit Windows
Neither ISO 42001 nor SOC 2 gives you a number. ISO 42001 asks you to define and justify retention as part of documented information control. SOC 2 needs evidence covering the whole Type II observation period, typically three to twelve months, plus time for fieldwork. The EU AI Act does set a floor for high-risk systems: Article 19 requires providers, and Article 26(6) requires deployers, to keep automatically generated logs for at least six months, with financial institutions folding them into their existing regulatory retention. The Digital Omnibus on AI, published as Regulation (EU) 2026/1744 and in force since 27 July 2026, moved the Annex III high-risk deadline to 2 December 2027. The six-month floor didn’t move.
| Framework | Stated Retention | Practical Target |
|---|---|---|
| ISO 42001 | Defined by the organization, documented and justified | 12 months online, 24 months archived |
| SOC 2 Type II | Cover the full observation period plus fieldwork | Observation window + 6 months |
| EU AI Act (high-risk) | At least 6 months (Articles 19, 26) | 12 months minimum |
| GDPR interaction | No longer than necessary for the purpose | Pseudonymize, then age out personal data |
Encryption, Access Restrictions, and Log Confidentiality
Agent logs concentrate sensitive material: prompts, retrieved documents, reasoning traces, and the identities of everyone involved. Encrypt at rest and in transit, limit read access to security, compliance, and incident responders by role, and log access to the logs themselves. Reasoning traces deserve a tighter access tier than the event stream.
Handling Sensitive Data: What NOT to Log
Don’t log raw credentials, API keys, or session tokens that pass through tool arguments. Don’t log full prompt or output text where it contains personal data; keep a redacted version or a reference to a governed store. Don’t log entire retrieved documents. GDPR’s data minimization principle applies to logs just as much as to the primary system, and an over-collected log turns into a breach liability and a data subject request headache. Hash or tokenize what you need for reconstruction and drop the rest.
Important: The most common ISO 42001 finding on logging is the reverse of what teams expect. Auditors flag over-logging of personal data far more often than under-logging. A log that captures every customer conversation verbatim is a privacy nonconformity, not a compliance win.
Logging Architecture for AI Agents
Instrumenting Agents at the Framework Level
Instrument at the agent framework or gateway, not inside individual prompts or tool handlers. A gateway sitting between the agent runtime and every model and tool endpoint sees every call. It can enforce the schema, attach identity, evaluate policy, and emit one event per decision. Application-level instrumentation drifts as developers add tools. Gateway-level instrumentation doesn’t.
Capturing Reasoning Traces Without Leaking PII
Route reasoning traces through the same redaction layer as prompts, store them in a separate restricted bucket, and reference them by ID from the main event. Give them shorter retention than the event stream if you only need them for incident investigation. Where models expose structured planning output, log the structure (tool selected, reason category) rather than the free text.
SIEM and OpenTelemetry Integration Patterns
Emit agent events as OpenTelemetry spans using the GenAI semantic conventions, export via OTLP to your collector, and fan out to two places: the SIEM (Splunk, Datadog, Elastic, or whatever you run) for real-time detection under CC7.2, and immutable long-term storage for evidence. Build SIEM detections that are specific to agent behavior: first-time tool use, tool-call rate spikes, high guardrail block counts per session, retrieval from unexpected sources, delegation chains longer than policy allows. Generic SIEM rules won’t catch any of these.
Centralized Log Pipelines for Multi-Agent Systems
Multi-agent systems need one pipeline with trace context propagated across every hop, so a single trace ID follows a task from the orchestrator through each sub-agent and tool. Each agent keeps its own identity in the events. Without propagated context, a task that touches five agents produces five unrelated logs and no story.
Evidence Collection for Auditors
Mapping Log Artifacts to ISO 42001 Clauses and Annex A Controls
Build a control-to-evidence matrix before Stage 1. For each ISO 42001 control, list the log query or export that evidences it. A.6.2.8 maps to the schema document, the lifecycle logging coverage statement, and sample exports. A.9.4 maps to guardrail and policy events. A.8.1 maps to override records. Clause 9.1 maps to monitoring dashboards and review minutes. Your Statement of Applicability should point at these artifacts directly.
Mapping Log Artifacts to SOC 2 Trust Services Criteria
SOC 2 auditors work from populations and samples. For CC6, produce the population of agent identities and their access changes over the period, plus periodic access review evidence. For CC7.2, produce the detection rules, the alert population, and triage records. For CC7.3 and CC7.4, produce the incident population with linked log excerpts. For CC8.1, produce the population of prompt, model, and config changes with approvals.
Sample Evidence Packages for Type II and Certification Audits
A workable evidence package for either audit contains the log schema and its version history, the logging coverage statement across lifecycle stages, integrity control documentation with a tamper test result, the retention policy and proof it’s enforced, five to ten full trace reconstructions of agent runs (including at least one with a guardrail block and one with a human override), access reviews covering agent identities, and the monitoring metrics reviewed in management review. The same package, filtered, serves both audits.
Automating Continuous Evidence Export
Schedule the evidence queries to run automatically and land in your GRC platform monthly, so the Type II observation period builds up without a scramble at the end. Continuous compliance monitoring platforms can ingest OpenTelemetry-derived summaries, but most still lack native agent-specific tests, so expect to build custom evidence collectors for the AI-specific fields.
Common Audit Log Failures and How to Avoid Them
Missing Reasoning and Decision Context
The log shows the tool call but not what the agent was asked, what it read, or why it picked that tool. The fix is to log context source references and a reasoning trace reference on every decision event.
Incomplete Tool Invocation Records
Some tools are instrumented and others aren’t, usually because a developer wired a tool in directly instead of going through the gateway. The fix is to only allow tool registration through the instrumented gateway, and to alert on any outbound call from the agent runtime that has no matching event.
Untracked Delegation and Authority Chains
The agent ran under a shared service account and the log can’t say who asked it to act. The fix is per-agent identities, principal propagation on every task, and a hard block on agents using human session tokens.
Gaps in Guardrail and Policy Enforcement Logs
Guardrails block actions but don’t emit events, so there’s no evidence that human oversight or intended-use controls actually operate. The fix is for every policy evaluation to emit an event with its outcome, allows included, so auditors can see the control ran on every action and not just the blocked ones.
In our own ISO 42001 readiness work, the untracked delegation chain is the failure that comes up most in gap analyses. Teams have solid tool logging and reasonable guardrails, but the agent is still running on an engineer’s OAuth token from the prototype phase and nobody ever swapped it out. Fixing it usually takes a week. Discovering it during Stage 2 costs a lot more than that.
Implementation Checklist for AI Agent Audit Logs
- Inventory every agent in scope, its tools, its data sources, and its current identity.
- Give each agent its own identity with least-privilege scopes, and remove any use of human session tokens.
- Define the unified event schema and version it as documented information.
- Instrument at the gateway or framework layer, and block uninstrumented tool registration.
- Propagate trace and delegation context across every agent and tool hop.
- Add redaction and hashing for prompts, outputs, arguments, and reasoning traces.
- Ship events to immutable storage with hash chaining and restricted delete rights.
- Set retention that covers your Type II window, your ISO 42001 policy, and at least six months for any EU high-risk exposure.
- Build agent-specific SIEM detections and route the alerts into your incident process.
- Log every policy evaluation and human override, allows included.
- Build the control-to-evidence matrix for both frameworks and automate the exports.
- Run a tamper test and a full trace reconstruction before the auditor does.
Getting this right is as much a management system job as an engineering one. The logging itself is fairly simple once the schema, identities, and pipeline exist. The real work is deciding what to capture, proving it’s trustworthy, and mapping it to two sets of controls in a way an auditor can follow. Teams that already hold SOC 2 or ISO 27001 have most of the plumbing and need the AI-specific layer on top. Axipro builds that layer as part of its ISO 42001 certification services, alongside SOC 2 audit readiness, and has covered the adjacent identity problem in its guide to managing AI agent access under compliance frameworks and its Vanta ISO 42001 implementation guide.
Frequently Asked Questions
What is the minimum log retention period for ISO 42001 and SOC 2?
Neither framework gives you a number. ISO 42001 asks you to define and justify retention in your documented information controls, and SOC 2 needs evidence spanning the full Type II observation period, usually three to twelve months. The EU AI Act sets a six-month floor for high-risk systems. Twelve months online plus a longer archive covers all three in practice.
Do we need to log every prompt sent to an LLM?
You need to log that every prompt happened, with its version, context sources, and a reference or redacted form of the content. You don’t need, and often shouldn’t keep, raw prompt text that contains personal data. Hash the system prompt, reference the user input in a governed store, and log the retrieval sources by ID.
How do we log agent reasoning without capturing sensitive user data?
Store reasoning traces by reference in a restricted store, run them through the same redaction layer as prompts, and log structured decision metadata (tool chosen, reason category, guardrail outcome) in the main event. Give the trace store shorter retention than the event stream if you only need traces for investigations.
Can SIEM tools handle AI agent log volumes?
Yes, as long as you log decisions and references rather than full content. An agent run that produces one event per model call, tool call, and policy evaluation is roughly the volume of a busy microservice. Pushing full prompts, outputs, and reasoning text into the SIEM is what blows up the bill. Keep that content in cheaper object storage and send the SIEM the structured events.
How do auditors verify the integrity of AI agent logs?
They review the storage controls (write-once configuration, hash chaining, restricted delete rights), inspect the access logs for the log store itself, and usually ask you to show that a modification would be detected. Being able to run a hash-chain verification on the spot and show a clean result is the strongest evidence you can offer.
Are audit logs required for internal-only AI agents?
Under ISO 42001, yes, if the agent sits inside the scope of your AIMS. A.6.2.8 and A.9 apply whether the users are customers or employees. Under SOC 2, an internal agent is in scope if it can reach systems or data covered by the report. An internal agent with production database access is in scope for both.
How do audit logs support incident response for prompt injection attacks?
They let you find the injected input (usually in retrieved context or a tool result), trace what the agent did after reading it, work out which guardrails fired or failed, and scope the affected data and downstream systems. Without context source logging and tool invocation records you can confirm something went wrong but not what, and that fails CC7.3 and CC7.4 evidence expectations.
