NCSC Annual Review 2026: lessons for AI agent security

AI did not create the weaknesses. It exposed them.

The NCSC’s tenth annual review opens its threat chapter with attacks on power grids, a breach of government personnel records and disruption to telecoms and hospitals. Then it reveals the year: 2015. A decade later, many of the same routes into organisations are still open.

I read the review with one question in mind: what does this mean for teams putting AI agents into production? An agent with broad permissions inside a poorly governed environment can turn an existing weakness into a repeated action across several systems. The task may be new. The credential, exposed service or missing approval often is not.

The UK National Cyber Security Centre, part of GCHQ, published the review on November 3, 2026, covering September 1, 2025 to August 31, 2026. CEO Richard Horne writes: “AI did not create these cyber security weaknesses; it revealed them.” That observation connects the incident record to the deployment decisions teams are making now. NCSC foreword · A decade of cyber threat.

What the incident figures establish

1. 1,831attack reports received
2. 337incidents requiring NCSC support
3. 80of those were nationally significant

These are stages of triage, not additive totals or counts of AI attacks. Separately, Early Warning notified 8,500 organisations of suspected compromise.

The figures show the workload reaching the national response team, rather than the total number of compromises in the UK. The review also cautions that incident reporting does not follow a simple year-on-year trend: significant events and early intervention can change the number of cases that need direct support.

This is why I would begin an agent review with access, not with the sophistication of the model. Those four routes already exist around developer workstations, SaaS integrations and MCP deployments. Source: NCSC’s decade of cyber threat.

The incident team observed attackers using AI, but none of those observed uses enabled a novel class of attack. Known vulnerabilities, stolen credentials and social engineering remained recurring routes into organisations. That is a bounded observation from the incidents the team handled, not proof that every possible agent failure fits an existing attack pattern. Source: NCSC incident management.

For an agent deployment, start with the identities already trusted by the environment. A support assistant may inherit a database credential; a coding agent may find a deployment token in its shell. Giving either a narrower task in a prompt does not reduce the permissions attached to that credential.

The business cost is substantial. The review cites UK government research estimating annual malicious cyber activity costs of £14.7 billion for UK organisations. It separately cites approximately £196 million in direct cyber-related costs reported by Jaguar Land Rover after its 2025 incident, alongside disruption to production and the wider economy. These are different measures and scopes, not comparable estimates of one attack. Source: The cyber threat to the UK.

AI accelerates operations; people still matter

The NCSC assesses that AI’s greatest impact will be increasing the speed and scale of established attack methods. Its assessment also says adoption is uneven and human operators remain important for directing, checking and adapting model output. More capable operators can extract greater benefit from the same tools.

Loss of control matters on both sides. The review judges that agentic systems drifting from their objectives are highly likely to hinder attackers too. Teams should therefore distinguish an agent completing several technical steps from evidence of a reliable, autonomous campaign.

The review also describes a pessimistic 2028 scenario involving an automated actor outside its operator’s control. The NCSC explicitly presents this as an illustration of the consequences of inaction, not a prediction or an observed incident. Its threat assessments and this scenario should not be collapsed into one claim. AI threat assessment · 2028 scenario.

GTG-1002: tactical automation still needed supervision

In November 2025, Anthropic disclosed a campaign it attributed with high confidence to a Chinese state-sponsored group, GTG-1002. It reported roughly 30 targets and a small number of successful intrusions. Claude Code and connected tools supported reconnaissance, exploitation, credential harvesting and exfiltration. Humans selected targets and intervened at consequential stages; the model also overstated results. This is Anthropic’s account, not an independently reproduced measure of end-to-end autonomy. Anthropic disclosure.

There is a separate signal in the HexStrike AI discussion. Check Point reported underground-forum claims about using the open-source security framework against newly disclosed NetScaler flaws, including CVE-2025-7775. Forum posts and claims of sub-ten-minute exploitation are not verified measurements of successful operations. The relevant warning is that tools built for defenders can also be adapted by attackers. Check Point’s analysis.

Looking ahead, the NCSC judges it highly likely that China, Russia and other states will routinely use AI in cyber operations by 2028, and that AI-powered malware will feature in a ransomware attack on UK critical infrastructure within that window. Those are forward-looking assessments, distinct from both today’s incident evidence and the review’s pessimistic scenario. NCSC threat outlook.

Four questions to answer before connecting an agent

The review’s technology chapter identifies four areas organisations need to understand: the data a model can access, the tools an agent can invoke, the instructions it trusts, and how its actions are observed and constrained. The following checks turn those questions into something a deployment owner can verify. Source: A decade of technological change.

1. What data can it access?

