When an Agent Goes Out of Bounds: Shut Down, Investigate, Restart
Stop the run, keep the evidence, check containment before restarting, and tell the people affected
Operator recipe for the incident itself, built from the ten voluntary key practices NIST, the NSA and CISA published in October 2026 (Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, PP-26-4396, Ver 1.0). The document defines an "SI control incident" as an occurrence in which one or more agents takes "significant uninstructed actions that compromise explicit or implicit policies, controls, or security measures imposed by the operator". Actions caused by a prompt injection or a backdoored model count as instructed, so they fall under ordinary security response rather than this definition. The practices are aimed mainly at organisations training or evaluating highly capable agents on long-horizon tasks with limited human supervision, and the authors say they "may also apply to deployers of such SI agents". They are voluntary and the document says it is not advice for compliance or legal purposes. This recipe covers what happens once something has gone wrong; for keeping agents inside their scope before that, see /playbooks/agent-overreach-containment/.
Core Workflows (7)
Each workflow represents a critical business function. Click any workflow to see detailed automation architecture.
Write the shutdown policy and build the kill path before you need it
Led by: Incident OwnerThe document asks operators to "Build mechanisms to rapidly block, contain, or terminate agent activity if an incident or near-miss is detected" and to set "clear indicators, criteria, and severity scoring" for incidents and near-misses. Write down which signals stop a run, who can stop it, and what happens to other runs of the same agent. Include monitor outages and signs of tampering as triggers, not only bad actions. Then drill it: the practices call for drills and simulations covering detection, response, recovery and reporting.
Stop the affected runs automatically
Led by: MonitorPractice 6.2 says to "Automatically shut down impacted SI agent trajectories on detection of a control failure or in-progress SI control incident". Do not wait for a person to read an alert. Depending on how severe the incident is, also pause other runs of similar agents until the controls have been strengthened and checked (6.3).
Revoke what the agent touched and close its ways back in
Led by: Host AuthorityRevoke credentials under your control that were accessed during the incident and rebuild any environment that may have been compromised (6.4). Then look for ways the agent could carry on after the stop: the practices name "code backdoors and hidden communication channels" (6.5). This is easier when each agent has its own credentials. See /playbooks/agent-credential-architectures/.
Keep logs the agent cannot edit, and enough to replay the run
Led by: Incident ReviewerPractice 5.3 asks for "tamper-resistant logs with reliable timestamps sufficient to reconstruct agent trajectories, tool calls, reasoning traces, user interactions, environmental states, and security-control decisions". Also keep the agent configuration, safeguards and environment details needed to reproduce the incident (5.2), and rejected actions and tool calls (5.1). Agents should not be able to reach or change their own monitoring and logs (3.3). If you use a model to help investigate, check key facts with a person and cross-check with models from a different family (5.5). Check other runs of similar agents for the same failure (5.6).
Check containment works before the agent runs again
Led by: Incident OwnerRebuild from verified baselines such as model weights, harness code, container images and tool configurations (7.1). Then "Validate that monitors, logging, egress allowlists, shutdown mechanisms, permission restrictions, and other containment layers are functional before SI agents are restarted" (7.3). Test the fix by replaying the trajectories or actions from the incident against the new controls (7.4). Before resuming, write down the decision to restart and the risks that remain (7.5), and prepare an after-action report (7.6).
Tell the people whose systems were hit
Led by: Incident OwnerNotify parties whose systems were compromised or exploited, "including third parties who are not the final target of the incident" (8.1), and share timelines and transcripts that help their own response where feasible (8.2). Share lessons with others in the value chain, such as the model developer or infrastructure providers (8.3). Report software vulnerabilities the agent found through established disclosure channels (9.2).
Meet reporting duties, then consider voluntary reports
Led by: Incident OwnerFirst meet any legal reporting duties, including cybersecurity incident reporting to CISA or law enforcement (9.1). The practices also invite voluntary reports of control incidents and near-misses to CISA and to NIST CAISSI and NSA SISC, focused on "the unsanctioned actions taken by the agents and explanations for these actions, rather than system compromise alone." Where appropriate, share details publicly as early as feasible (10.1). Outside the US, check the reporting rules in your own jurisdiction.