‘Can we get budget to replace this end-of-life system or invest in a more secure option?’

‘How do I get IT operations to make time for patching?’

‘How do we get a change request to put in firewall rules approved?’

In other words, defenders are most restricted by their organisational policies, whilst most attackers are restricted by technical hurdles. The reason for this difference becomes clear when you compare the core purposes of attackers and defenders.

For attackers, their core purpose is ‘to conduct cyber offence’ and success will cause their employer to profit. Whether that’s stealing money from organisations, extorting victims, or exfiltrating information. Cyber offence is their raison d'être.

For the defenders, their mission is to help their organisation avoid loss. Their employer’s mission isn’t cyber defence; it will depend upon whatever activity that organisation does (such as developing products, treating patients, or providing digital services). Cyber defence is effectively ‘a cost of doing business’, one of many priorities that the organisation has to manage.

This means the cost of cyber defence has to be rigorously assessed to make sure it does not harm the organisation’s competing priorities:

‘Could that money earmarked to replace the end-of-life system be better used on marketing?’

‘Will that patch take down the VPN?’

‘How sure are we that the firewall rule will not break a business function that relies on that connectivity?’

Some board members may see little difference between a DoS attack taking down the organisation’s IT, or a poorly implemented action by the cyber defence team that does the same thing. Except that the board can’t shout at an attacker over the phone …

Agentic tooling can be used for cyber offence, because AI is good at helping with technical problems with a clearly measurable success state. Offensive problems are mostly technical, and usually have a clear success state (the target program crashes, your malware calls home). But defensive problems, as we’ve established above, are not mostly technical. Nor do they always have a clear success state. 

Using AI automation for defence therefore quickly becomes a matter of organisational politics, and someone needs to be responsible for the action taken. Defenders simply cannot put AI to work in the same way attackers can. This is an inconvenient truth, as it suggests that the threat from AI-enabled cyber attacks will grow, whilst autonomous / agentic cyber defence might struggle to keep up unless we approach things differently.

How can defenders make better use of AI?

Rather than trying to mimic attackers’ use of agentic tooling (and risk breaking things), defenders need to solve the problem by explicitly considering the constraints. I am biased, but I think the work on Autonomous Cyber Defence by CETAS  – commissioned by the NCSC – is excellent. It identified early that defenders have different levels of appetite for where they would apply AI. But how can we break the problem down further to make it tractable?

To start with, let’s examine the technical defensive tasks and consider how we might use AI automation. Firstly, there is the category of offensive techniques being applied defensively, such as penetration testing and vulnerability research or discovery. These are typically done in a way that minimises risks to the business; applications are tested before they go live, and vulnerabilities are handed to development teams to fix.

Vulnerability scanning can take a lot of buy-in across an organisation. The first scan requires convincing management that it will not break anything. However, it quickly becomes a business-as-usual service, identifying unpatched vulnerabilities.

Secondly, there are examples of where technical and dynamic approaches are used for cyber defence. Establishing a SOC is also typically a lengthy (and often expensive) process. Legal aspects and policies need to be agreed, and data then exported from live systems to a new platform where malicious activity can be detected and triaged before the team takes action.

For both the above, there is a lot of work done upfront to show that detection of vulnerabilities or missing patches will not harm the business. The results of the detection are then given to humans to action, whether that’s development teams to implement fixes, system owners to apply patches, or incident response teams to respond to incidents 1.

There are 3 core principles at work here:

Technology is behind the detection, but humans respond with actions.

The technological detection must not harm the organisation.

The technological response is tightly controlled and scoped (for example to a single user account or computer in response to a clear malicious signal).

By developing these principles and splitting the problem into different dimensions, we can propose a framework for estimating the 'riskiness' of a defensive action: 

DimensionLevelDescription

Potency

Whether the automated process can only observe existing state or can alter systems, permissions, configuration or runtime behaviour.0AI provided data and then outputs explainable advice to a human

1AI provides non-explainable advice to a human

2Autonomously collects data using read-only privileges across APIs and web search introducing a risk of exfiltration, data being added to files

3

Changes data or system state via APIs

(Easier to guardrail than code)

4Executes code or makes direct system/runtime changes

Scope

How bounded the affected technical estate is.0Single system

1Known set of systems

2Unknown scope

3Multi-system or cross-domain

