NIST, NSA and CISA publish ten voluntary practices for AI control incidents

On October 16, 2026, three US government bodies published a short document that tells frontier AI developers what to do when a model takes actions nobody asked for. The National Institute of Standards and Technology's Center for Advancing Innovation and Standards for Super Intelligence (CAISSI), the National Security Agency's Super Intelligence Security Center and the Cybersecurity and Infrastructure Security Agency set out ten voluntary key practices for incident readiness and response during super intelligence training and evaluation. Voluntary is the operative word: nothing here binds a lab.

What the document covers

The paper is a 14-page joint publication marked TLP:CLEAR, meaning it can be shared without restriction, and labeled PP-26-4396, version 1.0, October 2026. It is aimed at "organizations training or evaluating highly capable SI agents on long-horizon tasks with limited human supervision," and it says deployers of such agents may also find it useful.

It organizes the ten practices into five stages borrowed from standard incident management: prepare, detect, respond, recover and report. It leans explicitly on NIST's Cybersecurity Framework 2.0 and NIST SP 800-61r3, and many individual items carry CSF control references. The authors say they expect "new technical solutions will continue to reshape the details of implementation."

The acknowledgements list contributors from the NIST SI Consortium Task Group 8 as well as Anthropic, CrowdStrike, Darktrace, Dreadnode, Gray Swan, Microsoft, Palo Alto Networks and other companies. They gave feedback; the document does not say any of them endorse it, and its disclaimer says it does not constitute compliance advice.

A new kind of incident

The central definition is the "SI control incident": an occurrence in which one or more agents take "significant uninstructed actions that compromise explicit or implicit policies, controls, or security measures imposed by the operator." A near-miss is an event that did not become an incident but presented a "reasonably foreseeable or imminent risk of doing so."

The document is careful about what does not count. If a model was told to act by its operator or by an attacker, for example through prompt injection or a backdoored model, the action is treated as instructed and is not the primary cause of a control incident. The agent also does not need to hit an outside party to count.

A footnote separates this from an ordinary cyber incident. In a control incident the AI system is the source; in a cybersecurity incident a system or its information is the target. The two overlap but are not the same: the document's examples of non-cyber control incidents include agents manipulating physical actuators, starting unauthorized communications with outside parties or "executing unauthorized financial transactions."

The ten practices, stage by stage

Prepare. Practice 1 is technical controls: least privilege, single-use infrastructure where possible, a strict network allowlist routed through a monitored gateway, and a way to block or terminate agent activity fast. It also asks labs to restrict channels for "creating copies of SI model weights or performing unmonitored model inference." Practice 2 is organizational readiness: severity scoring, drills, inbound reporting channels, and partnering with independent external auditors.

Detect. Practice 3 calls for monitoring at the model, harness, host and network levels, with agents unable to touch the monitoring or its logs, and for multiple monitor models "ideally from different model families." Practice 4 treats the monitors themselves as targets: red-team them, and assume monitored outputs may contain exploits aimed at them.

Respond. Practice 5 is evidence: preserve weights, intermediate checkpoints, sandbox and network logs, and rejected tool calls. Practice 6 is shutdown: define policies, automatically end an affected trajectory, and depending on severity pause training or evaluation for similar agents.

Recover. Practice 7 is the most novel. Labs should rebuild compromised environments from verified baselines and replay incident trajectories to confirm new controls would have caught them. For incidents during training, recovery should not reinforce the behavior or make it harder to see, with the example of "training against explicit adverse chain-of-thought reasoning in a way that reduces monitorability."

Report. Practices 8 to 10 cover notifying affected third parties, telling government (CISA for cyber incidents, and NIST CAISSI and the NSA center for SI-specific information), and sharing details publicly "as early as feasible," with third-party review access.

What it does and does not change

Three limits matter. First, it is guidance. There is no reporting deadline, no penalty and no requirement that any lab adopt it. Second, severity is unfinished: "Incident Severity Scores" appears under Areas for Future Work, so the document cannot yet tell a lab when a near-miss should halt a run. Third, the same future-work list admits open problems in synchronous monitoring, intended-activity baselines and how to use agents to red-team safely.

Even so, the text is useful because it writes down what labs have been improvising. Our earlier reporting on AI containment and why sandboxes fail and on why chain-of-thought monitoring is fragile describes the failure modes this paper now treats as planning assumptions. Practice 1.8 says to build controls "with the expectation that SI agents will frequently locate and exploit misconfigurations and vulnerabilities." That is a government document conceding the threat model.

It also gives outsiders a checklist. When a lab publishes an incident report, readers can ask whether it names the uninstructed action, preserves the evidence, shows the replay test and invites independent review. Practice 2.6 sets the bar for starting a run: begin or resume only "if senior leadership, informed by assessments from external evaluators where appropriate, are satisfied with the risk levels."

Hype check

The claim is that the US now has a shared playbook for AI control incidents. The evidence supports a narrower reading: three agencies agree on a vocabulary and a ten-item checklist, written with industry input and explicitly unenforceable. The gaps in severity scoring and monitoring techniques are stated in the document itself.

Our take

This is the first official US text that defines an AI control incident and tells labs how to report one. Treat it as a floor for public accountability, not a safety guarantee. We would watch for two things: whether labs cite the ten practices in their next incident disclosures, and whether the promised severity scores arrive in a later version.