The UK's National Cyber Security Centre published its agentic AI guidance on August 20, 2026, and it reads less like a policy statement and more like a settings list: four network isolation tiers, three human oversight modes, and a recommendation to fold agent activity into the same 24/7 monitoring a security team already runs. None of it is law. The NCSC describes the post itself as interim practical advice, not a requirement, and recommendation language runs through every control on the list. What makes it worth reading closely is that the recommendations are specific enough to turn into an actual configuration, not just a principle to nod along with.
What the NCSC actually told teams to do
The guidance comes down to six controls. Agents get only the permissions the task in front of them needs, and credentials with the shortest lifetime that still lets the job finish. Network access sits on a four-tier scale, worst to best: unrestricted access, access limited to an allowlist of approved domains, access limited to just the model's own API, and no external network access at all, with the model hosted locally. Every agent gets an oversight mode: human-in-the-loop, where a person approves actions before they happen; human-on-the-loop, where a person monitors and can step in; human-out-of-the-loop, where the agent acts without review. Chain-of-thought traces and logs from the sandbox the agent runs in get captured and kept immutable, so an investigator can trust the record afterward. Agent activity gets treated as a form of user activity and routed into the same round-the-clock security monitoring and incident response a team already runs. And there's always a way to halt it: pull the plug on the agent immediately, including cutting its network access and interrupting its communications.
That's the whole list. The gap is what happens between reading it and actually turning any of it on.
How to configure agentic AI controls
1. Scope credentials to the task, not the agent
Give an agent a standing credential and it carries that access into every run it ever makes, whether the task needs it or not. Issue a scoped token per task instead, generated at the start of the run and set to expire in minutes or hours, not days. A coding agent fixing a typo doesn't need the same token as one deploying to production, even if both are technically "the same agent." A case study on what happened when an agent's credentials reached further than its task required shows the failure mode this prevents: a low-privileged bot's comment was enough to trigger a second workflow carrying a maintainer-level token, because nobody had mapped what that second workflow's credential could actually do.
2. Pick a network isolation tier and name it, per agent
Don't set one isolation policy for every agent your team runs. A coding agent that needs to pull packages and check documentation probably sits at tier two, a domain allowlist covering package registries and internal docs. An agent anywhere near financial data or customer records has a stronger case for tier three, API access to the model only, or tier four, no external network access and a locally hosted model. Write down which agent sits at which tier and why, because "we isolated it" means nothing without a number attached.
3. Assign an oversight mode per agent, not per team
Match the mode to what the agent can actually do if it's wrong. An agent that reads and summarizes can run on-the-loop, watched but not gated on every step. An agent that merges code, deletes records, or moves money belongs in-the-loop until it's earned otherwise. GitLab shipped a narrower version of this same split as a product default in its 19.4 release: read-only tool calls run without asking, write and delete calls stop for approval. It's a two-tier approximation of the same idea, proof that the framework holds up outside a government blog post. Unprompted initiation is the trait worth watching for: an agent that starts work without anyone prompting that specific run, the way Cursor's Projects coordinator does ahead of a PR merge, leans toward human-out-of-the-loop on the initiation side. But the merge itself commonly stays gated by whatever branch protection the team configures, which keeps a human able to intervene, closer to on-the-loop. Decide, agent by agent, whether that's the mode you want.
4. Log chain-of-thought and sandbox activity together, and make the logs immutable
Capturing an agent's reasoning trace is only useful if it sits alongside what the sandbox around it actually did, file writes, network calls, process launches. Store both in one place, not two systems a responder has to correlate under pressure. "Immutable" isn't a synonym for "kept longer." It means append-only storage or write-once retention, where the agent (or anything that compromises it) can't edit or delete the record of what it did. If your logging setup lets anyone, including the agent's own service account, rewrite history, it isn't immutable yet, whatever your retention policy says.
5. Route agent activity into the same 24/7 monitoring as user activity
This is the step most teams reading this can't do as written. The NCSC's framing assumes a security operations center running around the clock, watching agent activity the way it watches employee logins. A ten-person engineering team doesn't have that, and building one from scratch to satisfy a single control isn't a reasonable ask. Hold that thought; it's the subject of the next section.
6. Build and test a kill switch before you need it
A kill switch isn't a stop button in a chat interface. It's the ability to cut an agent's network access at the infrastructure level, revoke its credentials, and confirm it's actually stopped, not just that it stopped responding to a prompt. Build it as its own runbook: who has the authority to pull it, what commands they run, how long it takes. Then test it on a live agent in a non-production environment before you need it in a real one. A kill switch nobody has ever exercised is a plan, not a control.
The gap the NCSC guidance doesn't close
This part is HighCircl's own read, not the NCSC's. Step five, folding agent activity into 24/7 security monitoring, assumes a SOC and an incident-response function that most engineering teams don't have. The guidance doesn't offer a smaller version of that control for a team without dedicated security operations, and it doesn't need to; that's not what a national cyber agency's advisory is for. But it leaves a real gap for the reader most likely to be implementing this list.
A practical minimum, in our view: route agent logs into whatever on-call or alerting system already covers production incidents, rather than standing up a formal SOC to satisfy one line item. It isn't equivalent to round-the-clock security monitoring staffed by analysts trained to spot an agent behaving strangely. An on-call engineer paged for a production outage and an analyst watching for credential misuse are not doing the same job. But it beats the alternative most teams actually choose, which is logging agent activity somewhere nobody looks until after something has gone wrong.
FAQ
Is this guidance mandatory?
No. It's advisory guidance from the UK's National Cyber Security Centre, not law and not a certification requirement. Nothing about running agentic AI systems obliges a team to adopt any of these controls, and the NCSC doesn't frame it that way either.
What's the minimum first control to configure?
Credential scoping and the kill switch. Both can be built with tooling most teams already have, short-lived tokens and a documented shutdown procedure, without procuring anything new. The isolation-tier scale and the oversight-mode framework take longer, because they require deciding, agent by agent, how much autonomy and network reach each one actually needs.
Does this guidance name any specific incidents?
No. The NCSC references incidents involving AI models and agentic AI systems without naming or dating them, pointing instead to a separate statement. Don't let anyone tell you this guidance was written in response to one identifiable breach. It wasn't presented that way, and there's no source for treating it that way.
What if my team doesn't have a SOC?
Route agent logs into the on-call or alerting system already covering production incidents. It's not the 24/7 security operations monitoring the guidance describes, and it won't catch everything a trained analyst would. But it's the honest minimum version of the control, and it's better than the default most teams land on, which is logging agent activity somewhere nobody checks. This is our read on the gap, not something the NCSC guidance spells out itself.