List the repositories, files, databases and authenticated sessions reachable by the runtime identity. Include inherited credentials and alternate routes through a shell or browser. In a test environment, allow a legitimate query and attempt a synthetic export outside the task’s scope. Check the destination’s records as well as the agent’s response.

2. Which tools can it invoke?

Record the MCP servers, skills, plugins and executables available to the workflow, with their versions and owners. Separate permission to read from permission to write, deploy, send or pay. An allowlisted tool may still accept dangerous parameters: a permitted HTTP client can send data to an unintended destination unless the destination is also constrained.

3. Which instructions does it trust?

A web page, repository issue, email or tool response is task data. Test whether instructions embedded in that content can change the agent’s goal or trigger a prohibited action. Prompts should explain the task, while access restrictions remain enforced outside the model. Our analysis of prompt injection and authorization follows that distinction through a tool call.

4. How are actions observed and constrained?

Identify who can stop new work and revoke access. Record the acting identity, requested tool, target, policy decision and outcome without copying secrets into logs. Test a denied action, an interrupted action and an operation whose outcome is unknown after a timeout. A log saying “allowed” does not establish that the destination completed the operation.

1. 01
   Untrusted input

   Issues, pages and tool responses inform the task. They do not grant authority.

2. 02
   Independent policy

   Check identity, tool, arguments, destination and any required approval.

3. 03
   Scoped access

   Use a constrained backend identity. Close alternate routes around the check.

4. 04
   Observed outcome

   Match the decision to the backend result. Preserve unknown or partial outcomes.

If the check failsStop before execution and record the reason. If the target or payload changes after approval, evaluate the new operation.

The four questions already have public cases behind them

The examples below expose different failure modes. Nx and the fake Postmark connector involved malicious software; Invariant’s GitHub example was a research demonstration; Replit was an unintended agent action reported by the affected user. Grouping them as four equivalent attacks would hide what each case teaches.

There is another useful credential case. Google Threat Intelligence reported that UNC6395 used compromised OAuth tokens associated with Salesloft Drift to export Salesforce data between August 8 and at least August 18, 2025. It did not attribute the entry point to a flaw in core Salesforce. This illustrates the authority carried by a trusted integration; it is not evidence that an AI model autonomously conducted the theft. Google investigation.

These cases are why I connect inventory, permissions, content inspection and evidence in Oktsec Control. A list of installed agents is useful, but it becomes operationally meaningful when it shows what each installation can reach and which decisions are actually enforced.

Seven incident lessons applied to agent deployments

The NCSC distils its incident experience into seven lessons. These are our proposed applications to agents, rather than an additional NCSC checklist. Read the original seven lessons.

1. Check exposed systems first. An outdated connector or publicly reachable management interface needs an owner and a correction, regardless of how capable the model is.
2. Protect people and the inputs agents read. Keep phishing-resistant authentication for people; treat external content as untrusted input for agents. Those controls address different mechanisms and both are needed.
3. Use the same access discipline against state and criminal threats. Scope credentials, remove unnecessary access and verify revocation. An attacker’s sophistication does not make a shared administrator token safer.
4. Limit destructive authority. Separate read-only investigation from deletion, deployment and recovery permissions. Maintain independently protected backups and rehearse restoration.
5. Prepare the evidence before an incident. Know which systems record tool requests and outcomes. Include MCP servers, skills and plugins in supplier and dependency reviews.
6. Act on meaningful changes early. A newly connected server, expanded permission or missing telemetry should trigger a review while the affected scope is still small.
7. Test what a valid account can do. An agent holding a legitimate credential may not need an exploit to cross a business boundary. Verify that the credential cannot access another customer, environment or workflow.

Prepare for more findings without losing triage

The NCSC has asked organisations to prepare for a wave of vulnerability disclosures and patches as AI exposes accumulated technical debt. For teams running agents, the update inventory needs to include runtimes, SDKs, MCP servers, plugins and the applications those tools connect to. A model upgrade does not patch the surrounding software. Source: Preparing for a vulnerability patch wave.

Project DROMOS offers a useful defensive example. It began with a four-week pilot examining government code repositories and expanded to selected operational environments. The review reports hundreds of potential security issues, including critical vulnerabilities. It also describes human oversight, governance and processes for handling false positives. Potential issues are not a count of independently confirmed, exploitable flaws. Source: Project DROMOS.

Teams need a finding-to-fix process that can handle this volume. Record the affected version, reachable attack path, required access, potential impact and evidence supporting the finding. A safe reproduction is valuable where feasible. A working exploit is not a universal prerequisite for action: an exposed credential, an unsafe permission or a credible vendor advisory can justify containment before a proof of concept exists.

