Your incident response plan assumes a human adversary. Someone phishes a credential, moves laterally, exfiltrates data, and leaves artifacts you can trace. The four phases of the NIST SP 800-61 Rev. 2 lifecycle, preparation, detection and analysis, containment and eradication and recovery, then post-incident activity, were written against that model of the world, and the federal playbooks that operationalize them inherit the same assumption, even though NIST replaced Rev. 2 in April 2025 with a Rev. 3 organized around the CSF 2.0 functions. When the actor is a model rather than a person, every phase shifts and two of them, detection and analysis and containment, change shape outright, and the runbook you rehearsed last quarter answers questions the incident is not asking.
This is a walkthrough for that case. The AI system is the cause or the amplifier: a chatbot that leaks data because someone asked it the right questions, an agent that takes an unauthorized action, a retrieval pipeline poisoned upstream of any code you own. The structure below keeps the NIST spine because your auditors and your muscle memory both expect it. What changes is what each phase means when there is no login to disable and no host to reimage.
The consensus runbook, and where it stops
The federal incident response playbook is a good baseline. It walks an FCEB agency through preparation, detection and analysis, containment, eradication and recovery, and post-incident activities, and it applies to incidents that involve confirmed malicious cyber activity for which a major incident has been declared or not yet been reasonably ruled out. A playbook, in the discipline's own terms, is a repeatable guide during chaotic scenarios that improves technical accuracy and cross-team coordination. Neither of those is wrong. Both were built for an attacker who is a person operating tools.
The Coalition for Secure AI names the gap directly. Traditional response assumes you isolate compromised systems, analyze logs, patch, and restore from backups, but AI systems face threats where an attacker does not break in, they ask your chatbot the right questions. Prompt injection, memory poisoning, context poisoning, model extraction, and jailbreaking do not leave the artifacts your detection logic hunts for. The CoSAI framework keeps the NIST lifecycle and adapts each phase for AI systems rather than replacing it, which is the right instinct and the one this walkthrough follows.
Figure 1: Two of four NIST SP 800-61 Rev. 2 phases, detection and analysis and containment, change fully under a model actor. Preparation and post-incident change partially, and only post-incident needs no new telemetry.
The classes of threat that break the assumption are not exotic. They are the ordinary failure modes of systems that take natural language as input and produce actions as output. That is why the fix is not a new framework. It is a different reading of the phases you already run.
Preparation: instrument the model as well as the host
The preparation phase in a traditional plan is about coverage: asset inventory, logging, response team rosters, communication trees. All of that carries over. What it misses is that your endpoint and network telemetry cannot see the event that matters. A prompt injection lives inside a model input. An unauthorized tool call lives inside an agent's reasoning trace. Neither shows up in a firewall log.
CoSAI's preparation guidance is specific about what to capture: prompt logs, model inference activity, tool executions, and memory state changes. If you are not logging those four streams before the incident, your detection and analysis phase has nothing to analyze. This is the AI-specific version of the oldest lesson in the discipline, that you cannot investigate what you did not record, and it is the one place where doing the work early is not optional.
Preparation is also where you decide what you are allowed to do under pressure. The frontier-model incident work frames post-deployment response as a toolkit of deployment corrections: user-based restrictions, access frequency limits, capability or feature restrictions, use case restrictions, and model shutdown. Those authorities have to exist as pre-agreed, allowable actions before you need them. A containment step you have not been authorized to take is a meeting, not a control.
Detection and analysis: the signal is behavioral
In a traditional incident, detection keys on indicators of compromise: a hash, a domain, an IP, a known-bad process. AI incidents often look different from traditional security events, and CoSAI points detection at model drift, suspicious prompt patterns, and unusual retrieval behavior in RAG systems instead. The question you are asking shifts from "what got in" to "why is the model behaving unlike itself."
Agentic systems raise the analysis stakes because autonomy is a spectrum, not a switch. CoSAI describes systems ranging from perceptively autonomous assistants, through reactively autonomous agents that observe but act under human direction, to partially autonomous systems that act while seeking approval, and finally to fully autonomous agents requiring no human supervision. Your triage has to fix where the offending system sits on that ladder, because it determines how fast the harm compounds and how much of the response you can hand to a human.
Severity classification still governs the clock. The OWASP Agentic Skills Top 10 incident response playbook, an OWASP incubator project still at version 0.0.0, keys response time to severity, from a one-hour response for critical, active exploitation in production, up to a week for a low, no-immediate-risk finding, with mass deployment of malicious skills and confirmed data exfiltration at the top of the scale and a confirmed malicious skill one rung below it at four hours. The classification exercise is the same. The evidence you classify on is prompt content and inference behavior rather than payloads and process trees.
Figure 2: The playbook keys the response clock to severity, in its own units. The window widens by roughly an order of magnitude at each step down.
Automation earns its place in this phase for a concrete reason. Guided-response research shows why full automation stays rare in remediation: a fully automated system needs an exceptionally high confidence threshold, on the order of 99 percent, to avoid disabling critical assets by mistake. That is the argument for keeping a human at the containment decision even when detection and triage are machine-assisted, and it applies with double force when the asset you might disable is the model your business runs on.
Containment: correcting a deployment, not isolating a host
This is where the AI incident diverges hardest from the runbook. You cannot pull the network cable on a behavior. Containment when the actor is a model means graduated correction of the deployment, and the frontier-model framework lays out the range: user-based restrictions, access frequency limits, capability or feature restrictions, use case restrictions, and full model shutdown. These are meant to be mixed and matched against the threat model. Filtering outputs suits a model producing dangerous biological or chemical designs, while rate limits reduce the scale of a model producing harmful output at speed.
CoSAI's containment guidance is architecture-specific for the same reason. The right move depends on the system: roll back to a previous model version, purge poisoned memory, or rebuild the vector database. A memory-poisoning incident and a RAG-poisoning incident both present as bad output, and they need different containment. That is why the analysis phase has to identify the architecture pattern before containment picks a tool.
Model shutdown deserves the same caution the traditional playbook gives to pulling a production system offline. The frontier work treats emergency shutdown as a distinct decision with its own considerations, because full market removal or destruction of the model is the most disruptive correction available and the hardest to reverse. Shutdown is a legitimate control. It is not the default, and treating it as one turns every AI incident into an outage.
Evidence preservation: capture the volatile state first
Traditional forensics preserves disk images, memory, and logs. AI forensics adds a category the old process does not name: the volatile, ephemeral state that produced the behavior. The prompt that triggered the action, the model version and inference parameters, the retrieved context, the agent's tool-call trace, and the memory contents at the moment of the incident are all evidence, and several of them are overwritten by the next request.
This is why the telemetry you established in preparation is also your evidence base. CoSAI's four streams, prompt logs, model inference activity, tool executions, and memory state changes, are the AI-specific chain of custody. If containment purges poisoned memory before you have captured it, you have eradicated the incident and the evidence in one move. Sequence the capture before the purge. A legacy runbook has no reason to specify that ordering, because on a host the disk image survives eradication and a model's memory does not.
The handoffs: internal escalation and external sharing
A model incident crosses more desks than a host compromise. The Agentic Skills Top 10 playbook assembles a response team spanning a security engineer as lead, a platform administrator, a threat intelligence analyst, a communications officer, and legal or compliance, and it separates that internal team from the platform operators who remove a malicious artifact. When your AI runs on someone else's platform, part of your containment is a request to a party you do not control, and that handoff has to be rehearsed rather than improvised mid-incident.
The external handoff has its own playbook. CISA's collaboration guidance is built for voluntarily sharing AI-related cybersecurity information with CISA and Joint Cyber Defense Collaborative partners, and it is careful about scope. Risks to human life, health, property, or the environment sit outside the JCDC playbook's scope and route through your own safety procedures instead. That boundary matters during triage, because an AI incident can be a cybersecurity event and a safety event at once, and the two travel different escalation paths.
Post-incident: build knowledge that transfers across architectures
The post-incident phase in the federal playbook exists to catalog incidents and improve future response. CoSAI keeps that intent and adds a demand specific to AI: understand both the technical root cause and how to prevent the same attack across different AI architectures. A memory-poisoning lesson learned on one agent should transfer to the next agent you deploy, and that only happens if the postmortem is written at the level of the architecture pattern rather than the single system.
This is also where governance closes the loop. The NIST AI RMF Playbook is explicit that it is neither a checklist nor a set of steps to follow in its entirety, with voluntary suggestions mapped to the Govern, Map, Measure, and Manage functions. Read against incident response, the Manage function is where a lesson learned becomes a control, and the Govern function is where you assign the authority to take deployment corrections before the next incident forces the question.
What to change on Monday
Keep your NIST-aligned playbook. Do not fork it. Add four things that the model case demands and the host case does not. Turn on the four telemetry streams so detection and evidence have something to work with. Pre-authorize the deployment corrections so containment is a control and not a meeting. Sequence evidence capture before memory purge so eradication does not destroy the record. Rehearse the platform-operator and CISA handoffs so the parties you do not control are not a surprise. None of that is a new discipline. It is the discipline you have, read for an actor who does not log in.