Think about what happens when a human engineer makes a mistake that triggers an incident. They notice something is wrong, they say something, or someone notices the change in a log and correlates it to a deploy or a manual action. The reconstruction starts from a known actor and works outward. Who did what, when, why, what was the state of the system before and after.
Now think about what happens when the same incident is triggered by an autonomous AI agent. The agent doesn't raise its hand. It doesn't have a Slack message you can cross-reference. It ran a session, made a series of tool calls, and something downstream broke. Maybe it ran at 2am. Maybe it was one of 15 agents that ran that night. Maybe it was called by another agent that was called by a scheduled job.
The question "what happened" is the same, but the evidence structure is completely different. And most incident response playbooks were written for the human case.
The Forensic Chain for Agent-Triggered Incidents
When we think about reconstructing an agent-triggered incident, the forensic chain has more links than a human-triggered one, and any break in the chain stops the investigation cold.
The chain looks roughly like this: what business trigger initiated the session, what parameters were passed to the agent, what tool calls did the agent make and in what order, what data did each tool call return and how did the agent use it in subsequent decisions, what was the final action that caused the harm, and what was the state of the affected system immediately before that action.
Each link in this chain requires a specific type of log record. The triggering context requires an event log from whatever initiated the session (a user action, a scheduler, an upstream API call, or a parent agent). The tool call sequence requires per-call logs from the agent runtime. The data flow between calls requires context-window-level logging, which most platforms don't retain by default. The final action requires application-layer logs from whatever system was affected. The pre-action state requires a point-in-time snapshot, which may or may not exist depending on the target system.
In practice, the break almost always happens at two points: the triggering context (enterprises rarely log which user or process initiated an agent session in a way that persists to incident review) and the data flow between tool calls (the intermediate reasoning steps that explain why the agent took a particular action are typically discarded after the session ends).
What You Actually Need Before an Incident Happens
The time to build your agent forensics infrastructure is before you need it. This is not a novel insight, but it is one that gets deferred repeatedly because it requires instrumenting systems that are working fine right now and that nobody wants to slow down with additional logging overhead.
The minimum instrumentation that enables a post-incident reconstruction includes four things.
Session identifiers that propagate through the entire execution chain. Every agent session should have a stable ID that is passed to every tool call it makes, to every downstream system it writes to, and to every sub-agent it invokes. This is the thread that pulls the chain together during an investigation. Without it, you are correlating events by timestamp and hoping the window is narrow enough to be useful.
Immutable per-session tool call logs. These are timestamped records of every tool invocation the agent made, including inputs provided and outputs received. The key word is immutable: if your logging infrastructure allows an agent (or a process triggered by an agent) to modify or delete its own logs, the forensic value is compromised. Append-only log stores with access controls on the append target are worth the operational overhead.
Triggering context records. For every agent session, something caused it to start. That cause should be recorded: the user identity if there was one, the job scheduler ID if it ran on a schedule, the parent agent session ID and the specific tool call that invoked it if it was called by another agent. This is the upstream link in the forensic chain.
Policy decision records. For each tool call, did it execute against a known policy, was it conditionally permitted, or was it outside any defined policy? The policy record doesn't just help with enforcement. It helps with investigation. An action that fell outside your policy at the time it executed is a very different finding from an action that was within policy but had unexpected downstream effects.
The Multi-Agent Complication
Single-agent incidents are relatively tractable once you have session logging in place. The harder problem is multi-agent architectures, where an orchestrator delegates work to specialized sub-agents, and those sub-agents may themselves call tools or invoke further agents.
In these architectures, the forensic chain becomes a tree. The incident might have been caused by a leaf node agent that executed a specific write operation. But the decision to invoke that leaf node came from an intermediate agent, which was itself invoked by the orchestrator, which was triggered by a user. Reconstructing the full tree requires that session IDs propagate correctly through every handoff, and that every node in the tree logged its own decision to call the next one.
We have seen architectures where the orchestrator logged its own tool calls but not the context it passed to sub-agents. This is the gap that matters: you can see that the orchestrator called sub-agent X, but you cannot see what instructions or data it provided, which means you cannot understand why sub-agent X did what it did.
The fix is straightforward at the design level but requires consistent implementation: every agent-to-agent handoff should log the full input context, not just the name of the target agent and the fact that it was invoked. The output of that logging is verbose, but it is recoverable. The output of not logging it is an investigation that ends at "we know sub-agent X did it, but we don't know why."
Incident Response Playbooks Need Agent-Specific Sections
Most existing incident response playbooks have sections for host compromise, credential theft, data exfiltration, and similar traditional categories. Very few have sections specifically for agent-triggered events.
An agent-triggered incident playbook section should answer several questions. How do we identify which agent or agents were involved? (Answer: look for the session ID in the affected system's logs, then query the agent audit store for that session ID.) How do we reconstruct the session timeline? (Answer: pull the per-call log for that session ID, order by timestamp, step through the tool call sequence.) Who needs to be notified? (Answer: the team that owns the agent configuration and the team that owns the affected system, plus whoever triggered the original session.) What is the containment step? (Answer: revoke or suspend the agent's credentials, or block it at the policy layer if your enforcement infrastructure supports that.).
The reason to write this down before an incident is that the first time it happens is not the time to figure out where your agent logs live or who can query them. Incident response depends on fast access to the right information. If your agents have been running without instrumentation, you will spend the first several hours of your response window discovering that you do not have the logs you need.
The Accountability Gap
There is a broader issue that agent forensics brushes up against: accountability. When a human makes a mistake, there is a person whose professional judgment failed. That person can be asked to explain their reasoning, retrained, or given different responsibilities. When an agent makes a mistake, the accountability is distributed across the team that designed it, the team that provisioned its permissions, the team that deployed it, and the team that decided not to instrument it properly.
We are not saying that is a bad thing or a new thing. Accountability for software systems has always been distributed across the teams that build and operate them. But AI agents feel different because they exhibit goal-directed behavior that looks like decision-making. The absence of a clear individual to hold responsible creates pressure to assign blame in unhelpful ways.
Good agent forensics does not solve the accountability question, but it does make the question answerable. When you can reconstruct exactly what the agent did, what it was told to do, and what policy it was operating under, you can identify where in the design and deployment chain the gap existed. That is what you need to prevent the same incident from happening again.
The goal is not to create a paper trail for assigning blame. It is to understand what happened well enough to fix it.
Audit your AI agents with Arrakis.
Arrakis gives security and platform teams a complete audit trail of every action your AI agents take, with policy enforcement that stops overreach before it reaches your data.
Request a Demo