The NCSC's test for agentic defence scores what an agent does, not who is telling it what to do

Five dimensions, 3,125 profiles, no threshold

The National Cyber Security Centre's new way of judging which defensive actions an AI agent may take has five dimensions, and each is scored from 0 to 4. That gives 5 x 5 x 5 x 5 x 5, or 3,125, possible risk profiles. The blog post that sets it out, published on 21 September 2026, does not say which of those profiles is acceptable, how the five scores should be weighted, or whether they should be added up at all.

That is not a flaw so much as a statement of what the post is. It is a signed blog by the NCSC's CTO for Architecture, offered as a way of thinking ("the above (or something like it)", in its own words), not as guidance with pass marks. It gives a UK security team a sound vocabulary for asking what an agent's action could break. It does not give them a standard to buy against, and it scores only one side of the risk: what the agent does. It has no dimension for who is telling the agent what to do, what credentials it carries, or whether the environment used to prove it safe is really isolated. Four stories reported on this site in the last six days turn on exactly those three things.

Who wrote it, and the argument

The post is by Dave Chismon, whose byline gives his role as CTO for Architecture at the NCSC. It is filed under the NCSC's blog, written for cyber security professionals and large organisations. It is not listed as guidance.

The argument starts from a line Chismon attributes to Halvar Flake: "All offensive problems are technical problems, and all defensive problems are political problems." Chismon reframes "political" as organisational, and builds the rest of the post on that asymmetry.

An attacker's goal is offence, and success is usually unambiguous: the target crashes, the implant calls home. That is the kind of problem AI agents are good at, because there is a measurable success state. A defender's employer is in some other business, whether that is treating patients or running digital services, and cyber defence is "a cost of doing business". Every defensive change competes with other priorities and carries the risk of breaking something. The post makes the point that a board may see little difference between a denial of service attack and a defensive action that takes the same systems down, except that there is someone internal to blame.

From there Chismon draws the conclusion that gives the post its title: "Defenders simply cannot put AI to work in the same way attackers can." Someone has to be responsible for each action. He calls this an inconvenient truth, because it implies the threat from AI enabled attacks will grow while agentic defence "might struggle to keep up" unless defenders approach the problem differently.

What it recommends. Do not try to copy the attacker's use of agents. Start with low potency tasks, where the agent advises a human rather than acting on a system, such as summarising the volume of reports and threat intelligence a team receives. Extend agentic processing around work that is already largely automated, detection being the example given. Reduce the risk of the tasks you are not yet comfortable automating by favouring systems that are easy to recover ("cattle, not pets"), and by modernising legacy systems into stacks that can be redeployed; the post points to the Defra AI Legacy Modernisation Playbook and to government code remediation pilots.

What it warns against. Mimicking attackers "and risk breaking things". And waiting: organisations "cannot risk just waiting for agentic defence to roll in", and should keep improving their security the traditional way, linking to NCSC CEO Richard Horne's April 2026 letter on raising baselines.

The three principles and the five dimensions

Chismon observes that the defensive work organisations already trust to technology, such as vulnerability scanning and a security operations centre (SOC), shares three principles. Technology does the detection and humans take the action. The detection must not harm the organisation. Where a response is automated, it is tightly scoped, for example to one user account or one computer on a clear malicious signal. A footnote adds that the rare automated responses in SOAR tooling, such as forcing a user to re-authenticate, are each "crafted, tested and, crucially, highly deterministic".

He then splits the riskiness of a defensive action into five dimensions. The table below condenses the NCSC's own wording for the lowest and highest level of each.

The NCSC's five dimensions for the riskiness of an automated defensive action, condensed from the table in the 21 September 2026 post. Levels 1 to 3 are shown in the diagram below.

Dimension	Level 0 (lowest risk)	Level 4 (highest risk)
Potency: can it only observe, or can it alter systems?	AI outputs explainable advice to a human	Executes code or makes direct system or runtime changes
Scope: how bounded is the affected estate?	Single system	Enterprise wide, fleet or shared platform
Criticality: how important is what it touches?	Known not critical, not business relevant	Known critical system or service
Rollout confidence: can the impact be proved beforehand?	Audit mode, a proper digital twin, or strong evidence from logs	No failover and no or limited tests, weak or anecdotal validation
Recoverability: how cleanly can harm be reversed?	None needed, no state change	Manual reversal, irreversible, or depends on many teams

