What an agentic AI audit trail must capture

A standard application audit log captures state changes in the system: records created, modified, or deleted; API calls made; authentication events; errors raised. This is appropriate for deterministic systems where the causal chain from input to state change is explicit in the code.

Agentic AI systems introduce three properties that make standard logs insufficient:

Non-determinism. The same input can produce different outputs across different runs. This means an action that appears anomalous in the log cannot be attributed to a specific code path — the same input might have produced different behavior in a different run. To understand why the agent took a specific action, you need to know what the model was reasoning about when it took it.

Context-dependence.The agent's actions are determined not just by the immediate input but by the accumulated context in the session: previous messages, retrieved content, tool results, and the model's evolving understanding of the task. An action that looks anomalous in isolation may be a predictable consequence of a context that was gradually manipulated. The context must be logged to reconstruct the reasoning.

Goal evolution.The agent operates toward a goal that can change over the course of a session. If the goal drifted, the actions taken after the drift are consistent with the drifted goal, not the original one. Without a log of the goal at each point in the session, it is impossible to determine whether an action was consistent with the agent's authorized objective or with an attacker-injected one.

A complete agentic AI audit trail has four components, each addressing a different layer of the system's behavior. All four are required for complete incident reconstruction. Omitting any one of them creates a corresponding blind spot in post-incident analysis.

• Action log — what the agent did: the observable state changes and outputs it produced
• Reasoning log — what the model decided and the context it had when it decided
• Tool call log — every tool the agent invoked, with full parameters
• Session log — the goals stated at session start and goal evolution across the session

The action log is the closest to what a standard system log captures: the observable effects of the agent's behavior on state inside and outside the system.

For an agentic system, this includes:

• Files created, modified, or deleted
• Database records created, modified, or deleted
• External API calls made (endpoint, method, response status)
• Messages sent (email, Slack, other channels), with recipient and subject
• Web content retrieved (URLs accessed)
• Code executed (if the agent has code execution tools)
• User-visible outputs produced (with timestamps)

The action log answers: “what state changes did the agent make?” This is the starting point for incident response. It is not sufficient on its own — it does not answer why, and for non-deterministic systems, why is where the vulnerability lives.

The reasoning log captures the model's decision context: what the model was processing when it decided to take each action, and what chain-of-thought or planning reasoning it produced.

For chain-of-thought models or ReAct-style agents, this is the model's explicit reasoning trace. For systems without explicit reasoning traces, the minimum viable reasoning log includes the full context window at the point of each consequential decision — the system prompt, the conversation history to that point, any retrieved content, and the model's response.

This log is the most important for security incident analysis. It answers:

• Was there injected content in the context at the point of the anomalous action?
• Did the model's reasoning reference goals, instructions, or context that were not in the original system prompt?
• Is there evidence of goal displacement — was the model reasoning toward a different objective than the session goal?
• Was the model misled about its authorization for the action it took?

The reasoning log is to agentic AI incident response what source code is to traditional software debugging: without it, you can observe what happened, but you cannot understand why. “Why” is where the vulnerability is, and “why” is what you need to prevent recurrence.

The reasoning log is also the most sensitive. It contains the full context the model had, which may include user data, retrieved documents, and system configuration details. It must be treated with the same access controls as the most sensitive data it might contain — and this access control requirement must be planned for at design time, not as an afterthought.

The tool call log captures every tool invocation: the tool name, the full parameters passed to the tool, the tool's return value, and the timestamp.

The parameters are not optional.A log entry that records “send_email tool invoked” without recording the parameters is insufficient. The parameters are what the tool did: the recipient, the subject, the body. Without them, you know an email was sent; you do not know what was in it or where it went.

This applies to every tool in the manifest:

• File operations: which file, what operation, what content (for writes)
• Database queries: the full query, the result set (or a summary for large results)
• External API calls: the endpoint, the request body, the response body (or response status for large responses)
• Code execution: the code executed, the execution environment, stdout/stderr
• Web retrieval: the URL, the content retrieved (or a hash for large documents)

