Frontier AI has changed cyber security for good

In November 2025, Anthropic reported that a state-sponsored group had used its coding agent to run most of an espionage campaign against roughly thirty organisations — reconnaissance, exploitation, credential harvesting, exfiltration — with the model doing an estimated eighty to ninety percent of the work and people intervening at a handful of decision points. Five months later the same company said that its newest model had found thousands of high-severity vulnerabilities in widely used software, operating systems and browsers among them, and that it would not release the model generally but give it to defenders first. By May, some fifty partner organisations had found more than ten thousand.

Those two announcements bracket the change: the same capability, at scale, on both sides. This article is about what changed underneath, what it means for the attacking and the defending side, and about a question that now comes up in almost every conversation I have with clients — whether the systems they built themselves are safer than the industry-standard ones everyone else runs, or less.

What changed is the price of attention

Security has always been a contest of attention. Finding a vulnerability, writing a reliable exploit, reading an unfamiliar codebase, correlating a week of logs, noticing that an invoice request is slightly wrong: all of it needed skilled human hours, and skilled human hours were the scarce input on both sides. Attackers rationed them by targeting the valuable, the exposed and the widely deployed. Defenders rationed them too, which is why most organisations have never had anyone read their internal tools for security at all.

Frontier models turned that scarce input into a metered commodity. Reading code, forming hypotheses about where it breaks, writing the test that proves it and the patch that fixes it are now tasks a model performs at a price per token, in parallel, without fatigue. Three consequences follow mechanically.

First, discovery scales with compute, not headcount. In late 2024, Google’s Big Sleep agent found the first publicly reported memory-safety bug discovered by an AI in widely used software, in SQLite, before the affected code reached a release. In August 2025, the seven finalists of DARPA’s AI Cyber Challenge processed fifty-four million lines of code, patched forty-three of fifty-four planted vulnerabilities and found eighteen real, previously unknown ones on the side. In 2026, one model found thousands.

Second, the window between disclosure and exploitation collapses. A patch is a diff, and a diff is a precise description of the bug. A model that reads the one can write the other.

Third, the long tail gets read for the first time. Everything that was never worth an expert’s afternoon — the internal portal, the integration script from 2014, the intake form somebody built with a coding assistant last month — is now worth a model’s minute. To both sides.

The attacker’s side: scale, speed and patience

Reconnaissance is now a query. Assembling a target profile from organisation charts, procurement notices, conference talks and code repositories takes minutes per target, which means the distinction between high-value targets and everyone else has gone. Everyone is a high-value target when personalisation is free — the same shift that ended the era of “looks suspicious” in social engineering. ENISA’s 2025 threat landscape report treats AI as both weapon and target and puts AI-assisted phishing at the large majority of phishing observed in early 2025; Verizon’s 2026 breach report finds generative AI bolstering about fifteen percent of attack techniques and, for the first time, vulnerability exploitation overtaking stolen credentials as the top way in.

Exploit development is where the clock moved most. Mandiant’s long-running series put the average time from disclosure to exploitation at sixty-three days in 2018–19, thirty-two in 2021–22 and five in 2023, before frontier reasoning models existed. In April 2024 an academic team showed a frontier model exploiting eighty-seven percent of a set of fifteen real one-day vulnerabilities given only the CVE description; the models available two years later are far more capable. The practical reading is simple. A public patch for an internet-facing component is an exploit recipe, and the recipe is executed within hours by anyone with an API key. For a decade “zero-day” meant the elite threat and “n-day” the manageable one. For exposed systems that has inverted: the n-day is the cheaper attack, because the patch documents it.

Intrusion operations became agentic. In the campaign Anthropic disrupted, the operators convinced the model it was working for a legitimate security firm, then had it map networks, test credentials, write exploits and sort the exfiltrated data, checking in at four to six points per target. Note what that does to the economics: an operator who could run one intrusion at a time now runs thirty, and the model works through the night.

Malware is beginning to use models at runtime. Google’s threat intelligence group described a dropper that asks a model API to rewrite its own script to evade detection, and a tool attributed to a Russian state actor that generates its reconnaissance commands on the fly. Both were experimental when reported. The direction is clear: signatures against code that is different on every run.

New surfaces appeared inside the defenders’ own systems. An assistant with tool access will follow an instruction hidden in a retrieved document unless it is designed not to — prompt injection is social engineering for machines. And the code assistants themselves have a supply-chain problem: a USENIX Security study found that almost a fifth of package references in over half a million generated code samples pointed to packages that do not exist, with open-weight models hallucinating far more often than commercial ones. Attackers register those names. ENISA now lists the technique, slopsquatting, among its supply-chain trends.

The defender’s side: the same capability, applied first

The defensive story is the same capability read in the other direction, with one decisive difference: order. Defenders can look first.

Discovery at scale started with Big Sleep and the AI Cyber Challenge, whose systems were released as open source after the final. Project Glasswing then did something structurally new: it applied a model that had not been released to anyone to the software everyone depends on — operating systems, browsers, cloud platforms, the Linux Foundation’s projects — through a partner group that at launch included Amazon Web Services, Apple, Cisco, CrowdStrike, Google, JPMorgan Chase, Microsoft and Palo Alto Networks, and gave those partners the model for pre-release checks, patch writing and rewriting legacy components in memory-safe languages. The important detail is not the ten thousand. It is that the widely used software got swept first, by defenders, before the capability existed anywhere else.

