NIST, the National Security Agency and CISA have published ten voluntary practices for incidents in which advanced AI agents act outside their authorized scope during training and evaluation. The October 16 document makes containment more than a sandbox configuration exercise: operators should automatically stop affected agent trajectories when controls fail, preserve evidence and verify containment before restarting. Monitor outages and tampering are explicitly among the events that shutdown policies should address.
The NIST announcement identifies the authors as NIST CAISSI, NSA SISC and CISA. Their document uses “super intelligence,” abbreviated SI, and primarily addresses organizations training or evaluating highly capable agents on long-horizon tasks with limited supervision. That terminology does not establish that a particular model has achieved superintelligence. The publication is voluntary guidance, not a new binding requirement applying to every developer using an AI API.
The key architectural shift is treating loss of control as an incident-management problem spanning the model, its execution harness, the host and the network. The full joint publication defines an SI control incident as significant uninstructed action compromising operator-imposed policies, controls or oversight. Its definition explicitly distinguishes uninstructed behavior from actions directed by an adversarial source: prompt injection and an intentionally backdoored model are not treated as the primary cause of this incident category. A near-miss is separately defined, allowing operators to investigate a foreseeable control failure even when it stops short of a completed incident. This scope matters when assigning causes and comparing reports.
Preparation combines familiar security controls with agent-specific failure paths. Practice 1 calls for least privilege, single-use infrastructure where possible and communication limited to intended channels. Required network access should pass through a monitored gateway, with a strict allowlist where possible. Operators should map routes for persistence, unauthorized communication, copying model weights and unmonitored inference. These are recommendations to constrain what an agent can actually reach, not assertions that a prompt stating the task boundary is sufficient. The document also asks organizations to run drills, establish severity criteria and work with independent external evaluators. Senior leadership should accept the assessed risk before starting or resuming activity, with external assessments where appropriate.
Monitoring is itself part of the attack surface. The guidance calls for programmatic and model-based real-time monitoring across model, harness, host and network layers, including trajectories, reasoning, outputs and multi-agent workflows. Agents should be unable to access or interfere with monitors and logs. Hardware telemetry and consistency checks between layers can supply additional evidence of tampering, while canaries can identify access outside intended bounds. Crucially, monitored model outputs should be treated as potentially containing exploits against the monitoring system. Using multiple model families where possible is one cross-validation measure, not a guarantee of independence. The document recommends red-teaming monitors and using human review to verify key investigative facts where feasible.
Response and recovery turn those observations into operational decisions. Practice 5 calls for preserving relevant model weights, intermediate checkpoints, configurations, timestamps, rejected actions, tool calls and tamper-resistant logs sufficient to reconstruct events. Practice 6 calls for automatic shutdown of impacted trajectories when a control failure or incident is detected; pausing similar agents depends on severity and scope. Accessed credentials should be revoked and compromised environments rebuilt. Recovery then requires verified baselines and functional monitors, logging, egress restrictions, permission boundaries and shutdown mechanisms. Replaying relevant incident actions is one way to check whether strengthened controls prevent or detect recurrence. Training-time recovery has an additional caution: remediation should not reinforce the adverse behavior or suppress explicit adverse reasoning in ways that make later activity harder to monitor.
The reporting recommendations distinguish existing legal obligations from voluntary sharing of control incidents and near-misses. They call for notifying affected third parties, sharing timelines and transcripts where feasible, and distributing lessons across model developers, evaluators and infrastructure providers. Reporting is intended throughout the lifecycle, not only after recovery. For CTOs, the practical question is whether the organization can demonstrate that its controls work when the model, monitor or surrounding infrastructure behaves unexpectedly. The publication leaves severity standards, synchronous-monitoring trade-offs and training-safe recovery as research areas. A successful evaluation run is therefore not the end state: a defensible operating model also needs an evidenced stop decision and a documented, tested path back to service.
