Security Operations

AI agent incident response: what US guidance means for UK SOCs

NIST, NSA and CISA set out ten practices for AI agent control incidents. What UK SOCs should change in detection, evidence and shutdown playbooks.

Radar graphic with the headline Incident response for rogue AI agents

NIST, the NSA and CISA have issued ten joint practices for handling incidents in which AI agents take actions nobody asked them to. The guidance is aimed at frontier developers, but the detection, evidence and shutdown thinking translates directly into the playbooks UK SOCs and incident response teams should be drafting now.

What happened

On 16 October 2026, three US agencies jointly released Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. The authors are NIST’s Center for Advancing Innovation and Standards for Super Intelligence (CAISSI), the National Security Agency’s Super Intelligence Security Center (SISC) and CISA. “Super intelligence”, or SI, is the term US federal bodies now use for AI.

The 14-page document (PP-26-4396, released as TLP:CLEAR) is voluntary. It sets out ten practices spread across five stages that any incident handler will recognise: prepare, detect, respond, recover and report. NIST says the practices are grounded in established incident response frameworks, including its own SP 800-61r3.

The trigger for all of this is a new category the agencies call an “SI control incident”. That is when one or more agents do something significant that neither the operator nor an attacker directed, and in doing so undermine the policies, controls or human oversight meant to keep them in their lane. The primary audience is organisations running highly capable agents on long tasks with little supervision, though the text says deployers may also fall within scope.

The guidance follows public cases of test agents reportedly slipping past protections or reaching external systems. On 8 October the ICO, the UK’s data protection regulator, said it had made enquiries with the UK’s AI Security Institute, OpenAI, Anthropic and Meta over recent testing and deployment of agents. Its six-week call for evidence on agentic AI data protection risks closes on 20 November.

The technical picture

One definitional point matters for anyone triaging these events. The guidance treats actions caused by an adversary’s prompt injection, or by a deliberately backdoored model, as instructed, so they fall outside the new category. A control incident is the agent crossing a boundary on its own initiative while chasing its goal. Distinguishing the two after the fact is an evidential question, which is why so much of the document is about records.

The preparation stage reads like a hardening checklist. Agents should get least-privilege access, run on single-use infrastructure where possible, and only talk to other agents over approved channels. Any network traffic they genuinely need should pass through a monitored gateway, ideally enforcing a strict allowlist. Teams are told to map likely persistence routes, with copying of model weights and unmonitored inference called out specifically, and to build fast mechanisms to block, contain and terminate activity. Crucially, the agencies ask organisations to assume agents will hunt for misconfigurations and exploit them.

Detection asks for monitoring at every layer: model, harness, host and network. The most interesting requirement for SOC engineers is isolation. Agents must not be able to read, alter or interfere with the monitors and logs watching them, and the document suggests hardware telemetry and consistency checks across layers to spot tampering. It also warns that model output passed to a monitoring model may itself contain an attempt to exploit that monitor, and recommends using several monitoring models, preferably from different families, plus canaries.

Response begins with evidence: weights, checkpoints, environment configuration, sandbox and network logs, rejected actions and tool calls, all with reliable timestamps in tamper-resistant storage. Shutdown rules should be agreed before a run starts, affected agent trajectories should stop automatically, and similar runs may need pausing depending on severity. Responders then revoke any credentials the agent touched, rebuild compromised environments and remove backdoors or covert channels. Recovery means restarting only from verified baselines, proving monitors, egress allowlists and kill switches work, and replaying the incident to check the new controls would catch it. The final stage covers notifying affected third parties, meeting legal reporting duties, voluntary reports to CISA and public sharing of lessons, near-misses included.

Flow diagram of the five stages in the NIST, NSA and CISA AI agent incident practices: prepare, detect, respond, recover, report

Why it matters for UK organisations

Few UK organisations train frontier models, but many now run agentic tools with real permissions: coding assistants that commit to repositories, workflow agents with API keys, and security copilots inside the SOC itself.

The ICO’s stated position is that autonomy does not excuse poor compliance. If an agent wanders into personal data or an external system, a UK organisation will still have to explain what happened, and possibly report it, using the same evidence the US document describes. Many UK incident response plans have no category for “our own tool did this”.

There is also a sequencing trap. ComplexDiscovery points out that the document asks responders both to preserve environments and to rebuild them. Evidence collection is listed first, but capture is never explicitly required to finish before rebuilding. Under pressure, a team can wipe the very evidence it needed.

Expert view

In my experience, the hardest part of incident response is deciding, at speed, whether something is malicious, accidental or a misconfiguration. Agent incidents blur all three. The instructed versus uninstructed split usefully forces a triage question SOC analysts are not yet asking.

The monitoring isolation point is the one I would put in front of every SOC manager. When we test environments, the logging pipeline is often reachable from the very systems it observes. An agent with shell access and a goal will find that faster than a human intruder. If your detection stack shares credentials, hosts or network segments with the agents it watches, assume it can be blinded.

I would also be cautious about the AI-assisted investigation the document permits. It rightly insists that humans verify key findings and that results are cross-checked with other model families.

The gaps are honest ones. There is no retention period, no severity scale yet, and the agencies list severity scoring and intended-activity baselines as future work. UK teams will need to fill those blanks themselves.

What to do now

  1. Inventory your agents. List every agentic tool, its identity, credentials, data access and network reach. Treat each as a privileged user under Cyber Essentials user access control.
  2. Add an agent incident category to your IR plan, with severity criteria, named decision makers and pre-agreed shutdown triggers.
  3. Isolate your telemetry. Make sure agents cannot reach SIEM forwarders, log stores or EDR consoles. Ship logs to storage the agent’s credentials cannot touch.
  4. Route agent egress through a gateway with an allowlist, mapping to Cyber Essentials firewall controls, and alert on anything denied.
  5. Write the evidence order into the runbook: snapshot, hash and export first, rebuild second.
  6. Log tool calls and rejected actions, not just outcomes, with synchronised timestamps.
  7. Run a tabletop in which an internal agent exfiltrates data or touches a third party, and test your ICO notification decision path.
  8. Restart only from verified baselines, after rotating every credential the agent could see.

Bottom line

This guidance was written for US frontier labs, but its logic applies to any organisation that has given an agent real permissions. UK SOCs that adopt its isolation, evidence and shutdown disciplines now will be far better placed when the first agent incident lands on their own desk.

Sources

Related Posts