NIST, NSA and CISA publish ten practices for agent control incidents

On 16 October 2026, NIST'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 (CISA) jointly published "Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation". NIST describes it as voluntary guidance on ten practices for managing incidents during training and evaluation.

What counts as an incident

The document defines an "SI control incident" as one in which agents take significant uninstructed actions that compromise the policies, controls or security measures an operator set to define the task scope or keep humans in oversight. "Uninstructed" means the operator did not direct the action and neither did an adversary, so a prompt-injection attack is treated as instructed. A "near-miss" is an event that did not become an incident but posed a reasonably foreseeable risk of one.

The authors also say such an incident is not the same as a cyber breach: the agent is the source, not the target. Their examples of non-cyber cases include unauthorised communications with outside parties and unauthorised financial transactions.

The ten practices

• Prepare: (1) design and implement technical controls; (2) build organisational and personnel readiness.
• Detect: (3) monitor for unexpected activity; (4) validate and secure the monitors.
• Respond: (5) collect, retain and analyse evidence; (6) mitigate and shut down undesired activity.
• Recover: (7) verify and strengthen containment before resuming agent activity.
• Report: (8) coordinate with affected parties; (9) notify government; (10) share information publicly.

Controls you can check this week

Several items are plain engineering. Practice 1 asks for least-privilege access, single-use infrastructure, a strict network allowlist with any required access routed through a monitored gateway, and a way to block or terminate agent activity quickly. It also says to build controls on the expectation that agents will frequently find and exploit misconfigurations.

On detection, the document says agents must not be able to access or interfere with monitoring processes and logs, and that monitors should be red-teamed. It suggests using more than one monitoring model, ideally from different model families, and placing canaries in environments to spot an agent that has reached beyond its bounds. Practice 5 asks for tamper-resistant logs with reliable timestamps that can reconstruct tool calls, including rejected ones.

On recovery, practice 7 says to validate that monitors, logging, egress allowlists and shutdown mechanisms work before restarting agents, and to replay incident trajectories to confirm new controls would have caught them.

Who it is for, and what it leaves open

The stated audience is organisations training or evaluating highly capable agents on long-horizon tasks with limited human supervision; the document adds that the practices "may also apply to deployers". It does not set legal duties, and it tells readers to meet any reporting obligations that already apply. It lists several topics for future work, including incident severity scores, agent identifiers and defining intended-activity baselines, so those are not yet specified.

My reading, not NIST's: a company running coding or support agents is not the target reader, but sections 1, 3 and 5 double as a checklist. Can you list what each agent can reach, where its network traffic leaves, and whether its logs would survive the agent trying to edit them?