AI Agent Incident Response Runbook Structure and Ownership

A refund agent starts issuing payments it was never supposed to touch, and the war room fills with a question that no standard incident response runbook was built to answer: why did the agent do it? That question is the subject of this piece. Incident response machinery was built for deterministic software, run by humans, so it cannot handle an autonomous agent: agent workloads break three assumptions that every traditional runbook rests on. An agent's behavior is non-deterministic: the same prompt can produce a harmless answer once and a harmful action moments later, so deterministic test cases miss the failure mode entirely, and detection becomes the operational burden. The evidence that matters most is a reasoning trace, not a disk image: a pod snapshot shows which containers ran, but it says nothing about whether the agent was compromised, manipulated, or fed poisoned context, because the real answer lives in the prompt, the retrieved documents, and the sequence of tool calls, none of which a standard container image captures. And the agent's input doubles as the attacker's weapon: a poisoned retrieval document or a manipulated MCP tool description can produce actions that look fully authorized because they are fully authorized, driven by reasoning that was hijacked. Standard cloud-native IR flattens three structurally different incident types into a single category, so responders run one runbook against a problem that needed three, and a mismatched runbook fixes nothing.

The three incident types that require separate runbooks

Classifying the incident correctly, before touching the runbook, is the single most consequential decision in agent IR, because that classification determines the containment family, the eradication path, and how the post-mortem gets framed. The first type is runtime execution escape: the agent reaches outside its sandbox through cross-container file operations, capability abuse, or host filesystem access through a path nobody intended. Its indicators look like classic container escape, kernel signals, namespace transitions, capability assertions, and it gets contained through workload isolation. The second type is privilege boundary escape, where the agent uses credentials it legitimately holds in ways it was never authorized to use them: a read-only role performing writes, an identity scoped to one storage bucket egressing to another, an MCP tool meant for queries running mutations instead. The indicators here sit entirely in the auth plane, scope deltas, identity-event traces, audit-log anomalies, and containment runs through permission revocation, credential rotation, and an access-grant audit. The third type is reasoning compromise, the category traditional IR has no runbook for. A prompt, a retrieved document, or a tool description gets manipulated, and the agent takes actions that look legitimate because they are legitimate, authorized at every checkpoint, just driven by reasoning that someone else hijacked. Patient zero can be a poisoned RAG document, a manipulated MCP tool description, or a straightforward prompt injection, and lateral movement means prompt context spreading to downstream agents, not network traffic spreading across a subnet. Containment for reasoning compromise means quarantining the corpus and tool catalog, auditing prompt provenance, and checking downstream agents for contagion. All three types, their indicator families, and their containment distinctions are documented in ARMO's incident response research. Some practitioners argue that one flexible runbook is easier to maintain than three specialized ones, but reasoning compromise produces no indicator in the kernel or the auth plane, so a unified runbook will never trigger the containment it needs. These are not three flavors of the same incident.

The six forensic artifacts that must be captured before containment closes the window

Agent forensics don't fail because evidence is missing; it's scattered across systems nobody centrally owns, available only for a limited window, and wiped out by the very containment moves a responder reaches for first. ARMO's playbook names six artifacts, and you have to capture them before that window closes. The first is prompt history with timestamps, so every message that entered the agent's context gets held in order. The second is retrieved context with source provenance: every RAG document fetched, every URL pulled, and every MCP tool description loaded, each one tagged with the identifier of where it came from. The third is the tool call sequence: every tool the agent invoked, along with the arguments it passed and the values it got back. The fourth is the agent's identity assumptions across the chain, so you track which service account it assumed at each step, and this matters most when the agent delegates work across multiple hops. The fifth is the record of downstream agent invocations: every agent the primary agent handed work to, along with the payload it handed over. The sixth is the full LLM output trace: you need the chain-of-thought, not just the final answer the agent produced. Killing the pod to stop the bleeding destroys most of this chain, so kernel-level capture has to keep running straight through containment, and it can't stop the moment containment starts. Much of this evidence sits in identity-provider logs, application logs, and vendor logs that a response team can query but doesn't own, often with retention windows shorter than the investigation itself takes to run. Collecting early has to be a first principle, done before containment, not a step scheduled for later. The equivalent of a disk image in that setting is a full OAuth grant export: every scope granted, every connected account, and the full record of recent activity. The runbook needs to specify evidence collection as a track that runs alongside containment, not one that waits for containment to finish first.

The four-phase runbook structure organized around agent-native actions

An agent incident response runbook is a different kind of artifact from a traditional playbook, not a modified version of one. It gets organized around identity revocation, action-class rollback, and reasoning-trace analysis, where a traditional playbook organizes around host isolation and log forensics. Four phases carry the structure.

Phase 1 is detection and declaration. If an AI system takes an unintended action against organizational data, it gets declared a security incident immediately, not filed as a product bug and routed to the tool owner. The incident owner comes from the security team, not from whoever owns the tool, and the incident record opens with the time the behavior was first observed, not the time the response actually started. Two tripwires do the detection work automatically: a cost-rate tripwire, where per-agent spend exceeding a multiple of its rolling median in a short window triggers review, and an action-rate tripwire, where API call volume exceeding a multiple of its rolling median, or calls hitting a previously unused endpoint, does the same. Automated outcome monitors catch these failures faster than a customer complaint ever will, and detection speed is the one lever that limits how far the blast radius can spread. The most common failure at this phase is a category error: unexpected agent behavior gets logged as a product bug, sits in a queue, and the agent's access stays live the entire time it waits there.

