NIST’s New AI Incident Playbook Starts After an Agent Crosses a Boundary

A model that crosses a boundary creates two problems. First, someone must stop the action. Then the team has to work out what happened, what the agent touched, whether the monitoring system was trustworthy and whether the environment is safe to use again. A shutdown button solves only the first problem.

On 16 October 2026, NIST, the National Security Agency and the Cybersecurity and Infrastructure Security Agency published ten voluntary practices for incidents during highly capable agent training and evaluation. The intended audience is narrow: teams running long-horizon tasks with limited human supervision, with possible relevance to deployers too. The document does not create a new law or claim that the practices solve agent behavior. ^[1]

Its central idea is familiar to security teams: prepare before an incident, detect activity that departs from the expected scope, respond without losing evidence, restore from a known-good state and share what affected parties need to know. The new part is translating that approach into an environment where the system itself can take discretionary actions through tools, networks and other software.

The five stages are a working checklist

The guide groups its voluntary practices into five stages: prepare, detect, respond, recover and report. Teams still need to map them to their own threat model and reporting obligations. ^[1]

Prepare: make the boundary enforceable

Before a run begins, define its scope, limit tools and reachable systems, and decide what counts as an incident or near-miss. The guide recommends technical controls alongside personnel readiness. ^[1]

These details matter because instructions alone are not a security boundary. A prompt may state “do not contact external systems,” but the environment still needs to make that action unavailable or observable. The engineering question is whether the restriction holds when the model, its harness, a dependency or a monitoring process behaves unexpectedly.

A useful tabletop exercise is to give the response team a plausible boundary crossing and ask whether it can answer three questions quickly: what credentials were exposed, which systems were reachable, and who has authority to pause the run? If the answers depend on a person remembering an undocumented setup, preparation is incomplete.

Detect: monitor the whole agent system

A tool-using agent is more than a model response. Detection needs visibility across the model, harness, host and network; teams should also test whether monitoring and logs can be trusted. ^[1]

That changes what a useful evaluation trace contains. A transcript can show what the model said, but it may not reveal which tool call was attempted, whether a permission layer rejected it, what the host actually executed or whether network activity matched the allowed destinations. Teams need a coherent timeline across those parts of the system.

This is close to ordinary cybersecurity practice, where detection depends on logs and telemetry that can be trusted. NIST’s broader incident-response guidance places preparation, detection, response and recovery within cybersecurity risk management. The agent-specific guide extends that operating discipline to systems that can choose actions while a task is underway. ^[2]

Respond: stop the trajectory and preserve evidence

The first response should prevent further unwanted activity while preserving enough evidence to reconstruct it. Affected runs may need to stop, systems may need isolation and credentials may need revocation. ^[1]

This is where teams can accidentally destroy the information they need. A quick reset may restore a clean machine while erasing the sequence that explains why the agent escaped its intended scope. Preserve a controlled snapshot before rebuilding, subject to the organization’s safety and data-handling rules.

An agent-control incident can overlap with a conventional cybersecurity incident, but the concepts are not identical. Describe both the boundary failure and any external compromise rather than assuming one proves the other. ^[1]

Recover: verify the fix before resuming

Recovery should establish a verified baseline and check that changed controls work before a run resumes. Replaying the failure path is one way to test whether the response addressed the cause. ^[1]

Training adds a subtle complication. A team may change a model or its environment after an incident, but a corrective intervention can affect how later activity is monitored or interpreted. The guide specifically raises the possibility that a recovery procedure could make future adverse behavior harder to detect. This is a reason to preserve the incident trace and involve evaluators who can assess both the new behavior and the quality of the monitoring.

A recovery decision should therefore include more than “the process starts.” Record which controls were changed, which failure path was replayed, what residual risk remains and who approved the restart. For a broader discussion of how persistent actions and permission boundaries interact, see our guide to helpful AI persistence and permission boundaries.

Report: include near-misses, not only confirmed harm

Reporting covers coordination with affected parties and sharing lessons from incidents and near-misses. The guide treats communication as part of the lifecycle, not only a final post-recovery step. ^[1]

This is useful because a near-miss can reveal a weak boundary before it causes external harm. But a voluntary practice does not replace mandatory reporting rules. Teams still need to follow the laws and existing incident obligations that apply to their organization and the systems involved. NIST’s general cybersecurity framework remains the larger management structure behind much of the document. ^[3]

What teams can put in place this week

A small evaluation team does not need a new committee to start. Before the next long-running agent test, write a one-page incident sheet with:

• the intended task, allowed tools, networks and data;
• the signals that count as a control failure or near-miss;
• the person who can pause the run and revoke credentials;
• the logs and checkpoints required to reconstruct a tool trajectory;
• the known-good environment used for recovery;
• the tests that must pass before the agent resumes;
• the people who need notice, including affected external parties.

The point is not to make every experiment bureaucratic. It is to avoid improvising under pressure when a system with tools has already acted outside its scope.

The ten practices are a voluntary starting point for a specific set of high-capability training and evaluation settings. Their value will depend on whether teams translate them into controls that are actually enforced, monitors that can be tested and recovery decisions that preserve accountability. A model stopping is an event. A trustworthy incident process is what comes next.