In October 2026, NIST CAISSI, NSA SISC, and CISA published Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation (PP-26-4396). By the end of this article you will know what it covers, where its scope ends, and which parts you can adopt as written.
The guidance is serious, agent-aware work written for frontier labs. Its definition of an incident leaves out prompt injection, a core attack path for any agent that reads untrusted content. If you deploy agents rather than train them, treat it as a floor and plan for what sits outside it.
This is Part 1 of two. Part 2 lays out an incident response model built for the rest.
At a glance
- The federal guidance sets ten voluntary practices for incident readiness and response in superintelligence training and evaluation.
- It is written for frontier labs, and its “SI control incident” definition excludes adversarially instructed events, including prompt injection.
- Deployers can adopt several agent-specific practices as written, but must close six production gaps, most of them about authority.
| Key fact | Detail |
|---|---|
| Document | Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, PP-26-4396 v1.0 |
| Publishers | NIST CAISSI, NSA SISC, CISA |
| Published | October 2026 |
| Contents | Ten voluntary practices across Prepare, Detect, Respond, Recover, Report; nine topics left as future work |
| Primary audience | Organizations that train or evaluate highly capable agents; the document says the practices may also apply to deployers |
| Scope limit | An “SI control incident” is uninstructed agent action; prompt injection and backdoored models count as instructed and sit outside the core definition |
What did NIST, NSA, and CISA publish?
They published ten voluntary practices for organizations that train or evaluate highly capable agents on long-horizon tasks with limited human supervision. The document says the practices may also apply to deployers. It is version 1.0, and it lists nine topics as future work.
The ten practices sit under five headings:
| Phase | Practices |
|---|---|
| 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 |
| Respond | 5. Collect, retain, and analyze 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 |
The nine future-work items mark where the guidance stops short: training-safe recovery, intended activity baselines, synchronous monitoring, incident severity scores, AI-enabled investigations, structured risk assessments, red-teaming for critical systems, additional escalation mechanisms, and agent identifiers.
What does the guidance get right?
It treats the agent as a system. Its definition of an agent covers scaffolding, tools, subagents, and orchestration, and practice 3.2 asks for monitoring at the model, harness, host, network, and multi-agent layers. A checklist written for endpoints would stop at the host.
Six more provisions carry AI-specific weight:
- Persistence and replication (1.4, 1.5). Map and restrict routes to persistence, including copying model weights, and force egress through a monitored gateway.
- Monitors as targets (3.3, 4.2). Keep agents away from monitoring processes and logs, and treat monitored output as a possible exploit against the monitor itself.
- Evidence beyond logs (5.1-5.3). Preserve weights, environments, configurations, rejected actions, and tool calls, so the event can be reproduced.
- Broad containment (6.3-6.5). Pause similar runs, revoke credentials, rebuild compromised environments, and remove persistence routes.
- Replay before restart (7.4). Strengthen controls, then replay the incident trajectory to prove they hold.
- Training-safe recovery (7.7). Recovery that retrains on the failure can teach the agent to hide the behavior instead of dropping it. The guidance warns against exactly that.
The last item has no counterpart in conventional incident response, because retraining can make the next occurrence of a behavior harder to observe.
What counts as an SI control incident?
SI control incident (definition): an 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.
The federal definition, verbatim — PP-26-4396, p. 3. Footnote 1 is the carve-out that matters: prompt injection and backdoored models count as instructed, so they fall outside it.
“Uninstructed” means the agent was not directed to take the action by its operator or any adversarial source. A footnote makes the consequence explicit. Prompt injection and intentionally backdoored models count as instructed, so they are not the primary cause of an SI control incident.
For research on whether frontier agents act against their operators unprompted, that boundary is sound. Run three cases through it and the gap for deployers shows up:
| Case | Inside the federal definition? |
|---|---|
| An agent bypasses a restriction on its own to finish a task | Yes. This is the core case. |
| A retrieved document injects instructions that trigger an unauthorized funds transfer | No. Adversarially instructed. |
| A manager approves a harmful action after reading a misleading AI-generated summary | Not addressed. |
The second and third cases are routine exposure for a deployer, whose agents read untrusted content and whose staff approve AI-drafted actions. The responder facing case two also has a timing problem.
At the moment of detection, nobody knows whether the cause was injection, emergent behavior, poisoned memory, or operator error. A program that classifies by cause first is still deciding while the transfer settles.
Where does it stop for organizations deploying agents?
Six gaps open up when a deployer adopts the guidance as its whole incident program. Some are deliberate research-scope choices. They still leave a production team without an answer at the moment it needs one.
Stopping the process ends none of these. Containment has to target authority and effects, not the agent.
| Federal provision | What happens in production |
|---|---|
| Task scope and rules defined in agent instructions (1.3) | The boundary holds only while the model complies. An injected instruction rewrites it. |
| Shutdown and credential revocation as the end of containment (6.1-6.4) | Queued jobs, scheduled retries, descendant agents, poisoned memory, and sent email keep producing effects after the process dies. |
| AI tools assist investigation, checked by humans and by models from other families (5.5) | Correlated models can agree on a wrong story, and a recorded reasoning trace gets read as the cause. |
| Human review and leadership sign-off (2.6, 5.5) | The guidance does not test whether the approver was rushed, overloaded, or steered by the system under review. |
| Severity scores, activity baselines, synchronous monitoring, and agent identifiers left to future work | Responders reach the first minute of an incident without thresholds, owners, or a reliable identity for the agent. |
| Containment validated before restart (7.3-7.5) | Full authority returns in one step, and the residual-risk decision carries no expiry date. |
The common thread is authority. The guidance asks what the agent did. A deployer also has to answer what the agent was permitted to do, who granted it, how far that permission spread, and whether the humans in the loop could still stop it.
The working split: adopt what the guidance says, supplement the authority layer it omits, and test both before an incident does it for you.
What should a security leader do with it now?
Use it three ways.
- Adopt the agent-specific practices as written. Network and persistence restrictions (1.4, 1.5), monitor isolation (3.3, 4.2), the evidence list (5.1-5.3), trajectory replay (7.4), and training-safe recovery (7.7) all transfer directly to a deployer’s environment.
- Use it in vendor due diligence. Ask each frontier model provider you depend on which of the ten practices they run, who audits them (2.4), and how they would notify you under practice 8. Their answers tell you how much of your own response depends on someone else’s readiness.
- Write down your interim answers to the future-work list. You need a severity threshold, an owner for each agent, and a kill path you have tested before the first incident. Mark them as local defaults and revisit them when standard methods mature.
Then close the gaps in the table above with controls that sit outside the model: enforced boundaries, containment that tracks effects past process death, evidence that does not rely on the agent’s account, and tests of the human approval path.
What to Do Next
- Adopt the transferable practices (1.4, 1.5, 3.3, 4.2, 5.1-5.3, 7.4, 7.7) into your own incident program as written.
- Put the ten practices into your next frontier-model vendor review, including who audits them and how they notify you.
- Write interim local answers for severity thresholds, per-agent owners, and a tested kill path before your first incident, not during it.
What comes next?
Part 2 walks through CSI’s agentic AI incident response doctrine (CSI-DOC-IR-001). It keeps the federal practices as one reference view and builds the rest on AI SAFE² for the machine and the Cognitive Sovereignty Framework for the humans governing it.
Start your free AI governance assessment to see where your own agents stand.
Sources
- CISA, Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation (resource page)
- NIST CAISSI, NSA SISC, CISA, Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, PP-26-4396 v1.0, October 2026 (defense.gov copy)
- Cyber Strategy Institute, AI SAFE² Framework v3.1
- Cyber Strategy Institute, Cognitive Sovereignty Framework v2.1