NIST, NSA and CISA practices for AI incident response

You must now treat an unauthorised or unexpected action by an AI agent as a separate class of incident, with its own detection, containment and evidence-preservation procedures distinct from your standard cyber playbook. Response requires independent oversight at each stage, documented human approval before any agent resumes operation, and advance agreement on which external parties must be notified.

An analysis of 27 October 2026 of incident-response practices for unauthorised AI-agent behaviour argues that organisations deploying capable agents should treat control incidents—cases in which an agent acts outside its intended scope—as a distinct operational risk requiring their own containment and recovery sequence. The framework distinguishes between actual breaches of agent boundaries and near-misses, both of which warrant structured response. In our assessment, this distinction matters because an agent can overstep its authorisation without triggering the alerts your cyber team normally expects from a data breach, and because the consequences may affect third parties or external systems without producing a classic security incident.

What counts as a control incident rather than an ordinary error?

A control incident occurs when a highly capable agent acts outside what was authorised or intended. The official practices treat near-misses—situations that almost went wrong but did not—as part of the same framework. The distinction is important because an agent might execute a tool call that violates its task boundary, access a system it should not have reached, or affect a third party without any personal data being exposed. Your ordinary mistake-handling process does not capture these cases. The boundary between routine failure and incident should be set in advance, not discovered in retrospect.

Which concrete controls does the framework require?

• Independent monitoring — logs and activity records that the agent itself cannot modify or delete.
• Automatic shutdown on boundary violation — predefined stop conditions that trigger without requiring a meeting or escalation delay.
• Credential revocation — immediate withdrawal of the agent's access to tools, systems and identities once containment begins.
• Recovery from verified baseline — restoration from a known-good state, not from the agent's own proposed remediation.
• Documented human re-authorisation — resumption only after a named individual has reviewed evidence and approved restart in writing.
• Integrity-protected records — tool calls, approvals and timestamps captured with safeguards against tampering, linked to the original request.

How should you structure the response sequence?

The official framework sets out five phases: Prepare, Detect, Respond, Recover and Report. Preparation means assigning roles in advance—who may trigger shutdown, who approves containment, who decides on resumption, and which external parties must be notified. Detection relies on independent monitors that flag when an agent has crossed a boundary you have defined. Response freezes evidence, revokes credentials and stops the agent outside the model itself. Recovery restores from a baseline you have verified separately. Report documents what happened and what residual risks remain.

The critical point is that response does not end when you stop the faulty action. Academic research on incident response for language-model agents reports detection and remediation success rates above 90 per cent in controlled settings, but emphasises that response rules generated by a model require human validation and correction. An agent must not be the sole assessor of its own containment. This means your re-authorisation decision cannot rest with the team running the agent in production; it must rest with someone independent.

Why should your legal function act before the first agent goes live?

Because an unauthorised agent action could affect a third party, trigger a contractual obligation, or cross a regulatory boundary without producing a data breach, your legal team should investigate in advance which reporting routes may be relevant. Determine now which external parties—regulators, counterparties, customers—must be notified if an agent oversteps its scope. Set those reporting criteria before deployment, not after an incident. This prevents you from discovering mid-crisis that you have a contractual duty to notify someone you did not know about.

What can tooling do, and what remains your own judgement?

Activity logs and formal monitors can flag many agent actions that cross a boundary, but they do not flag all of them and they do trigger on some benign runs. No automated system can guarantee complete reconstruction of what happened. Tooling can enforce the sequence—shutdown, credential revocation, evidence preservation—but it cannot replace the human decision to resume. The open question the sources do not answer is how to arrange independent validation and monitoring without undermining response time. In our judgement the answer lies in role assignment in advance: predefined stop conditions that may be triggered without delay, and a separate re-authorisation decision that does rest with a human and is documented with a name and a retest.

The shift from model promises to independently verifiable proof means you cannot rely on an agent to tell you it has contained itself. Assign the containment-approval role to someone outside the production team, require that person to sign off on evidence before resumption, and ensure your CISO can verify that tool calls and approvals are recorded with integrity safeguards. That is the core of a defensible playbook.