The tool call log is the bridge between the action log (what changed) and the reasoning log (why the model decided). It shows the sequence of invocations that produced the state changes, and the parameters reveal what the model instructed each tool to do — which in turn reveals what the model was reasoning about.

For tool chaining attacks — where the agent uses a sequence of permitted tools to achieve an unauthorized outcome — the tool call log is the only evidence that the chain occurred. Without full parameter logging, the chain is invisible.

The session log captures the agent's stated objectives at the beginning of the session and any evolution of those objectives across the session.

At session start, the session log should record:

• The user's stated task or request
• The agent's stated understanding of its goal for this session (if the agent is prompted to state this)
• The tool manifest active for this session
• The user's identity and privilege level

Across the session, the session log should record any point at which the agent's stated goal changes, is expanded, or is questioned. If the system uses session-scoped goal statements with periodic reconfirmation, each reconfirmation and any deviation should be recorded.

The session log is the reference against which goal drift is assessed. In a post-incident analysis, the question "was the agent's behavior consistent with its authorized task?" can only be answered if there is a documented record of what the authorized task was at each point in the session.

For incidents involving instruction drift — where the goal shifted gradually — the session log provides the timeline of the drift. Without it, the incident appears as a single anomalous action at the end of the session; with it, the progressive manipulation is visible.

Retention requirements for agentic AI audit trails must account for the investigation timeline — how long after an incident it might be discovered and investigated — and any regulatory requirements for the specific deployment context.

Investigation timeline. Some agentic AI incidents are discovered immediately (the agent produced an obviously wrong output). Others are discovered weeks or months later, when an external party surfaces evidence (a recipient forwards an unexpected email, a regulatory inquiry triggers a review, a user notices an anomalous pattern in their account). The audit trail must be retained long enough to support investigation of late-discovered incidents.

For most deployments, a minimum 90-day retention for detailed logs (reasoning log, full tool call parameters) with 12-month retention for summary logs (action log, session log) is a defensible baseline. High-risk deployments — agents with access to financial systems, health data, or external communications — should extend both to 12 months and 7 years respectively, aligned with financial record-keeping requirements.

Sensitivity and access control.The reasoning log contains the model's full context, which may include user inputs, retrieved documents, and tool results. Retention at scale creates a significant data store of potentially sensitive content. Retention policy must include access controls, encryption at rest, and an audit log of who accessed the logs and when.

Regulatory requirements. For EU AI Act high-risk systems, Article 12 requires technical documentation and logging that supports post-market monitoring. For systems processing personal data, GDPR Article 5(1)(e) requires storage limitation — retention should not exceed what is necessary for the specified purpose. These requirements create a tension between security (longer retention enables better incident investigation) and data protection (shorter retention limits data exposure). The resolution requires a specific retention analysis per deployment, not a single default policy.

The security review must verify that the audit trail implementation is complete and functional — not just that an audit trail is described in the system documentation.

The review produces the following evidence for the audit trail:

• Log schema documentation — the exact fields captured in each log type (action, reasoning, tool call, session), with an assessment of whether each schema meets the completeness requirements above
• Sample log review — review of actual log output from a representative agent session, confirming that the schema as documented is actually being populated (tool call parameters are present, not empty; reasoning context is captured at decision points, not just at session end)
• Gap assessment — any log type that is absent or any field within a log type that is not captured, with the associated risk of that gap for post-incident analysis
• Access control documentation — who can access each log type, how access is controlled, and whether the access controls are appropriate for the sensitivity of the log content
• Retention policy documentation — the retention period for each log type, the enforcement mechanism, and the alignment with investigation timeline and regulatory requirements
• Tamper-evidence mechanism — how the logs are protected against modification after the fact, particularly for the reasoning log which contains the evidence most relevant to attributing insider threats or sophisticated attacks

The audit trail review is a required component of every agentic AI security review. An agentic system without a complete audit trail is an agentic system that cannot be investigated after an incident — and that incapacity is itself a risk that must be reflected in the risk disposition.

For the full framework, including how audit trail requirements integrate with the overall assessment, see the agentic AI security review hub.