NIST, NSA and CISA published voluntary practices for AI incident response

NIST, NSA and CISA published voluntary practices on 16 October 2026 for incident response to unauthorised or unexpected AI-agent behaviour. Treat such cases as a separate control incident: qualify the signal, freeze evidence, contain outside the model, determine the impact, recover from a verified baseline and authorise resumption only after a demonstrable retest.

The trigger is a joint publication by the NIST Center for AI Standards and Innovation (CAISSI), the NSA Secure Intelligent Systems Center and CISA, titled Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. The text introduces the concept of a control incident: a case in which a highly capable AI agent acts outside what was intended or authorised. Near-misses, situations that almost went wrong, are also given a place in the framework.

These practices are explicitly voluntary and primarily aimed at organisations that train or evaluate highly capable agents. In our judgement, however, the distinction the publication makes is more broadly useful: any organisation that gives agents access to tools, systems or transactions benefits from a boundary set out in advance between an ordinary mistake and an incident.

What exactly do the new NIST, NSA and CISA practices for AI incident response involve?

The publication distinguishes five phases: Prepare, Detect, Respond, Recover and Report. Among other things it calls for independent monitoring, logs that the agent itself cannot modify, securing evidence, an automatic shutdown, revoking credentials, recovery from verified baselines and documenting residual risks. The core is that response does not end with stopping a faulty outcome.

Academic research supports that approach. The study AIR: Improving Agent Safety through Incident Response proposes an incident-response framework for LLM-agent systems covering detection, containment, recovery and eradication. In its reported experiments, AIR achieves detection, remediation and eradication success rates above 90%, but the authors stress that response rules generated by a language model require human validation and correction. In other words: an agent must not be the sole assessor of its own containment.

Which steps belong in a playbook for a derailing AI agent?

A defensible playbook follows a fixed sequence and sets out in advance who may take which step. The six steps below summarise the official practices and the supporting research in a workable series.

1. Qualify the signal. Is it a hallucinating or faulty outcome, an unauthorised tool action, a possible data breach, external impact or a near-miss? Set the criteria in advance.
2. Freeze and protect evidence. Model and tool version, prompt and context artefacts, timestamps, logs, network data, credentials, refused actions and environment state.
3. Contain outside the model. Pause the trajectories, revoke credentials, block outbound traffic and isolate affected systems — not via the model itself.
4. Determine the blast radius. Which systems, third parties or transactions have been affected, and which legal or contractual reporting route applies?
5. Recover from a verified baseline. Retest monitors, logging, allowlists, permissions and shutdown mechanisms before anything is restored.
6. Authorise resumption only after a retest. A responsible director documents the residual risks and a retest must be able to detect or block comparable behaviour.

The study evaluates, offline on recorded AgentDojo, STAC and related benchmark trajectories, whether formal monitors can identify specified obligations in tool-use traces. On the evaluated corpora, the monitors flag many, but not all, attack chains and also trigger on some benign runs. For that reason, an activity log on its own is no guarantee of a complete reconstruction; a playbook must additionally record which context, approvals, provenance and timestamps are available. This aligns with a second response playbook alongside your cyber runbook and with our piece on splitting incident triage from the reporting duty for AI incidents.

Why is an ordinary cyber incident plan not enough for unauthorised model behaviour?

Because an agent can overstep its task or authorisation boundaries without there being a classic data breach. The comparative study by Abbas Raftari compares incidents around agent evaluations at OpenAI, Anthropic and Google and argues that the relevant safety boundary encompasses the full execution system: goal, model, harness, tools, identities, networks, shared state, monitors and human authorities.

Our analysis is that a single agent action could create a cross-system effect or affect a third party without producing the kind of alert a traditional cyber team normally expects from a data breach. The study treats the public information about the Gemini incident as limited and provisional, moreover; we adopt that caution. The assurance model proposed by the author emphasises executable scope, least privilege, independent containment, predefined stop conditions and re-authorisation based on evidence. That aligns with the shift from model promises to independently verifiable proof and with the broader discussion of control and oversight of agentic AI.

What does this mean for directors, lawyers and CISOs who must assign AI response?

Our analysis: because the official practices call for independent monitoring and evidence-based re-authorisation, we consider it defensible that whoever manages the agent is not at the same time the person who approves its own containment; we therefore advise a director to appoint a separate person responsible for the AI control-incident track, independent of the team keeping the agent in production. Because an unauthorised model action could affect a third party, an external system or, in some deployments, a financial transaction without a classic data breach, we advise that the legal function investigate in advance which contractual and regulatory reporting routes may be relevant; it is therefore advisable to set those reporting criteria before the first agent goes live, not afterwards. If the organisation wants to support full reconstruction, we advise not relying solely on an ordinary activity log; the CISO can therefore require that tool calls, approvals and timestamps be recorded with appropriate integrity safeguards and that their relationship to the original request be documented. And because response rules proposed by a model require human validation, we advise that resumption takes place only after a documented decision by a human; in our judgement the board therefore links the resumption decision to a name and a retest, so that it can afterwards be demonstrated who approved what.

The open question the sources do not answer is how organisations arrange that human validation and independent monitoring in practice without undermining response time. In our judgement the answer lies in assigning roles in advance: predefined stop conditions that may be triggered without a meeting, and a separate re-authorisation decision that does rest with a human.

Sources: The article relies on the joint publication by NIST CAISSI, NSA SISC and CISA (16 October 2026) and on academic research from ICML (AIR), Abbas Raftari (arXiv) and CPSIoTSec '26 (ACM).