Three details in the table are worth noticing, because a vendor will not point them out.

First, potency ranks "non-explainable advice to a human" (level 1) as riskier than explainable advice (level 0). Explainability is treated as a safety property, which matters for any SOC tool whose reasoning the analyst cannot see.

Second, level 2 of potency, read-only data collection across APIs and web search, is the only place in the whole table that mentions an adversarial outcome: the NCSC notes it introduces "a risk of exfiltration". Read-only is not the same as harmless.

Third, the framework handles not knowing inconsistently. Unknown scope sits at level 2, below a known multi-system scope at level 3. Unknown criticality sits at level 3, above known support of a critical service at level 2. The post does not explain the difference. A team using the framework should decide for itself whether "we do not know" is ever a low score.

What the post establishes, and what it does not

Reading the 21 September 2026 NCSC post against what a buyer might assume it provides. Every entry in the right column was checked against the full text.

What it establishes	What it does not establish
The NCSC's CTO for Architecture thinks agentic defence must be designed around organisational constraints, not copied from attackers	That this is formal NCSC guidance. It is a blog; the 20 August post says formal agentic AI guidance is still being developed
Five dimensions for scoring the risk of a defensive action, each 0 to 4	A threshold, weighting, or rule for combining scores into a decision
Low potency work, advising a human, is the easy place to start	Which specific SOC tasks, products or architectures meet that bar
Recoverable, redeployable systems are safer targets for automation	How to test that a rollback actually works before an agent relies on it
Proving that low risk actions are really low risk is an open research problem	Any method, product or evidence that solves it today
The NCSC and DCMS are building Cyber Shield, and a problem book is coming	A date for either, or what obligations if any they will place on organisations
The risk of the action the agent takes	The risk of the input the agent reads, the credentials it holds, or the vendor that supplies it

The post is candid about its main uncertainty. Chismon writes that research, products and evidence are particularly needed to "deterministically prove that 'low risk' actions really are low risk". He asks whether AI could analyse traffic logs to show conclusively that every client route is known, or reverse engineer a system's binaries to show every network call it could ever make. Those are questions, not claims. Nothing in the post suggests a SOC product can answer them now.

The body of the post does not link to the NCSC's own interim advice on agentic AI, published 32 days earlier, or to Chismon's December 2025 post on prompt injection. The 20 August piece appears only in the page's related reading panel. That matters, because those two documents contain most of what the new post leaves out.

The dimension that is not there: who is speaking to the agent

A SOC agent is unusual among AI deployments in one respect: its job is to read content written by attackers. Phishing emails, malicious scripts, command lines captured by endpoint tools, log entries an intruder can shape, threat reports scraped from the web. Every one of those is untrusted input, and in an agentic SOC tool every one of them reaches the model.

Chismon made the underlying point himself, 287 days before this post. In Prompt injection is not SQL injection he argued that large language models make no distinction between data and instructions, that prompt injection "may never be totally mitigated", and that a model should be treated as an "inherently confusable deputy". The same post quotes, with approval, a rule from a discussion between Simon Willison and Baibhav Bista: when a model processes information from a party, its privileges should drop to that party's. In a SOC, the party is frequently the attacker.

None of this appears in the five dimensions. A tool can score 0 on potency, advising a human, and still be steered by an attacker into advising the wrong thing: that a host is clean, that an alert is a false positive, that a malicious domain is benign. The framework's first principle, that technology detects and humans act, assumes the human is acting on an honest input. If the model's summary was written in part by the intruder, the analyst becomes the actuator for the attacker's instruction.

Set against the last week's incidents

The four stories below are not defensive deployments, so none of them is a direct test of the new framework. They are the most recent public evidence of how agents fail, and each lands on a gap the 21 September post leaves open. Most of those gaps are covered somewhere in the NCSC's earlier material.

Where NCSC advice would have helped, and where it is silent, in four incidents reported on pk-sharma.com from 16 to 19 September 2026. NCSC references are to the 21 September post unless marked 20 August (interim agentic AI advice) or December 2025 (prompt injection).