The NCSC’s proactive vulnerability notification service sent more than 52,000 notifications, with about 70% of identified vulnerabilities subsequently resolved. The report acknowledges that some organisations may have fixed issues independently. A trial found remediation up to 45% faster among notified organisations. These are results from that service and trial, not a promised improvement for every security programme. Source: Securing the UK’s internet.

Another result in the review is the reduction in median remediation time for government domain-related vulnerabilities from 50 days to 8 days. That is a result for a specific programme and class of vulnerabilities, not a general patching benchmark. It nevertheless shows why ownership and a working response process matter as much as discovery. NCSC full report, “Securing the backbone of society”.

There is a concrete AI-assisted defensive case too. In July 2025, Google said its Big Sleep agent, working with threat intelligence, identified SQLite CVE-2025-6965 before an anticipated exploitation attempt. Google described this as preventing imminent use of the flaw. The lesson is the combination of intelligence, discovery and intervention, rather than the model operating alone. Google’s account.

1. 01
   Find the installation

   Identify version, exposure, owner and the agent workflows that depend on it.

2. 02
   Establish the risk

   Review the attack path and evidence. Reproduce safely where feasible.

3. 03
   Contain or update

   Assign urgency from impact and reachability. Prepare rollback and revoke exposed credentials.

4. 04
   Check the running system

   Verify the installed correction, permitted work and the previously unsafe action.

Insufficient evidence?Keep the finding under investigation with an owner. Do not label it fixed, or dismiss it solely because no exploit is available.

Defensive agents need bounded authority too

The NCSC’s Cyber Shield programme aims to build a national ecosystem of defensive agents over five years. Its initial operational capability focuses on detection and blocking. The review describes those tasks as more amenable to automation than autonomous remediation, while identifying assurance of safe, predictable and proportionate action as a remaining challenge. Source: Cyber Shield.

For a security team, a reasonable first deployment is an agent that gathers evidence and recommends a response with limited access. Before permitting it to block a destination or change production, define the affected scope, approval requirements, rollback method and stop conditions. Blocking can itself disrupt a service; “defensive” is not a sufficient authorization rule.

The NCSC’s separate agentic AI guidance recommends explicit oversight, technical controls, isolation and restricted credentials. It cautions against relying on prompting alone. Our implementation preference is to make authorization decisions through explicit, testable policy outside the model. That is an Oktsec design choice, not a claim that the NCSC mandates one architecture. Source: Managing the cyber risk of agentic AI.

Oktsec Control applies policy to activity routed through its configured integrations. It complements endpoint, identity and network controls; it cannot enforce restrictions on a path that bypasses it. A scoped assessment can test whether those alternate paths exist and whether the expected limits hold.

1. Observe
   Collect and correlate evidence

   Read-only permissions, defined data scope and reliable telemetry.

2. Propose
   Present a specific response

   Identify the target, expected effect, uncertainty and affected service.

3. Approve
   Bind authority to that operation

   Named approver where required, exact parameters and a limited validity period.

4. Act & verify
   Execute within the approved scope

   Check the result and service health. Stop or roll back when the agreed conditions fail.

Previously approved, low-impact actions may follow a tested automatic policy. Irreversible changes, uncertain impact or a changed target return to human review.

The defender’s advantage is that it owns the environment: it can instrument systems, define acceptable behaviour and change access. That advantage only becomes real when the controls cover the execution path. My preference is a deterministic authorization layer with explicit policy, so the guardrail does not depend on another model agreeing with the first one.

The NCSC’s Principles Based Assurance makes a related point about evidence: confidence in a security claim needs to survive changes in the technology and threat environment. For an agent workflow, signed records can help establish origin and integrity, but they cannot prove that every action was captured or that a missing path was controlled. The assurance question is what the record covers and how the team verifies the claim.

What teams deploying AI agents should do now

The NCSC writes for the whole economy. This is how I would turn the review into a deployment plan, starting with agents that can reach customer data, production infrastructure or money.

There is also a physical boundary. Agents connected to industrial equipment, robotics or medical devices can affect safety, availability and reliability as well as information. In those environments, the equipment owner and operational team need to define the test conditions and safe response limits before automation expands.

Start with one consequential workflow. Test a necessary action, a prohibited action and revocation. Keep the destination’s evidence, identify the gaps and assign the next correction. Ten years of incident experience make the same point: familiar weaknesses still matter, and machine-speed execution leaves less time to discover them after the fact.

Sources and scope

This analysis uses the NCSC Annual Review 2026, published November 3, and the NCSC guidance linked alongside the relevant claims. Reporting-period counts, assessments and scenarios are identified separately. The control proposals are Oktsec’s analysis. The case matrix distinguishes reported incidents, a research demonstration and an operational failure; it does not claim that the NCSC investigated those examples. The review does not assess Oktsec or establish compliance for a particular deployment.