Patching is becoming cheap. Systems that generate, test and backport a fix for a found vulnerability turn the thirty-day patch cycle from an organisational constraint into a choice. Whether an organisation exercises that choice is another matter, and the exploit clock does not wait.

Detection and response gained the ability to read everything. Triage of alerts, correlation across logs no human could read in a week, detection engineering from a single incident to a rule set, hunting for the pattern behind the pattern — this is where the model’s tolerance for tedium is worth most, and where the polymorphic malware of the future will be caught by behaviour rather than signature.

The human layer did not go away; it moved. Verification workflows, explicit ownership of risky requests and one-click reporting are still what stops the deepfake call — and now also what stops an agent from wiring money because a document told it to.

The structural advantage is old and now finally usable: defenders have the source, the logs, the topology and the right to look first, and they can change the system. Attackers have to find the door; defenders can count the doors. That advantage was theoretical for every organisation that could not afford security engineers. It is now available to anyone who buys the attention — and worthless to anyone who does not.

The end of obscurity: custom versus standard

The question clients now ask goes like this: “We build a lot ourselves. Are we safer than the organisations running the same three vendors as everyone else — or less?”

It used to have a shape. Widely used software had many eyes on it, from both sides, and it got exploited en masse: one bug, millions of victims. Log4Shell in 2021 and the MOVEit breaches in 2023 were the recent demonstrations of the argument Dan Geer and his co-authors made in 2003, when they called software monoculture a systemic risk. Custom software had almost no eyes on it from either side. Its bugs lived for years, unfound because nobody looked, and its blast radius was one organisation. Obscurity was a real, if shabby, control.

Three things changed.

1. The cost of reading your code collapsed. An attacker with access to a repository, a leaked build or simply the JavaScript your customer portal ships can have it audited overnight. Obscurity as a control is gone.
2. Widely used software gets swept first. The defensive sweep reaches the popular code first because that is where the leverage is — the Glasswing partners’ operating systems and browsers, the open-source pipelines running AI Cyber Challenge systems. Per line, standard software is better reviewed than it has ever been.
3. Correlation did not change. When a widely deployed component fails, everyone fails together. The CrowdStrike update of July 2024 was not an attack, and it still took an estimated 8.5 million Windows machines down within hours. DORA calls this concentration risk and asks financial entities to manage it; the dependence of most AI systems on a handful of model providers is the same risk one layer up.

So the question is badly posed. Neither custom nor standard is safe or unsafe as such. Safety is a function of two things — who looks at the code first, and how many organisations fail together when a bug is found — and frontier models moved every point on that map. Standard software moved right: more defensive attention than ever, the same correlation. Custom software split. Unaudited custom code moved left, because the attacker can now look and you still are not. Audited custom code moved right, and it sits in the safest quadrant there is: looked at first by you, and failing alone if it fails.

Four rules follow.

• Standardise where hardening compounds. Cryptography, authentication, transport security, operating systems, browsers, mainstream frameworks. Never build your own cryptography; that advice has not aged.
• Diversify where correlation hurts. Identity providers, endpoint agents, cloud regions, model providers — the components whose simultaneous failure would be an existential event. Not everywhere, which would be unmanageable; there, deliberately, with the exit tested.
• Audit what only you would ever audit. The custom layer, with the same class of tools attackers now have, in your jurisdiction, on a cadence. Start with authentication, payments, data export and everything an agent can call.
• Watch the new long tail. Internal tools built in an afternoon with a coding assistant are custom software with no review, no threat model and often no owner. They are the new soft underbelly, and there are more of them every month. Whether your organisation is safer for building its own now depends on whether it audits its own — nothing else.

What this means for a European organisation in 2026

The regulators’ clocks are being set to the attacker’s. From 11 September 2026 the Cyber Resilience Act obliges manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents — an early warning within twenty-four hours, a notification within seventy-two, a final report once a fix is available — through a single EU reporting platform, for products already on the market. NIS2 and DORA already expect tested resilience and managed concentration risk. None of that is achievable by an organisation whose patch cycle is thirty days and whose incident process starts with a meeting.

The programme that follows from this article is short, and every item is measurable.

1. Know what you run. An inventory and a software bill of materials for everything exposed, generated from reality rather than from a spreadsheet.
2. Patch exposed systems in hours. Automate, canary, roll. If change management needs a week, change the change management, not the deadline.
3. Audit your own code with frontier models — authentication, payment, export paths and agent tools first — under the conditions of a penetration test, and handle the findings as incidents.
4. Give agents designed limits. Least-privilege tools, human confirmation for consequential actions, retrieved content treated as untrusted.
5. Design the human layer. Verification through known channels, explicit ownership, one-click reporting — and measure verification rate and reporting time, not click rate.
6. Exercise the pipeline. Detection to classification to a twenty-four-hour report, as a game day, before the day it is real.

Attention is now bought, not grown. For every system you run, someone will be the first to look at it with a frontier model. The whole question of the next few years is whether that someone is you.