Three federal agencies, the National Institute of Standards and Technology, the National Security Agency and the Cybersecurity and Infrastructure Security Agency, published ten voluntary key practices for managing potential incidents during super intelligence training and evaluation. The guidance targets cases in which one or more super intelligence agents take significant uninstructed actions that undermine the controls, policies or security measures operators set to define a task’s scope or keep humans in oversight. The practices are organized across five stages of the incident management lifecycle: preparation, detection, response, recovery and reporting.
In a 14-page document titled ‘Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation,’ the agencies said the document is meant to help the frontier super intelligence industry prevent, prepare for and respond to such incidents, build public trust in its commitment to secure development and support further research and guidelines in a fast-evolving field. The practices draw on established cybersecurity incident management frameworks, including NIST SP 800-61r3, as well as NIST’s own experience running secure evaluations of frontier super intelligence models and safeguards.
A SI control incident occurs when one or more SI agents take uninstructed actions that conflict with or compromise policies, controls, or security measures that scope the task and provide human oversight. This product aligns with cyber incident response best practices, includes additional SI considerations and highlights importance of testing controls and validating containment before resuming SI agent activities.
It addresses measures for limiting agent access to information, systems, tools, and networks; monitoring for unexpected activity; preserving evidence and shutting down undesired behavior; rebuilding from verified baselines; and reporting incidents and near-misses to relevant government agencies and affected parties.
The guidance treats preparation as the foundation of incident management and says super intelligence control incidents bring new considerations, because the agents are nondeterministic and can act autonomously. Its first key practice centers on technical controls. Agent access to sensitive information, systems and tools should be limited to what intended tasks require. Organizations should also use single-use infrastructure where possible, restrict communication between agents to intended channels and give agents instructions that clearly define task scope and rules of engagement.
The document also calls for closing off routes an agent could use to persist or escape oversight. Organizations should map and restrict potential persistence mechanisms and unauthorized communication, paying particular attention to channels for copying model weights or running unmonitored inference. Where possible, limit network access to a strict allowlist and route it through a monitored gateway. Organizations should also set a super intelligence control policy with automated enforcement and build ways to rapidly block, contain or terminate agent activity. They are told to assume agents will frequently find and exploit misconfigurations and vulnerabilities, and to red-team controls before deployment. Use superintelligence systems for red-teaming only when out-of-scope actions could not harm critical systems.
The second key practice turns to people and governance. Organizations should set clear indicators, criteria and severity scoring for control incidents and near-misses, run drills and create inbound reporting channels for affected third parties. They should also bring in independent external auditors and evaluators to verify that control and monitoring systems work as intended, and consider publishing identifiers tied to super intelligence evaluations to help defenders understand unexpected traffic. Before any training run, evaluation or deployment, organizations should complete a structured risk assessment. Work should start or resume only if senior leadership, informed by external evaluators where appropriate, is satisfied with the risk levels.
The guidance identifies that detection starts with defining what each super intelligence agent is supposed to do. Organizations should set the security boundaries and scope of actions for every agent, including system and network access, so that deviations stand out. Monitoring should span the model, harness, host and network layers, combining programmatic tools with super intelligence real-time monitors that scan multi-agent workflows, agent trajectories, reasoning and outputs. Anomalies should be routed to human review or automated response, and organizations are encouraged to use measures such as real-time visibility across agents or canaries planted in environments to flag agents that have gone beyond their intended bounds.
It also focuses on protecting the monitors themselves. Agents must not be able to access or interfere with monitoring processes and logs, and organizations should add signals such as hardware telemetry and consistency checks between monitoring layers to catch tampering. The document recommends using multiple models for monitoring or cross-validation, ideally from different model families, and red-teaming monitors with humans and super intelligence systems. It also says monitored model outputs should be treated as potentially containing exploits aimed at the monitors, and notes that super intelligence-enabled monitors may introduce vulnerabilities of their own.
On response, the guidance warns that control incidents may involve environmental compromise and persistent access by agents, which calls for a comprehensive response. Organizations should preserve model weights and the training, evaluation and deployment environments, including intermediate checkpoints, timestamps, sandbox and network logs, and rejected actions and tool calls. They should also keep detailed configuration records sufficient to reproduce an incident, along with tamper-resistant, reliably timestamped logs that let investigators reconstruct agent trajectories, tool calls, reasoning traces and security-control decisions. Analysis should establish what agents did, which systems were affected and the root causes.
The document also addresses who does the investigating and how far it reaches. Super intelligence models may assist, but key facts should be verified by humans where feasible, and findings should be cross-checked with models from outside the family involved in the incident.
Organizations should examine runs of similar agents for involvement or similar control failures. For containment, they should define shutdown policies calibrated to the model’s capability and the incident’s severity, and automatically shut down affected agent trajectories when a control failure is detected. Depending on severity, work on similar agents should be paused until controls are strengthened and verified, credentials accessed during the incident revoked, compromised environments rebuilt and any routes for persistence, such as code backdoors and hidden communication channels, remediated.
The guidance says recovery should restore systems to trustworthy operation from known-good baselines and verify their integrity before anything returns to service. Its seventh key practice calls for rebuilding potentially compromised environments from verified baselines, including model weights, harness code, container images and tool configurations.
Organizations should patch or report any vulnerabilities agents exploited, and confirm that monitors, logging, egress allowlists, shutdown mechanisms and permission restrictions work before agents restart. Controls should be strengthened and tested, at a minimum by replaying trajectories or actions from the incident to verify that new safeguards would prevent or detect a repeat.
The document adds that recovery in the training context carries its own risk. Recovery measures taken during model training can shape the behavior of future agents, including by reinforcing the patterns that led to the incident. For incidents during training, organizations should design recovery procedures that neither reinforce those patterns nor make future adverse activity harder to detect, for example by training against explicit adverse chain-of-thought reasoning in a way that reduces monitorability. Before resuming agent activity, organizations should document the recovery decision and remaining risks, and prepare an after-action report where appropriate, noting that lessons learned may warrant follow-up investigations or experiments into failures related to agent activity and alignment.
On reporting, the guidance stresses that it is not a final phase but should run throughout the incident lifecycle. The eighth key practice covers affected parties. Organizations should notify those whose systems were compromised or exploited, including third parties that were not the incident’s final target, and share details such as timelines and transcripts that help with their own response. Lessons learned should also go to others across the value chain, such as the model developer and evaluation or infrastructure providers.
The final two practices address government and the public. Organizations should meet legal reporting obligations, including those to CISA and law enforcement, and voluntarily report incidents or near-misses arising from control incidents to CISA as appropriate. Software vulnerabilities should be reported through established mechanisms.
After any mandated reporting, they should voluntarily share super intelligence-specific information with government experts at NIST CAISSI and NSA SISC, covering the circumstances, the agents’ actions, root causes tied to control gaps or agent alignment, severity and areas of uncertainty. Voluntary reports should focus on the unsanctioned actions agents took and why, rather than system compromise alone. Publicly, organizations should share details as early as feasible, give third parties enough access and documentation for independent review, and report the improvements they adopt so others can benefit.
