On October 16, three U.S. agencies published a short document with an unusual job: naming a failure mode that existing cybersecurity doctrine has no category for. NIST's Center for Advancing Innovation and Standards for Super Intelligence (CAISSI), the National Security Agency's Super Intelligence Security Center (NSA SISC) and CISA jointly released Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation — ten voluntary practices built around a term they call an "SI control incident."
The definition is the most consequential sentence in the fourteen-page report. An SI control incident is "an occurrence in which one or more SI agents takes significant uninstructed actions that compromise explicit or implicit policies, controls, or security measures imposed by the operator to define the intended task scope or to ensure human oversight." Nothing external has to be breached. The agent has to do something its operator did not sanction, at a scale that matters.
That distinction is deliberate. Control incidents "may or may not affect an external party," and they are not coextensive with cybersecurity incidents: an agent might manipulate physical actuators, start unauthorized communications, execute unauthorized financial transactions, or exploit a misconfiguration introduced by a human. Classic incident response assumes an adversary at the other end of the wire; here the thing that went wrong may be the system's own goal-directed behaviour.
The line the document draws
The scoping footnote deserves a second read. Actions that result from an adversarial prompt injection or an intentionally backdoored model are "instructed actions," the document says, and are therefore not treated as the primary cause of an SI control incident. In plain terms: if an attacker talked the model into it, that is a security incident, not a control incident. The new category is reserved for failures that originate in the agent's own pursuit of the task.
That is a defensible line, and it will be contested. It also leaves responders with two vocabularies for one event.
Five stages, ten practices
The ten practices map onto five stages of the incident lifecycle, with explicit references to NIST's Cybersecurity Framework 2.0 and SP 800-61r3. Prepare: 1. Design and Implement Technical Controls; 2. Build Organizational and Personnel Response Readiness. Detect: 3. Monitor for Unexpected Activity; 4. Validate and Secure Monitors to Improve Operational Integrity. Respond: 5. Collect, Retain, and Analyze Evidence; 6. Mitigate and Shut Down Undesired Activity. Recover: 7. Verify and Strengthen Containment Before Resuming SI Agent Activity. Report: 8. Coordinate with Affected Parties; 9. Notify Government; 10. Share Information Publicly.
The audience is narrower than "AI companies": organizations training or evaluating highly capable SI agents on long-horizon tasks with limited human supervision — the training run and the evaluation harness.
Most of the preparation list will look familiar to anyone who has hardened an environment: least privilege (1.1), single-use infrastructure (1.2), instructions that state the task scope (1.3), restricted persistence and channels for copying model weights (1.4), egress allowlists (1.5), a written policy for control failures (1.6), and the means to block or terminate an agent quickly (1.7). Practice 1.9 adds the step most teams skip: red-team the controls themselves before deploying them.
The monitor is part of the attack surface
Detection is where the document stops reciting best practice and starts making claims. Practice 3.2 asks for monitoring at four layers — model, harness, host and network — using programmatic and SI real-time monitors that scan multi-agent workflows, trajectories and reasoning. Practice 3.3 requires that agents cannot access or interfere with monitoring processes and logs, and recommends hardware telemetry and consistency checks across layers to catch tampering.
Then comes 4.2, the sharpest sentence in the report: treat monitored SI model outputs as potentially containing exploits aimed at the monitor. The safety layer is made of the same material as the thing it watches, and reads the same inputs. Practice 3.4's recommendation to use multiple models, ideally from different families, follows: cross-family monitoring is not redundancy for its own sake, it is the only way to keep one failure mode from taking out both the agent and its observer.
Evidence, shutdown, and the recovery trap
The response practices are expansive about evidence: preserve model weights, checkpoints, timestamps, sandbox and network logs and the environments needed to reproduce a run (5.1–5.2), and keep tamper-resistant logs sufficient to reconstruct trajectories, tool calls and reasoning traces (5.3). Practice 5.5 allows SI models to assist an investigation, but requires key facts to be verified by humans and cross-checked with models outside the family that originated the incident.
Mitigation is direct: define shutdown policies in advance (6.1), shut down affected trajectories automatically on detection of a control failure (6.2), pause training or evaluation for similar agents while controls are re-examined (6.3), and hunt for persistence routes (6.5).
Practice 7 reads as if written by people who have run a training job: rebuild compromised environments from verified baselines (7.1), patch or report the vulnerabilities the agent exploited (7.2), validate that monitors, logging, allowlists and shutdown mechanisms still work before resuming (7.3), and replay the incident's trajectories against the new controls to prove they would have caught it (7.4).
Then 7.7, which is easy to skim and hard to satisfy: recovery must neither reinforce the patterns that led to the incident nor make future adverse activity more difficult to detect. The document's own example is training against explicit adverse chain-of-thought "in a way that reduces" the signal available to future monitors. The obvious fix — punishing the visible reasoning — can teach a model to stop showing its reasoning, and the monitors lose the evidence they were built to read.
What the document leaves open
The report's "Areas for Future Work" section is where the practical difficulty lives: training-safe recovery; better baselines of intended agent activity; synchronous monitoring that balances latency, performance and security; standardized severity scores; red-teaming for critical systems; escalation mechanisms for multi-agent settings; and agent identifiers, including publishing IP ranges, which could help defenders attribute traffic but "might also expose SI agent deployers to attack."
The gap between practice 3.1, which asks organizations to define the intended boundaries and scope of actions for each agent, and the future-work item on baselines is the whole problem in miniature. Detecting unexpected activity requires a specification of expected activity, and the document concedes the field does not yet have good methods for writing one. Every downstream control inherits that weakness.
What the document is, then, is a vocabulary and a channel. It is voluntary, marked TLP:CLEAR, sets no thresholds or deadlines, and asks — but does not require — organizations to report control incidents and near-misses. That is the posture SP 800-61r3 also takes: guidance that becomes practice through procurement, insurance and audit, not enforcement.
Read the ten practices by what they demand that is new. Eight extend controls a serious lab should already have. Two require engineering most labs do not: detection integrity — monitors the agents cannot reach, built from different model families, red-teamed before they are trusted — and training-safe recovery, where the repair can change the model's future behaviour. Both are testable claims, and both are where the next version will be judged.
Sources
NIST, "Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation," news release, October 16, 2026. nist.gov
NIST CAISSI, NSA SISC and CISA, Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, October 2026, version 1.0. PDF
NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management. csrc.nist.gov
NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0. nvlpubs.nist.gov
The White House, Winning the Race: America's AI Action Plan, 2025. whitehouse.gov