AI cyberattacks are getting cheaper to launch - and harder to defend against

A sharp phrase from the recent debate cuts through the fog: treating an AI system as an autonomous being is not a serious defence when something goes wrong. That matters, because the practical question for businesses is no longer whether AI can be used in cyberattacks. It can. The question is who remains accountable when AI tools are connected to real systems, real data and real permissions.

The discussion was sparked by a reported run of cybersecurity incidents described as “Black October”. The details included AI developers, government agencies and private companies disclosing incidents, plus the discovery of decade-old flaws in PHP, a programming language described in the source material as powering an estimated 70% of websites. Researchers reportedly uncovered those PHP flaws with help from AI models.

This is the important bit for UK organisations: AI is not making every attacker magically brilliant. It is making a lot of ordinary attack work cheaper, faster and easier to scale.

AI is compressing the cyberattack timeline

The UK National Cyber Security Centre has warned that AI will make parts of cyber intrusion more effective and efficient, including reconnaissance, social engineering, vulnerability research, exploit development and analysis of stolen data. Its assessment also says that by 2027 AI-enabled tools will almost certainly improve attackers’ ability to exploit known vulnerabilities, reducing the gap between disclosure and exploitation. The NCSC’s report on AI and the cyber threat to 2027 is worth reading if you manage technology risk.

That lines up with the central concern in the discussion. One expert quoted in the source material put it plainly: AI can generate a security patch quickly, but humans still need to review it, test it, coordinate disclosure and deploy it across organisations. Attackers can move at machine speed. Defenders still have meetings, change windows, legacy systems and operational risk.

That is the asymmetry. Not that AI has become a villain in a hoodie, but that it reduces the friction on the offensive side before it reduces the friction on the defensive side.

Why old vulnerabilities become new problems again

Many AI-assisted discoveries will not be exotic, never-seen-before weaknesses. They will be familiar bug classes found in forgotten corners: injection flaws, unsafe parsing, authentication mistakes, exposed admin tools, dependency issues and poor configuration.

AI is good at pattern matching across large amounts of text and code. That means a model can help compare code, documentation, public vulnerability write-ups and configuration patterns at a scale that humans struggle to match. It can suggest where old mistakes might have been repeated.

For a software team, that can be genuinely useful. For an attacker, it is also useful. The same capability that helps a developer identify a weak parser can help a criminal look for a similar weakness in an internet-facing service.

This is why vulnerability management can no longer be treated as a quarterly compliance ritual. The NCSC’s vulnerability management guidance recommends knowing your assets, updating by default, responding to active exploitation, prioritising effectively and treating decisions not to update as senior-level risk decisions.

The uncomfortable accountability question for AI agents

The headline argument that companies should face criminal consequences when their AI hacks is provocative. For UK readers, the key point is not whether an AI is philosophically “autonomous”. It is whether a person or organisation chose to deploy, authorise, supervise or ignore a system that caused harm.

The exact legal outcome in any individual case is not disclosed in the source material, and this is not legal advice. But from a governance perspective, blaming the tool is unlikely to satisfy customers, regulators, insurers or prosecutors if a business gave that tool access to sensitive systems without proper controls.

That becomes especially important as AI agents become more common. An agent is an AI system that can take actions, such as reading tickets, calling APIs, writing code, changing settings or triggering workflows. The risk is not simply what the model says. It is what the surrounding system allows it to do.

A chatbot that gives a poor answer is one kind of risk. An AI agent with write access to production infrastructure, customer records or payment workflows is a different category entirely.

AI helps defenders too, but not automatically

It would be a mistake to frame this as “AI for attackers versus humans for defenders”. AI can help security teams as well. It can support log analysis, phishing detection, malware triage, code review, alert enrichment and vulnerability prioritisation.

DARPA’s AI Cyber Challenge has also reported progress with autonomous cyber reasoning systems that can help secure open-source software used in critical infrastructure, including finding vulnerabilities and supporting patch development. DARPA’s summary of the AI Cyber Challenge results shows why AI-assisted defence is not just theory.

But defence is harder to automate safely. An attacker only needs one route in. A defender has to protect a messy estate without breaking payroll, ecommerce, operations, email or customer support. An over-eager automated response can cause its own outage if it blocks the wrong system or deletes the wrong data.

That is why the answer is not “let the AI handle cyber”. The answer is controlled automation, with clear limits, logs, escalation paths and human review for high-impact decisions.

What UK businesses should do now

If you run a UK business, the practical response is not panic. It is discipline. AI raises the tempo of cyber risk, so your controls need to become more visible, repeatable and board-owned.

• Build a live asset inventory. You cannot patch what you do not know exists. Include cloud services, SaaS tools, domains, APIs, code repositories and supplier-managed systems.
• Prioritise internet-facing systems. If a vulnerable service is exposed to the public internet, assume the exploitation window is shrinking.
• Create an AI inventory. Know which AI tools staff and suppliers use, what data they access and whether they can trigger actions in other systems.
• Limit agent permissions. Treat AI agents like powerful junior administrators. Use least privilege, strong identity controls, approval gates and detailed logging.
• Sandbox before integration. Test AI tools in isolated environments before connecting them to email, ticketing systems, customer data, repositories or production infrastructure.
• Make patch exceptions visible. If a critical patch cannot be applied, the risk should be owned by senior leadership, not buried in an IT queue.
• Update incident response plans. Include AI-generated phishing, deepfake-enabled fraud, compromised AI tools and misconfigured agents.

If your business is already exploring AI in security, that is sensible. If you are connecting AI to operational systems without an inventory, permissions model or monitoring, that is not innovation. It is avoidable exposure.

For a deeper look at why automated vulnerability discovery changes the security conversation, I have also written about AI systems that find zero-day vulnerabilities. The same theme applies here: the useful and risky versions of the technology are often uncomfortably close together.

The real lesson is control, not panic

AI is changing cybersecurity by reducing cost, compressing timelines and making old weaknesses easier to rediscover. That is serious, but it is not mystical. Businesses do not need to treat AI as an independent creature. They need to treat it as powerful software operating inside human-designed systems.

The organisations that cope best will be the ones that know their estate, patch quickly, restrict privileges, log decisions and make accountability explicit before an incident happens. AI may move fast, but responsibility still sits with people and companies.