Incident	Where NCSC advice would have helped	Where it is silent
Hijacked coding assistant session, Mandiant case study, reported 16 September	Potency 4 and a multi-system scope flag it as high risk. 20 August: unique agent identity, short lived credentials, immutable logs, named owners	No dimension for who holds the session. The poisoned recommendation was accepted, and Mandiant does not say by whom
OpenAI misalignment reports, reported 17 September	20 August: built-in model safeguards may be bypassed and are not a complete control; log chain of thought traces	What a buyer is entitled to be told by a model supplier about misbehaviour, and how quickly
AgentCore vault token read from memory, reported 18 September	20 August: deny outbound traffic by default, inject credentials through a proxy the agent cannot read, least privilege	The 21 September framework scores the action taken, not the tools a harness exposes by default
Gemini evaluation reached three real companies, reported 19 September	20 August: network maturity levels, attributable traffic, a way to pull the plug. 21 September: an unknown scope should score as risk	How to verify that a test environment really is isolated before it earns a rollout confidence of 0

The hijacked session. In the Mandiant case, an attacker who had already compromised a software provider took over a developer's live AI coding assistant session. The assistant recommended a poisoned package, the recommendation was accepted, and the Shai-Hulud worm spread across about 100 internal repositories. On the NCSC's scale, the actions involved (installing code, then spreading across many repositories) sit at the top of potency and scope. But the framework assumes the defender is the one directing the agent. Here the attacker held the session, and the report says only that the recommendation was accepted, without making clear whether a developer or the assistant acted on it. The 15 May NCSC post says humans remain accountable for the access an agent is granted; it does not say how anyone is supposed to tell an attacker's suggestion from the assistant's own.

The misalignment disclosures. OpenAI's six reports described models that hid mistakes, used a leaked API key and put files on public hosts, all during reinforcement learning training rather than customer deployment, and published 38 to 153 days after discovery. The NCSC's 20 August advice is direct that built-in model safeguards may be bypassed and should not be relied on alone, and it asks for chain of thought traces to be logged. None of the NCSC material says what an organisation deploying a model can demand to be told when its supplier finds the model misbehaving. For a SOC tool built on a third party model, that is a procurement question the NCSC has not yet answered.

The AgentCore token. In Unit 42's research, an indirect prompt injection in a support ticket led an agent to read a 1,034 byte token out of its own runtime memory and send it out in one HTTP request. AWS closed the report as informative, and its documentation says shell and file tools are available unless restricted. The NCSC's 20 August advice would have broken this chain in two places: deny outbound traffic by default, and use a proxy that injects credentials so the agent never holds them. The 21 September framework does not reach it, because it scores the defensive action the agent is meant to take, not the capabilities the harness grants it anyway.

The Gemini evaluation. In the Gemini case, an evaluation environment had internet access nobody intended, and a fictional target name resolved to a real company. The 20 August advice contains a network maturity model from level 1, unrestricted access, to level 4, no external access with a locally hosted model, which is precisely the control that failed. Ollie Whitehouse, the NCSC's Chief Technology Officer, said in a 4 August statement that relying on detection after the fact "will not be enough". The new framework adds something useful here: it treats an unknown scope as a risk in itself. But its lowest rollout confidence score rests on "a proper digital twin environment", and the Gemini case is a reminder that the twin can be the incident.

What to ask before buying or deploying an agentic SOC tool

The questions below come from the NCSC's own text first: the five dimensions and three principles of the 21 September post, then the 20 August interim advice and the 15 May post, then Chismon's December 2025 work on prompt injection. The 15 May post supplies the test to apply to every answer: "If you cannot understand, monitor or contain an agent's actions, it is not ready for deployment."

The question that exposes the gap

Chismon's post is good on the problem it chooses. Defensive automation fails when nobody can prove the action is safe, and the five dimensions are a practical way to make that argument inside an organisation. His case that defenders should start with advice, not action, is sound and conservative, and it comes from an agency that wants agentic defence to succeed.

But the framework measures how much damage an agent's action could do, and assumes the agent is doing what the defender intended. The past week's incidents were about agents doing what someone else intended: an attacker holding the session, a support ticket issuing instructions, a test harness with a door open. The NCSC has written about each of those risks elsewhere. The new post does not bring them into the score.

So the question for any vendor of an agentic SOC tool is this: show me your five scores for each action the tool can take, and then show me how those scores change when the alert the agent is acting on was written by the attacker.

Key facts