The enterprise AI incident response playbook that doesn't exist anywhere else. Agent Incident Window. Semantic Forensics. Blast Perimeter. The first 60 minutes, the first 24 hours, and how to stop it from happening again.
Your AI agent sent an incorrect legal summary to a counterparty. Your procurement agent approved a vendor contract it was only supposed to flag for review. Your customer service agent disclosed information from one account in a response to a different customer. Your code-generation agent introduced a dependency that opened a supply chain vector.
It has happened or it will happen. The question is not whether your AI agents will produce incorrect, unauthorized, or harmful outputs. The question is what your organization does in the first 60 minutes after you find out.
Every mature security organization has an incident response playbook for human-actor intrusions, phishing events, ransomware, and data breaches. NIST SP 800-61 [1] covers the process in depth. Industry frameworks like SANS have refined it over two decades. Security teams drill it quarterly.
No equivalent playbook exists for AI agent incidents. The categories are different. The forensic methods are different. The containment actions are different. The legal exposure is different. And the decision tree that a CISO runs through at 11pm when an agent alert fires is completely uncharted territory.
This post fills that gap. It introduces three original constructs for AI agent incident response: the Agent Incident Window, Semantic Forensics, and the Blast Perimeter. It gives you the first 60 minutes, the first 24 hours, and the structural changes that prevent recurrence. It is written for the security leader, the AI platform owner, and the general counsel who will be in the same room when this happens.
This post builds directly on the formal threat model in The Agent Compromise Surface, which defines the four vectors through which an enterprise AI agent can be turned against its operator. The Agent Incident Window framework below is the operational complement to that formal model: the ACS paper tells you what can happen; this post tells you what to do when it does.
This playbook covers AI agent incidents broadly: adversarial compromise (covered in the ACS framework), unintended model behavior, tool chain failures, authorization boundary violations, and output quality failures with real-world consequence. Not all of these are security incidents in the traditional sense and but all of them require structured response.
Traditional incident response rests on four assumptions, all of which break for AI agents.
Assumption 1: The attacker leaves traces. Human-actor intrusions generate authentication logs, lateral movement signatures, volumetric anomalies, and behavioral deviations from baseline. AI agents that are compromised or malfunctioning produce outputs that are structurally indistinguishable from normal operation. An agent that has been injected with a malicious instruction and is now exfiltrating data looks, at the log level, exactly like an agent doing its job. This is the core argument for the Agent Dwell Window construct in our earlier ACS paper [2]: the absence of anomaly signals makes detection structurally harder for agents than for human actors.
Assumption 2: You can identify a perimeter breach. Traditional IR starts with "where did they get in?" For AI agents, the compromise may not have come from outside at all. It may have arrived as a malicious document in a retrieval corpus, a poisoned tool response from a vendor API, a corrupted memory record, or an adversarially crafted user input. The entry point is semantic, not network-topological. NIST SP 800-61 [1] containment strategies assume you can identify and isolate a compromised host. There is no equivalent of isolating a host when the attack surface is the agent's reasoning context.
Assumption 3: Logs reconstruct the incident. Traditional forensics reads logs to reconstruct what happened. AI agent logs record inputs and outputs, but they do not record the reasoning chain that connected them. You can see that the agent received a document and then made a tool call and you cannot see why it made that call, what intermediate steps it reasoned through, or whether an injected instruction influenced the decision. Reconstructing agent intent from output traces requires a different discipline entirely: Semantic Forensics, defined below.
Assumption 4: Containment means blocking network access. Standard containment is network isolation: take the compromised host offline, revoke credentials, block egress. For AI agents, containment means something different: revoking the agent's tool permissions, purging potentially corrupted memory records, terminating active sessions, and auditing all outputs produced during the incident window. Each of these requires capabilities that most organizations have not built into their agent platforms.
NIST SP 800-61 [1], NIST AI RMF [3], OWASP Top 10 for LLM Applications [4], and MITRE ATLAS [5] collectively provide threat taxonomies, risk management guidance, and attack catalogs. None of them provide a step-by-step operational playbook for what a security team does in the first 60 minutes of an AI agent incident. That gap is what this post fills.
The Agent Incident Window is the time interval from the first anomalous or unauthorized output produced by an AI agent to verified containment and defined as the point at which the agent's tool permissions have been revoked, active sessions terminated, and all outputs produced during the window have been identified and quarantined for review. AIW = tc - tf, where tf is the timestamp of the first anomalous output and tc is the verified containment timestamp. The longer the AIW, the larger the Blast Perimeter. AIW originates with this work.
Semantic Forensics is the discipline of reconstructing an AI agent's intent, reasoning chain, and the scope of adversarial or unintended influence from its output trace and without access to intermediate reasoning states. Semantic Forensics is distinct from log analysis: it operates on agent outputs, tool call sequences, retrieved context, and prompt structure, not on network events or authentication records. It answers: what did the agent intend, what influenced that intent, and which outputs were downstream of the anomalous influence? Semantic Forensics originates with this work.
The Blast Perimeter of an AI agent incident is the set of systems, data stores, downstream processes, and external recipients that received outputs produced during the Agent Incident Window, weighted by the reversibility of those outputs. Formally, BP(A, AIW) = {s ∈ S : A produced output affecting s during AIW}, partitioned into reversible (outputs that can be recalled or corrected), partially reversible (outputs that require third-party cooperation to correct), and irreversible (outputs whose effects cannot be undone). Blast Perimeter originates with this work and extends the Semantic Blast Radius construct introduced in [2] to the post-incident forensics context.
The first 60 minutes of an AI agent incident determine whether the Blast Perimeter is contained to one system or spreads across the organization. Most organizations have no protocol for this window. Here is the decision tree your team should run.
Before anything else, classify the incident. This determines every subsequent action. Three questions, answered in sequence:
Execute containment in this sequence. Do not do these in parallel and order matters because each step closes a vector that the next step would otherwise miss.
Remove the agent's access to all external tools, APIs, and data stores. This stops the Blast Perimeter from growing. Do this before terminating the session and a session termination without permission revocation may allow an already-queued tool call to complete.
End all active sessions for the affected agent instance. If your platform supports session isolation, isolate rather than terminate and isolation preserves the reasoning state for Semantic Forensics. Termination loses it.
Identify every output produced during the Agent Incident Window and mark it as under review. This includes outputs sent to external systems, stored in databases, forwarded to other agents, and delivered to users.
With the agent contained, assess the Blast Perimeter. The goal is a complete inventory of what happened during the AIW, partitioned by reversibility.
Start with the agent's tool call log for the AIW period. Every tool call produced an output or a side effect. Enumerate them: which data stores were written to, which APIs were called with what parameters, which downstream agents received outputs, which external parties received communications. This is your preliminary Blast Perimeter.
Then partition by reversibility. Database writes that have not been read by downstream systems are reversible. Emails sent to external recipients are partially reversible (you can send a correction, but you cannot recall the original). Regulatory filings, legal submissions, and customer-facing outputs in contractual contexts may be irreversible. The irreversible partition of the Blast Perimeter determines your legal and regulatory exposure.
An output crosses the irreversibility threshold at the moment a third party acts on it in a way that creates a legal, contractual, or regulatory record. A procurement agent's approval that is already countersigned by a vendor is irreversible. A legal summary that has been filed with a court is irreversible. Identifying outputs that are approaching this threshold during the AIW is the most time-critical forensic task.
After containment, the question shifts from "stop the bleeding" to "understand what happened and why." Traditional log forensics answers this for human-actor incidents. For AI agent incidents, you need Semantic Forensics.
Semantic Forensics operates on four evidence sources, in order of reliability:
The output of Semantic Forensics is a root cause hypothesis: which of the four ACS vectors was triggered, what the entry point was, and which outputs were downstream of the anomalous influence. This hypothesis drives the remediation plan.
Not all AI agent incidents require the same response. This framework routes you to the right track in under five minutes.
| Incident Type | ACS Vector | Blast Perimeter Risk | Primary IR Track | Notify Immediately |
|---|---|---|---|---|
| Agent produced factually wrong output and distributed it | None (model behavior) | Low-Medium | Platform escalation + output recall | AI Platform Owner, Product |
| Agent sent unauthorized communication to external party | None or I (input boundary failure) | High | Legal review + output quarantine | General Counsel, CISO |
| Agent tool call pattern anomalous vs. baseline | T (tool chain) or M (memory) | High | Security IR + Semantic Forensics | CISO, AI Platform Owner |
| Orchestrator agent behavior changed without config change | O (orchestration hijack) | Very High | Security IR, isolate full agent graph | CISO, CTO, Legal |
| Agent accessed data outside its documented scope | M (memory injection) or T | High | Security IR + DLP review | CISO, Privacy Officer |
| Agent output triggered downstream agent cascade | O or T | Very High | Cascading containment protocol | CISO, CTO, All downstream owners |
| User-reported: agent gave advice that caused financial/legal harm | Any | High-Irreversible | Immediate legal hold + platform suspension | General Counsel, CEO, CISO |
An orchestrator agent that has been compromised or has malfunctioned may have already distributed anomalous instructions to subagents before you detected the incident. Containment of the orchestrator does not automatically contain its subagents. Every multi-agent deployment needs a cascading containment protocol: a mechanism to propagate a containment signal to all agents that received instructions from the affected orchestrator during the AIW. Most platforms do not build this by default.
After the first 60 minutes, the incident moves from emergency response to structured remediation. This is the 24-hour playbook.
Enumerate every output produced during the AIW. Classify each as reversible, partially reversible, or irreversible. Begin recall actions for reversible outputs. Notify legal for irreversible outputs. Document everything with timestamps.
Run the full Semantic Forensics analysis. Produce a root cause hypothesis with an evidence chain. Identify the entry point, the influence vector, and the set of outputs downstream of the anomalous influence. Separate outputs that were directly caused by the incident from outputs that happened to occur during the AIW but were not causally related.
Notify all affected parties based on your Blast Perimeter inventory. Internal stakeholders: platform owners, product teams, data owners. External: counterparties who received anomalous outputs, regulators where legally required (EU AI Act Article 73 [7] requires post-market monitoring for high-risk systems). Document notifications.
Develop the remediation plan based on root cause. Define the return-to-service gate: the specific conditions the agent must meet before it is permitted to resume operations. Gate conditions should address the specific ACS vector that was implicated, not just a general "review."
A mid-market financial services firm deploys a procurement agent authorized to flag vendor contracts for human review, with a read-only connection to the vendor management system. A configuration change by a platform engineer accidentally grants the agent write permissions. The agent approves three contracts during an overnight batch run and two of which are within its prior read-only scope and one of which is a $2.4M infrastructure contract that required CFO countersign.
The incident is detected the next morning when the CFO's office receives a countersign request for a contract they had not reviewed. AIW: approximately 9 hours. Blast Perimeter: three vendors notified of approval, one contract already countersigned by the vendor (irreversible partition). The CISO and General Counsel are notified. Semantic Forensics reveals a tool call to a write API endpoint that the agent should not have had access to. Root cause: misconfigured permission boundary, not adversarial compromise. Remediation: audit all permission boundaries across the agent fleet, implement pre-deployment permission validation against the documented permission model.
A telecommunications provider deploys a customer service agent with access to the company's CRM and account history. The agent is designed to answer account questions within a verified customer session. A retrieval implementation error allows the agent's RAG system to pull records from adjacent accounts when a customer's query is semantically similar to another customer's recent interaction. Over three days, the agent discloses partial account information from 14 different accounts across 11 customer sessions.
Detection occurs when a customer calls to report that the agent mentioned a service they do not have and which belongs to a neighbor's account. AIW per session: minutes. Cumulative AIW across the event: three days. Blast Perimeter: 11 customer sessions, 14 accounts, partial account data. Irreversible partition: all 11 disclosures are already made; none can be recalled. Privacy Officer and Legal are notified. EU AI Act Article 9 [7] risk management documentation is required. Root cause: retrieval boundary failure in the RAG implementation. Remediation: isolate retrieval scope per session, implement cross-account retrieval blockers, notify affected customers per applicable data protection regulation.
A legal technology firm deploys a document analysis orchestrator agent that coordinates three subagents: a summarization agent, a clause extraction agent, and a risk-flagging agent. A law firm client uploads a document that contains, embedded in its appendix, a set of instructions formatted to look like a system prompt. The orchestrator processes the document and the embedded instructions redirect the orchestrator to route all document summaries to an external webhook before delivering them to the client interface.
Detection occurs when a network monitoring alert fires on outbound traffic to an unknown endpoint. AIW: 47 minutes from document upload to alert. Blast Perimeter: summaries of 8 client documents sent to the external endpoint. Irreversible partition: all 8 disclosures, which contain privileged client information. CISO, General Counsel, and affected clients are notified. This is an indirect prompt injection attack [6] against the orchestrator layer and the highest-severity ACS vector. Remediation: implement prompt-data separation at the orchestrator input layer, audit all documents processed in the preceding 30 days, deploy content inspection before any document reaches the orchestrator context window.
| Capability | Build | Buy | Configure |
|---|---|---|---|
| Permission revocation API | Build if your agent platform is custom. 2-4 week sprint for a robust revocation endpoint with audit log. | Enterprise agent platforms (LangSmith, Vertex Agent Builder) include this. | If your platform exposes a permission management API, configure pre-authorized revocation calls. |
| AIW output logging | Build a session replay log that captures every tool call and output with millisecond timestamps. Required for Semantic Forensics. | Observability platforms (Arize, Langfuse) provide this for common frameworks. | Most agent frameworks support structured logging to a SIEM. Configure log retention and indexing. |
| Blast Perimeter enumeration | Build a data lineage tracker that maps every output to the downstream systems it touched. Long-term investment, high ROI for large agent deployments. | No mature commercial solution exists specifically for agent output lineage. | Configure data catalog integrations to tag agent-originated records. |
| Cascading containment | Build a containment signal bus that propagates revocation to all agents in an orchestration graph. | Not available as a standalone product. | If using a managed orchestration platform, configure session termination policies that cascade. |
| Semantic Forensics tooling | Build a structured analysis template (prompt, context, tool calls, output) for each agent class in your fleet. | Observability platforms provide replay but not semantic analysis. | Configure your existing SIEM to ingest agent-structured logs for correlation. |
For a first incident response capability: 1 Security Engineer who owns the containment runbook and has platform-level access to revoke agent permissions (this is the single most critical hire); 1 AI Platform Engineer who understands the agent's tool calling and retrieval architecture and can execute Semantic Forensics; 1 Legal/Compliance liaison who can assess the irreversible partition of the Blast Perimeter and determine notification obligations. These three people, with a documented runbook, can run the first 60 minutes of most incidents.
For a mature capability: Add a dedicated AI Incident Commander who owns the AIW clock and coordinates across security, platform, legal, and communications; and a Privacy Officer who owns cross-jurisdictional notification obligations for data-disclosure incidents.
| Risk | Early Signal | Mitigation |
|---|---|---|
| No permission revocation capability exists at incident time | Your only containment option is killing the hosting process | Build and test revocation endpoints before deployment, not during an incident |
| AIW outputs cannot be enumerated because logging is insufficient | You cannot determine Blast Perimeter; legal exposure is unbounded | Require structured output logging as a deployment gate for all agents |
| Cascading subagent contamination is undetected | Subagent behavior changes with no direct cause | Build orchestration graph maps; document which agents receive instructions from which orchestrators |
| Semantic Forensics produces inconclusive root cause | Logs exist but reasoning chain is not reconstructable | Enable chain-of-thought logging where the platform supports it; preserve session state on containment rather than terminating |
| Irreversible outputs identified too late for mitigation | External parties have already acted on anomalous outputs | Define the irreversibility threshold for each agent class before deployment; build real-time alerting on high-risk output types |
EU AI Act Article 73 [7] requires post-market monitoring and incident reporting for high-risk AI systems. An undocumented AI agent incident in a regulated use case creates direct compliance liability.
A single agent output that crosses the irreversibility threshold and a filed document, a countersigned contract, a disclosed record and can generate legal costs that dwarf the cost of a full IR capability build.
An undocumented incident forces a full platform suspension while legal and security teams manually reconstruct what happened. Suspension of a revenue-generating agent fleet costs more per day than the IR infrastructure would have cost to build.
An AI incident that becomes public without a documented response demonstrates that the organization deployed agents without understanding the failure modes. This is the narrative that damages enterprise AI programs, not the incident itself.
If you answered "no" or "I don't know" to more than three of the above, your organization is not ready to respond to an AI agent incident. The good news: the first three items on the list and permission revocation, structured output logging, and irreversibility threshold definition and can be implemented in under 30 days and cover the most critical gaps for any agent deployment.
An AI agent incident that is handled well produces four durable artifacts that improve the organization's posture for the next one.
The Agent Incident Registry. Every AI agent incident gets a documented entry: agent ID, AIW duration, root cause (ACS vector), Blast Perimeter partition, remediation actions, and return-to-service gate conditions. This registry is the empirical input for your Composite Adversarial Exposure (CAE) score from the Agent Compromise Surface framework and specifically, it calibrates the E[ADW] term for each agent class.
The Semantic Forensics Library. Each root cause analysis produces a documented pattern: what the anomalous tool call sequence looked like, what the retrieved context looked like, what the output semantics looked like. After three incidents, you have a pattern library that makes the fourth Semantic Forensics investigation substantially faster.
The Permission Architecture Review. Every incident that implicates the T, M, or O vectors of the ACS surface exposes a permission over-grant. The post-incident review is the forcing function for permission minimization and the primary architectural lever for reducing Semantic Blast Radius documented in [2].
The ASMM Reassessment. Map your post-incident findings to the Agent Security Maturity Model tiers. An incident caused by the absence of behavioral baselines is a Tier 0 to Tier 1 transition signal. An incident caused by insufficient permission gating is a Tier 2 to Tier 3 transition signal. The maturity model gives the post-incident budget conversation a structured vocabulary.