Two pieces of NCSC advice on deploying agentic AI safely have appeared this year, and between them they amount to a quietly radical point, which we would put like this: treat an agent less like software and more like an untrusted contractor with excellent typing speed. Here is what the advice says, and how to use it.
Two documents, one direction
The first, Thinking carefully before adopting agentic AI (opens in a new tab), appeared on 15 May 2026. It summarises ‘Careful adoption of agentic AI services’, joint guidance the NCSC co-authored with international partners, and it is aimed squarely at the decision to deploy at all. Its most quotable line is also its most useful test: “If you cannot understand, monitor or contain an agent’s actions, it is not ready for deployment”.
The second, Managing the cyber risk of agentic AI (opens in a new tab), published on 20 August 2026 by Toby W, a Principal Security Architect at the NCSC, is the engineering follow-through. It is explicitly interim. The NCSC says it is working with partners on formal guidance “which will build upon, and ultimately supersede, this blog.” That is worth knowing before you build a compliance programme on its exact wording, but we would be surprised if the substance softened.
The core premise
The August advice asks designers to begin with threat modelling, and it contains a sentence that should be printed on the wall of every team shipping an agent: “Remember that an AI agent is not human. It does not have common sense or human traits, and may interpret instructions and goals in literal or unexpected ways.”
It follows that the model’s own guardrails cannot be the whole defence. The NCSC says built-in safety controls may be bypassed and “should not be treated as holistic”. On prompts specifically, it suggests stating clearly what the agent should and should not do, repeating critical constraints during long tasks, and then adds the important caveat: “do not rely on prompting alone.” Prompts are guidance to the agent. Controls are things the agent cannot talk its way past.
Choosing your oversight model
The advice sets out three oversight modes: human-in-the-loop, where people approve actions before they happen; human-on-the-loop, where people monitor and can intervene; and human-out-of-the-loop, where the agent acts without review. Where unintended activity would have significant consequences, it recommends named owners, real-time alerting and the ability to stop the agent. It also warns that ‘judge’ models used to supervise other agents have limitations of their own and should be evaluated independently. Asking one model to mark another’s homework is still asking a model.
The two maturity models
The most practical part of the August advice is a pair of four-level maturity models, one for network access and one for compute isolation. They make a useful common vocabulary for design reviews.
| Level | Network access | Compute isolation |
|---|---|---|
| 1 (lowest) | Unrestricted network access | None: the agent runs on, or can reach, the host alongside other workloads and data |
| 2 | Allowlist of approved domains | Same host, constrained by kernel primitives such as process separation and properly configured OCI containers |
| 3 | Only the model’s API | Same host, isolated with virtualisation |
| 4 (highest) | No external network; model hosted locally inside the sandbox | Dedicated hardware separate from other workloads |
The default position is deny-all, with allowlists for what is genuinely needed. Where an allowlist is too coarse, the NCSC suggests protocol- or service-aware proxies that permit connections only by exception. It also notes something that should focus minds: agents may be able to “discover and exploit configuration issues, or potentially even vulnerabilities” in technical controls, leading to sandbox escape. Its answer is several layers of isolation and regular validation of the configuration.
The advice names OpenClaw and Hermes Agent as examples of autonomous tools built to touch large numbers of systems. That is not a criticism of either product so much as a reminder that breadth of access is breadth of blast radius.
Credentials, logs and the off switch
Every agent should have its own identity, in a class that distinguishes it from humans and ordinary systems, with only the permissions it needs and credentials that expire quickly. For some uses the NCSC suggests a proxy that injects credentials into requests, so the agent never holds the secret and cannot use it against an endpoint it was not meant to find.
On observability, the advice asks for chain-of-thought traces and transcripts alongside sandbox logs, protected from tampering and immutable where possible. It goes on to say agent activity “should be treated as a form of user activity” and included in 24/7 security monitoring and incident response. It sensibly suggests running early experiments in office hours, when there are more people about to notice.
Two final points are easy to overlook. Make your agent’s traffic attributable, with reverse DNS on its source addresses and identifying HTTP headers, so the organisation on the receiving end knows whom to call. And keep the ability to “pull the plug”, which the NCSC defines broadly: not just stopping the process, but cutting network access and the link between agents and the inference service.
How to use it
- Score your existing agents on both maturity models. Anything at network level 1 and compute level 1 with production credentials deserves attention before the next sprint, not after.
- Write down the oversight mode for each agent and who owns it. The May advice insists that humans remain accountable for the decision to deploy, the access granted and the consequences.
- Route agent logs to the SOC as you would a privileged user’s, and test that someone can actually stop the agent at 3am.
- Read it alongside the standards. Both NCSC pieces point to ETSI EN 304 223 (opens in a new tab) for baseline requirements. For attacker behaviour, MITRE’s ATLAS (opens in a new tab) and the OWASP Top 10 for Agentic Applications (opens in a new tab) fill in the other side of the board.
None of this is exotic. Least privilege, isolation, logging and an off switch are the same disciplines we apply to contractors and service accounts. The novelty is that this contractor reads everything it is given and may act on any of it.
For a threat model of agentic systems, see OWASP agentic Top 10 meets MITRE ATLAS; for the UK legislation, the Cyber Security and Resilience Bill. More is in Regulation & Standards.
Sources
- NCSC: Managing the cyber risk of agentic AI (PDF, 20 August 2026) (opens in a new tab)
- NCSC: Thinking carefully before adopting agentic AI (PDF, 15 May 2026) (opens in a new tab)
- ETSI EN 304 223: Securing Artificial Intelligence, baseline cyber security requirements for AI models and systems (opens in a new tab)
- MITRE ATLAS (opens in a new tab)
- OWASP Top 10 for Agentic Applications for 2026 (opens in a new tab)
Follow Cyber-Threat.net RSSFeedly (opens in a new tab)X (opens in a new tab)Bluesky (opens in a new tab)LinkedIn (opens in a new tab)