AI for cyber defence means using artificial intelligence (AI) to help find, understand and fix security weaknesses before an attacker uses them. AI in cyber security is good at the volume work: sorting vulnerability reports, reading code and logs, taking malware apart, and keeping the record during an incident. The decisions stay with people.
This guide covers where AI helps defenders, how to use it to attack your own work before release, the rules that keep it safe, and how ddx works this way.
Why defenders are using AI now
Attackers already use AI. The UK’s National Cyber Security Centre (NCSC) expects AI to increase the number and the impact of cyber attacks up to 2027, mainly by making existing methods faster and better rather than by creating new ones. One effect it names: attackers will use a weakness sooner after it is made public.
October 2026 showed both sides. In August, researchers at two security firms, Calif and Wiz, used AI models to find serious flaws in PHP, the programming language behind a large share of the world’s websites. The flaws, now called PHP2Shell, were in every version of PHP released in the last ten years. They let an attacker run their own code on a web server without signing in, or read passwords and keys from its memory. Wiz says AI helped at every step: finding the flaws, building working attacks on popular website platforms within hours, and checking the fixes. The models it names include Google’s Gemini 4 Argon.
The researchers told the people who maintain PHP, who released fixes on 21 October, after details had leaked. Finland’s government web services, the Dutch national cyber security agency and parts of Wikipedia went offline while they were fixed. Amazon Web Services reported attackers trying to use the flaws on a large scale. The same tools that find a weakness can help an attacker use it, so the time to check, fix and watch for attacks is now short.
AI finding real flaws isn’t new. In 2024, Google’s Big Sleep project used an AI agent to find an exploitable bug in SQLite, a widely used database, before the code reached a release. Google’s team called that work highly experimental, and said a fuzzer built for the target (a tool that sends a program very large numbers of random inputs) would probably do at least as well.
None of this means AI replaces a security team. In both cases, people chose where to look, checked what the AI found, and decided whom to tell and when. AI can now do useful security work, and its work needs checking like any other source.
What AI is good at in cyber defence
Vulnerability triage and checking
Scanners and dependency checks produce long lists of possible weaknesses, and in any one system most of them don’t matter. Triage means deciding which ones do. AI can read the code around each finding and answer the questions a person would ask. Can an attacker reach this code? With what input? Does an existing check already stop it? It can then explain the answer in plain words, suggest a fix, and write a test that proves the fix works.
It also does the reverse well: reading code to look for the kinds of mistake that become vulnerabilities, such as a missing permission check, unsafe handling of what a user types or uploads, or a password left in the code. It is good at finding variants. Show it one bug and it can search the rest of the code for others like it. That is how Big Sleep found the SQLite bug.
Detection
Security monitoring produces more alerts than people can read. AI can read logs and alerts, group the ones that belong to the same event, explain in plain words what an alert means, and suggest what to check next. It can draft detection rules, the patterns a monitoring system watches for, from a description of an attack. A person tests each rule before it goes live.
Malware analysis
Taking a suspicious file apart used to take a specialist several hours. AI can read a script or a decompiled program, remove the parts written to confuse a reader, and explain what the code does: what it downloads, what it changes, and where it sends data. It can list what to search for elsewhere, such as file names, network addresses and domains. All of this happens on a copy of the file, in an isolated environment, never on a machine people use for work.
Incident response
During an incident, people lose time to writing. AI can build a timeline from the logs, keep notes as the team works, summarise the position for managers in plain words, and draft the report afterwards. It can check the team’s steps against the response plan, so nothing is missed. Decisions on how to contain the problem, and when to tell clients and regulators, stay with the people responsible for them.
Where it goes wrong
- It can be confidently wrong. It may report a weakness that isn’t there, suggest a fix that doesn’t work, or cite an advisory that doesn’t exist. The NCSC calls this AI hallucination.
- It sees only what you show it. It doesn’t know which systems face the internet, or which data matters most, unless someone tells it.
- It can be steered by what it reads. A log entry, a web page or a comment in code can hold instructions written for the AI, not for people. This is called prompt injection. OWASP (the Open Worldwide Application Security Project) ranks it as the first risk for applications built on large language models.
Adversarial reviews: attack your own work before release
An adversarial review asks AI to take the attacker’s side against your own work, before anyone else does. It suits three kinds of work.
- Code. Give the AI a change, or a whole service, and ask how it would break it: get past the sign-in, read another user’s data, upload something harmful, or stop the system working.
- Designs. Before anything is built, give it the design and ask what an attacker would try at each point where data passes from one system or user to another. This is threat modelling. AI makes it quick enough to do for every design, not only the large ones.
- AI features. A chatbot or an AI agent in a product is a new way in. Ask the AI to make the feature ignore its rules, reveal its instructions or another user’s data, or use its tools for something it shouldn’t.
Then a person who didn’t write the work reviews every finding. They repeat each one in a test environment, reject the ones that aren’t real, decide what to fix first, and record why. A finding nobody can repeat isn’t a finding. A finding nobody owns doesn’t get fixed. Each confirmed attack becomes an automated test, so the same weakness can’t return without someone noticing.
This isn’t a penetration test. A penetration test attacks a running system the way a real attacker would. It needs written permission from the system’s owner, specialists to run it, and its own agreed scope. An adversarial review works on the code, designs and AI features of the systems you build, before they are released.
Best practice for AI in cyber security
A named person owns every output
Every finding, fix, rule and report that AI produces has a named owner. They check it, approve it and answer for it. “The AI said so” is not a reason to change a live system, or to tell a client something.
Client data goes only into approved tools
Logs, code and incident records often hold personal data, client secrets and details of weaknesses that aren’t fixed yet. Decide in advance which tools may see which data, check what each tool’s provider does with it, and keep a list. A tool that isn’t on the list gets nothing.
Contain and log AI agents
An AI agent can run commands, read files and use other systems. Give it only the access the task needs: OWASP calls the opposite “excessive agency”. Run it in a separate environment with test data, not on live systems, and without live passwords or keys. Limit what it can reach on the network. Ask a person to approve any action that changes something. Log every instruction, every tool it uses and every result, so you can see later what it did and why. Treat everything it reads as untrusted, because of prompt injection.
The UK’s Code of Practice for the Cyber Security of AI asks for the same things: people able to oversee the system, security testing before release, and logs of what the system and its users do.
Stay within what your access permits
Security work needs permission. Test only the systems you own, or the systems a client has asked you in writing to look after, and only within the scope you agreed. AI tools built for security work come with their own terms. Some allow defensive work but not attacks on systems, and some are open only to teams the provider has checked. Read the terms and stay inside them. If the work needs a penetration test, arrange one separately, with the right people and the right permission.
How ddx works this way
ddx is approved to use AI models built for cyber defence, open only to verified security teams, to find and fix weaknesses in the systems we build and run.
AI handles the volume, our team brings the judgement. Every AI tool we use sits under one framework, including frontier models (the most capable AI models available) such as Claude Fable 5.1, Claude Opus 5.5 and GPT-6 Astra. A named person owns every output, and nothing AI produces reaches a client until they’ve approved it. Client data goes only into approved tools. Everyone at ddx is tested on the framework every year.
We run adversarial reviews on the systems we build, for clients and for ourselves: the code, the designs and the AI features, with every finding checked by someone who didn’t write the work.
We’re now looking at detection too. An attack like PHP2Shell first shows up as unusual entries in a server’s logs: memory errors after strange uploads, or a run of server errors. The plan is to send every log entry that isn’t standard to a decision model, such as Jev from TypeSafe AI or Cloudflare’s Clef. A decision model is a fast AI model that gives a set answer to a fixed question, here whether the entry is expected, with a score for how sure it is. If the entry isn’t expected, a frontier model reviews it, and the code that produced it, as it happens. A person on the team then decides what to do.
For Torn, we built the AI assistant’s guardrails: they sort what players ask, and stop attempts to jailbreak the assistant (trick it into ignoring its rules) or misuse it.
We protect our clients’ information under an information security policy based on the ISO/IEC 27000 standards. We’re certified under the UK Government’s Cyber Essentials scheme, and we hold our own cyber insurance as well as the cover that comes with it. Read more about information security at ddx, or see what our Technology practice builds.
