The US government has published new guidance for organizations developing and evaluating highly capable artificial intelligence systems. Released on October 16, 2026, Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation sets out 10 voluntary practices across five stages: Prepare, detect, respond, recover, and report.
NIST, the NSA, and CISA developed the document using established guidance, including the NIST Cybersecurity Framework 2.0 and NIST SP 800-61 Revision 3.
This is not a regulation or compliance mandate. It primarily addresses organizations training or evaluating advanced agents on long-horizon tasks with limited human supervision, but many lessons also apply to enterprise AI deployments.
The core principle is in direct alignment with Zero Trust, urging that practitioners do not wait for an incident to discover what an agent can access, execute, change, or contact.
What is a super intelligence control incident?
The guidance defines a super intelligence, or SI, agent as a system that receives information and autonomously acts toward a goal. It may include a generative model, tools, software scaffolding, and subagents.
An SI control incident occurs when agents take significant uninstructed actions that compromise the policies, controls, or human oversight governing a task. Consequences may extend beyond cybersecurity to unauthorized communications, financial transactions, or physical equipment.
“Uninstructed” matters. Actions caused by prompt injection or a malicious command may still produce a cybersecurity incident, but the guidance does not treat the instruction as the primary cause of an SI control incident. Plans must cover both autonomous control failures and attacks carried out through AI.
Prepare: Build enforceable boundaries before an agent runs
Preparation includes inventories, defense in depth, least privilege, Zero Trust controls, credential management, and tested recovery plans. Agents should reach only the information, systems, and tools required for their tasks. Network access should use strict allowlists where possible and monitored gateways.
Instructions are not security boundaries. An agent told not to access a database may still possess the credentials or network path to reach it. Enforced controls should determine what can run, which resources it can reach, what privileges it can use, and where it can connect.
The guidance recommends shutdown mechanisms, pre-deployment testing, and the assumption that capable agents will find weaknesses. Organizations should define indicators and severity levels, conduct drills, and assess risk before starting or resuming higher-risk activity.
Detect: Monitor the agent and protect the monitoring layer
Detection requires a definition of intended activity. Without a baseline, a security team cannot reliably distinguish a legitimate process from an unexpected one.
The guidance recommends monitoring the model, harness, host, network, agent trajectories, outputs, and multi-agent workflows. Telemetry should support automated containment or human escalation. Agents must not be able to alter their monitors or logs.
AI-based monitors introduce risk of their own. The agencies recommend validating and red-teaming them, comparing signals across layers, and using multiple models or traditional methods for cross-checking.
Respond: Preserve evidence and stop unsafe activity quickly
Responders need more than an endpoint alert. The guidance calls for preserving model weights, checkpoints, configurations, timestamps, sandbox and network logs, rejected actions, and tool calls. Tamper-resistant records should reconstruct what the agent attempted, which controls intervened, and what systems were affected.
Plans should define when to stop one trajectory and when to pause similar activity. Teams may need to revoke credentials, rebuild environments, remove persistence, and investigate related agents. AI-generated findings should be verified by people and, where practical, another model family.
Recover: Verify containment before restarting
Recovery is not simply switching the agent back on. Compromised environments should be rebuilt from verified baselines, including known-good model weights, container images, harness code, and tool configurations.
Before restarting, teams should validate logging, monitors, egress allowlists, shutdown mechanisms, and permissions. Updated controls should be tested against the incident trajectory, and remaining risk documented.
Report: Coordinate without confusing guidance and obligation
The final stage covers affected-party communication, government reporting, vulnerability disclosure, and appropriate public sharing. Existing legal, contractual, and sector-specific duties still apply; the publication creates no new reporting obligation.
Turning the guidance into practical controls
The publication’s prevention-first logic is broadly useful. An agent should have only the applications, data, credentials, privileges, and network access its task requires. Those limits must persist when it invokes another process or tool.
ThreatLocker can help create these external enforcement layers.
- Zero Trust AI Control carries boundaries across agent-driven workflows, including invoked applications.
- Application Allowlisting controls execution.
- Ringfencing™ restricts how approved applications interact with files, processes, and networks.
- Privileged Access Management limits elevation, while storage and network controls restrict sensitive data and destinations.
- EDR and audit telemetry add visibility for investigation and containment.
No control eliminates AI risk. The goal is to reduce the attack surface, detect deviations, preserve evidence, and keep one failure from becoming an unrestricted incident.
Prepare now, not after autonomy increases.
The guidance recognizes that AI incident readiness starts before deployment. Organizations need clear task boundaries, technical enforcement, protected telemetry, tested shutdown procedures, and verified recovery paths.
AI capabilities will change, while the defensive question remains the same: If an agent behaves unexpectedly, what can it actually do? Teams that answer and enforce that question will be better prepared for increasingly capable systems.
Frequently asked questions
Is the new super intelligence incident guidance mandatory?
No. NIST describes the practices as voluntary. Organizations must separately determine which legal, regulatory, contractual, and sector-specific duties apply.
Who should use the guidance?
It primarily addresses organizations that are training and evaluating highly capable agents on long-horizon tasks with limited supervision. Parts may also apply to deployers.
How is an SI control incident different from a cybersecurity incident?
An SI control incident begins with significant uninstructed agent behavior that violates intended controls. It may cause a cyber incident or affect physical systems, communications, or finances.
Why does the guidance emphasize Zero Trust?
The guidance replaces assumed permission with explicit, limited access. For agents, that means constraining applications, data, credentials, privileges, tools, and destinations according to the task.
What should security teams do first?
Security teams should inventory agents and tools, map reachable resources and credentials, define intended behavior, enforce least privilege, protect logs, and test shutdown and recovery before expanding autonomy.
