Is the NCSC risk framework an official standard?

No. The September 21, 2026 NCSC blog, written by Dave Chismon, presents it as a proposal for defensive actions ("we can propose a framework for estimating the riskiness of a defensive action"), and the August 2026 agentic AI blog says it is interim advice that formal guidance will build on and ultimately supersede. Treat both as a starting rubric to adapt, not a compliance baseline.

Where should a team start if it already runs agents with broad access?

The four steps in this answer are all measures the NCSC's August blog describes; picking them as a starting set, and their order, is our assessment. Give each agent its own identity, shorten credential lifetimes, deny outbound traffic by default where possible and log the agent's transcripts alongside sandbox telemetry. We expect these to reduce blast radius without rebuilding the deployment, and to make later tier upgrades measurable.

Does a model's built-in safety training count as a control?

Not on its own. The NCSC says model-level safeguards can be bypassed, may not suit higher-risk environments and should not be treated as holistic. It recommends additional safeguards such as classifiers or deterministic provers for deployments where failure would exceed your tolerance, plus observability and response procedures regardless.

NCSC Agentic AI Advice: Risk-Score…

Two recent NCSC blogs give defenders concrete material for agentic AI: a rubric for scoring how risky an automated defensive action is, and tiered maturity models for the network and compute isolation of the sandbox an agent runs in. Our framing is that, read together, they can support a go or no-go decision per workflow. The NCSC does not make that link itself, neither blog is formal guidance, and we mark where our reading goes beyond the text.

Two documents, one workflow

The first is the NCSC blog “Managing the cyber risk of agentic AI”, published August 20, 2026 (the NCSC’s October 20 research problem book blog lists it with the same date). It states that formal guidance is in development and that the blog is interim advice based on NCSC research. The second is “One does not simply defend agentically” by Dave Chismon, the NCSC’s CTO for Architecture, published September 21, 2026. It is a personal-voice blog. It argues that defensive problems are mostly organisational rather than technical and often lack a clear success state, so defenders cannot use agents the way attackers do, and it proposes a way to estimate how risky a defensive action is.

No evidence found as of October 30, 2026 of either blog being cited in our published articles (we searched our blog content for the blog titles and URLs). We opened both pages directly on October 30, 2026; we did not review the CETAS work the second blog cites.

Step 1: score the action

The September blog proposes rating a defensive action on five dimensions, each from 0 to 4, and its examples are patching, SOC and firewall changes. Applying the same rubric to any agent workflow is our extension. The wording below is condensed from the NCSC’s table.

Potency: 0 means the AI supplies explainable advice to a human; 2 means it collects data autonomously with read-only privileges, which the NCSC flags as an exfiltration risk; 3 means it changes state through APIs; 4 means it executes code or makes direct system or runtime changes. Level 1 is non-explainable advice to a human.
Scope: 0 is a single system, 2 an unknown scope, 4 enterprise-wide, fleet or shared platform.
Criticality: 0 is known not critical, 3 is unknown whether it supports a critical service, 4 is a known critical service.
Rollout confidence: 0 means audit mode, a proper digital twin or strong evidence from logs; 4 means no failover, no or limited tests, and weak or anecdotal validation.
Recoverability: 0 means no state change, 1 a simple undo such as an API revert, 4 manual reversal, irreversible, or recovery that depends on many teams or systems.

In the Criticality scale, not knowing whether a system supports a critical service scores 3, worse than a known support role at 2. Our reading is that this penalises ignorance, though the Scope scale does not follow the same pattern (unknown scope scores 2, below multi-system at 3). Chismon calls low-potency tasks, where the AI advises a human rather than affecting a system, an easy win. He also asks whether defenders can focus on systems that are easy to recover, following the “cattle, not pets” model; that is a question in his piece, not a conclusion.

The blog does not say how to combine the five numbers and, in the page text we read, gives no threshold (no evidence found as of October 30, 2026). Our assessment: treat the highest single dimension as a gate rather than a sum, because one 4 (irreversible, or a known critical service) should block autonomy however good the other scores are.

Step 2: pick oversight to match

The August blog names three models. Human-in-the-loop means a person approves actions before they happen. Human-on-the-loop means a person monitors and can intervene. Human-out-of-the-loop means no review. For significant consequences it recommends named individuals or groups responsible for agent activity, real-time alerts on unexpected behaviour and the ability to stop the agent. If you use a judge model to watch another agent, it says that judge should be evaluated independently, since it has its own limits.

It also warns against relying on prompts alone. Some agents compress their context, so where appropriate it suggests repeating critical constraints, but it pairs that with technical and operational controls.

Step 3: choose the sandbox tier

The August blog gives two four-level maturity models, level 1 weakest and level 4 strongest.

Network

Unrestricted access.
An allowlist of approved domains.
Access only to the model’s API.
No external access, with the model hosted inside the sandbox.

Compute

No isolation, so the agent shares the host with other workloads.
Kernel primitives such as properly configured OCI containers, with residual kernel-escape risk.
Virtualisation-based isolation, still on the same host as other workloads.
Dedicated hardware.

The NCSC warns that an agent prompted or trained to do so may find configuration issues or vulnerabilities in these controls, leading to a sandbox escape, and advises layered isolation with regular validation. Where possible, it says to deny all inbound and outbound traffic by default and allow only what is required. For use cases that need internet access, it says to consider protocol- or service-aware proxies that permit connections only by exception, with manual approval outside approved scopes.

Credentials get prose advice rather than a maturity model: each agent should have its own identity class, only the permissions it needs and credentials with the shortest possible lifetime where possible. For some use cases, the NCSC says a proxy can help by injecting credentials into requests without exposing them directly to the agent.

Step 4: log it like a user

Collect the agent’s transcripts and chain of thought traces, plus access logs, proxy and network telemetry from the sandbox. Keep them immutable where possible, and consider whether the log pipeline itself is an escape route. The NCSC says agent activity should be treated as user activity inside 24/7 monitoring, and that initial experiments may run in office hours, when more human oversight is available, before expanding to overnight or weekend autonomous execution once controls are shown to be effective. It also asks operators to make agent traffic as easy as possible to attribute, noting methods are still emerging (examples include IP addresses with reverse lookups), and to keep an emergency shutdown available.

A combined gate

Our assessment, not an NCSC rule, and an extension of a defensive-action rubric to agents generally: before an agent workflow goes live, record its five scores, the oversight model, the network tier, the compute tier and the credential lifetime in one review ticket. Any workflow with a 3 or 4 on potency, criticality or recoverability should need human-in-the-loop approval and compute tier 3 or higher. We limit the trigger to those three because they bear most directly on blast radius; scope and rollout confidence should still raise a flag at 4. Anything that touches the internet and holds credentials should sit behind a proxy that injects them.

Limits

Both documents are blogs, not standards. The September blog is one author’s proposal and leaves scoring thresholds open, and Chismon says research is still needed on proving that low-risk actions are low risk. We did not test any of these controls against a deployed agent.

NCSC Agentic AI Advice: Risk-Score Actions, Then Match a Sandbox (Our Mapping)