4Enterprise-wide, fleet or shared platform

Criticality

How important the affected scope is to business or mission delivery. Includes the criticality of systems within the scope.0Known not critical; not business relevant

1Business relevant but non-critical

2Known support of critical service

3Unknown whether it supports critical service

4Known critical system or service

Rollout confidence

How well the proposed scope and impact can be proved before execution.0Audit mode, proper digital twin environment, or strong evidence from historical/recent logs

1Imperfect development environment or system twin, or partial logs

2Can ring-deploy, with strong test suite

3Single system with no failover, but robust tests

4No failover and no or limited tests; weak or anecdotal validation

Recoverability 

How cleanly and quickly harm can be reversed if the automation is wrong.

 0None needed because there is no state change

1Simple undo, for example API revert or permission rollback

2Code or configuration rollback with no wider systemic effects, using CI/CD

3Rollback possible but may leave inconsistent state, currency or dependency issues; possibly CI/CD of a complex system

4Manual reversal, irreversible, or recovery depends on many teams or systems

By considering the above (or something like it) we can identify the lowest-risk actions that we can start to automate. An easy win is focusing on tasks that are low potency ('advise a human' rather than 'affect a system directly'). Florian Roth has a good blog on how defenders can use generative AI to make sense of the deluge of data they face and prioritise their actions. AI is good at summarising and so is already useful to defenders in finding details, or making sense of the huge volumes of reports or threat intelligence. 

Areas that can already be largely automated are good candidates for implementing agentic processing around or extending, for example, detection efforts.

Next, we look at how we can reduce the risk of tasks we want to automate but currently are uncomfortable with doing so. Can we focus on systems we know are easy to recover, ing the ‘cattle, not pets’ model? Government teams have also been working with departments to use agentic tooling to rewrite or recreate legacy systems in modern, and therefore more re-deployable, stacks. See the Defra AI Legacy Modernisation Playbook and reporting on the government’s AI code-remediation pilots.

Unlocking the potential of agentic AI actions

The NCSC and DCMS are jointly working on Cyber Shield, a national-scale agentic cyber defence ecosystem, and delivering that vision will require making autonomous defensive actions possible in a way they currently are not. As part of this, the NCSC sees a number of areas where we think specific research is needed to unlock the potential of agentic cyber defence, and will be publishing our ‘AI for Cyber Defence’ problem book soon.

An area where I believe we particularly need research, products, and evidence of efficiency is in how we deterministically prove that ‘low risk’ actions really are low risk. Can AI help us analyse traffic logs and show conclusively that we do know all the routes clients connect by? Can AI reverse engineer or otherwise assess a system and its binaries to show exactly which network calls it could ever make, or which processes it might need to spawn?

Answering these questions will give us, and the organisations we protect, the confidence to take automated defensive actions. Furthermore, it opens up the chance to automate the hardening of systems and reduce attack surfaces and exposure, which will be crucial in combating AI-enabled cyber attacks.

All these efforts will take time, effort, and research. Organisations cannot risk just waiting for agentic defence to roll in and protect them; they also need to be focussing on improving their security the traditional way.Dave ChismonCTO for Architecture

[1]There are a very small number of cases where remedial action is automated, such as security orchestration, automation and response (SOAR). In SOCs that use SOAR, automations might be enabled that, for example, make a user re-authenticate if suspicious activity is seen. Each rule is crafted, tested and, crucially, highly deterministic.

Share and print this article Share Share Close share options Share onFacebook Share onLinkedIn Share onX Copy Link

Written by Dave Chismon

CTO for Architecture

Published 21 September 2026

Written for

Cyber security professionals

Large organisations

Part of blog NCSC publications

Was this article helpful?

Yes the article was helpful

No the article was not helpful Close Feedback Form Back to top Share Close share options Share onFacebook Share onLinkedIn Share onX Copy Link

Also see Blog Post 15 May 2026

Thinking carefully before adopting agentic AI

When it comes to using agentic AI, make sure you can walk before you run. Blog Post 7 Sep 2026

The hidden risks of shadow AI

Understanding why staff use unapproved AI tools is key to managing the security challenges they can create. Blog Post 20 Aug 2026

Managing the cyber risk of agentic AI

Use safeguards, sandboxing and active oversight to realise the benefits of autonomous systems while limiting the unintended activity.