Phase 2 is where the runbook inverts the traditional instinct: contain the identity, not the host. Pulling a machine off the network is the reflex trained into a generation of incident responders, but there may be no machine to pull, because the agent runs as an identity with permissions, not as a box on a rack. So the equivalent move is to cut off the agent's authorization rather than isolate infrastructure that may not exist in any form a responder can touch. Resetting a password or re-enrolling multi-factor authentication does nothing, because the credential the agent is actually using can be long-lived and often belongs to no human being at all, so disabling the person who installed the integration does not reliably stop the agent from acting. You need to stop autonomous actions before anyone debates root cause, because every minute of investigation with live permissions still attached changes the risk calculation.

Phase 3 is blast-radius reconstruction and rollback. The work runs outward from the credential: what scopes were granted, which accounts the agent connected to, what data those accounts can reach, and only then what the agent actually did with that reach. Blast radius is bounded by granted permissions and available tools rather than network reachability, which reframes the whole scoping question toward "what was it permitted to touch. Rollback isn't always available, and where it isn't, the runbook has to name the substitute in advance: a compensating action, a customer notification, or a regulatory disclosure. The runbook has to encode the absence of a rollback path as a design decision before the incident happens, not patch it afterward under pressure. For reasoning compromise specifically, the blast-radius map has to include every downstream agent the primary agent handed work to, because prompt context propagates through a chain of agents the same way malware propagates through a network of machines. Re-enablement requires explicit gates before production autonomy resumes: a verified root-cause category, a confirmed rollback checkpoint, fixed guardrails, clean test results, and a monitored re-entry period, with recovery validation confirming system state before anyone calls the incident closed.

Phase 4 is the post-mortem, and it runs on a detection-time metric built for agents. Standard SRE post-mortems apply here, but you need one addition: a detection chain that answers why detection happened when it happened and names the structural change that would pull the next instance inside a target detection window. The post-mortem record has to note who got notified, when, and with what message, particularly customers and, where disclosure is mandatory, regulators. Tabletop drills, queue-pause exercises, and rollback rehearsals make the whole runbook materially more reliable in practice, so the runbook gets tested before a real incident forces the test, not only after one. Root causes that feed back into prevention fall into a handful of categories: prompt injection, authorization drift, unsafe tool use, model regression, workflow bugs, and human configuration error, and each of those maps to a different control upstream.

Credential design and permission scope as pre-incident runbook inputs

How fast the runbook can contain an incident, and how large the blast radius can ever get, both trace back to decisions made the moment a credential was issued, long before any incident occurred. If an agent is provisioned with broad standing access, every phase of the runbook above gets slower, harder, and more expensive to run. An agent should never hold broad standing access. Its credential should bind to the narrowest set of resources and actions its task actually requires, so that an agent that gets fully compromised, or simply misbehaves, can only reach what it was explicitly permitted to touch, with scoping enforced at the moment of issuance. Workload identity federation and short-lived, automatically rotated credentials beat embedded secrets as a pattern, and where an agent is acting on behalf of a user, OAuth 2.0 Token Exchange under RFC 8693 keeps the agent's own identity distinct from the authority it has been lent. That distinction disappears the moment an agent reuses a user's session token directly, which collapses two separate identities into one and makes the blast-radius math in Phase 3 much harder to run cleanly. Delegation chains need to narrow, not widen: when a parent agent calls a child agent or an external tool, the permissions handed down should stay equal or shrink, never expand just because another component joined the workflow. Most enterprises report they have monitoring and oversight in place, but far fewer have built the true containment controls that Phase 2's identity-revocation ladder depends on, and those controls need to exist before the incident starts, not get built in the middle of one.

Assigning runbook ownership across security, platform, and business teams before an incident

Ownership confusion causes more damage in practice than any technical gap in the runbook itself, because it stays invisible until an incident forces it into the open, and the most common failure mode traces straight back to the category error described in Phase 1, where an incident gets routed to the wrong team from the start. A laptop has a name next to it in an asset register. An AI agent connected through a consent screen may effectively belong to whoever clicked Allow, and that person can sit in a completely different department, may not know they own anything at all, and may be on vacation the moment the incident starts. Security needs the authority to declare the incident and own Phase 1 and Phase 2 regardless of who built or requested the agent. Platform teams need pre-assigned responsibility for the identity and credential infrastructure that Phase 2 and Phase 3 depend on, so that revocation and blast-radius reconstruction don't wait on someone locating the right engineer. Business teams, the ones who clicked Allow in the first place, need a named point of contact on record before the incident, not discovered during it, because they hold context about what the agent was supposed to do that security and platform teams won't have on hand. None of this works if you assemble it during the war room. The runbook's four phases only move at the speed the material above describes if the people who execute each phase were named, briefed, and drilled before the first unintended action ever reached production data.