AI is finding the holes faster

On 4 November OpenAI described a run of AI agents against the Linux kernel, the software that underpins Android phones, cloud infrastructure and supercomputers. Over about ten days from the middle of October, the agents produced working exploits for 948 distinct flaws, each of which could turn an ordinary user account into full control of a machine, and wrote a candidate patch for every one. A week earlier Google announced Gemini 4 Carbon and gave it first to vetted cyber defenders. The time between a flaw existing and someone finding it is shrinking, and the labs want defenders to get there first.

What OpenAI ran

The pipeline had five stages and ran on a cyber model OpenAI released on 5 November as GPT-6 Cyber. Scout agents picked 5'034 parts of the kernel worth auditing, about 7 percent of its code. Analyst agents turned them into 2'308 candidate findings in 12 hours. Triage agents tried to reproduce each one in an isolated machine and succeeded for 1'724, about three quarters, and OpenAI says only 3.1 percent of the findings rested on wrong analysis. Later stages tested which flaws could be exploited and wrote patches, and people reviewed the results before anything was reported.

The run cost 1'213'430 dollars in API credits, or about 1'279 dollars per exploit. The targets ran a stock desktop Linux with its usual protections on. A run in July with an earlier model, GPT-5.6 Sol, had found 166 such flaws. The newer model found more than five times as many, although the kernel had been hardened for three months in between.

What the labs say about limits

OpenAI is candid about where it went wrong. In an early run the pipeline reported 200 successful exploits, and human review found that 20 of them had reached full control through a different unknown flaw than the one they were assigned. “This suggests that even successful exploitation by agents needs proper validation,” OpenAI wrote, and it added an independent check that each exploit used its assigned flaw. Its lesson holds for any automated work: “verify the path to a result in addition to verifying the result itself.”

The patches needed work too. The first ones worked but sometimes added needless code, ignored local conventions or missed variants of the same flaw, until more instructions and iteration improved them. OpenAI calls its cost figures “more an upper bound”. All these numbers are OpenAI’s own. By 5 November we had found no independent audit of them and no public statement from kernel maintainers on this batch.

Defenders first

Google’s announcement on 28 October follows the same pattern. It calls Gemini 4 Carbon “our strongest model with state-of-the-art cybersecurity and long horizon capabilities” and reports 88.2 percent on SEC-bench Pro for finding flaws, 54.8 percent on ExploitGym and 71.0 percent on CWE-bench for patching, all of them Google’s own figures, measured without guardrails. Access starts with a subset of cyber defenders and widens in phases through the Fairwind Program, which SecurityWeek reports has more than 650 participants, among them governments and critical infrastructure operators. A release for developers, businesses and consumers is promised “as soon as possible”, with no date.

Anthropic set this pattern with Mythos in April, and OpenAI follows it. GPT-6 Cyber goes first to a select group of approved customers of Daybreak Red, its programme for authorised security testing, and OpenAI rates the model Critical for cybersecurity under its own Preparedness Framework. Its announcement says why: “It is clear that we have a limited window to use frontier models to secure software.”

The maintainers’ side

Every finding lands with someone who has to fix it. In March Greg Kroah-Hartman, a senior kernel maintainer, told The Register that reports made with AI had switched from junk to genuine about a month earlier: “Now we have real reports.” In May Linus Torvalds wrote that “the continued flood of AI reports has basically made the security list almost entirely unmanageable”, because many people find the same bugs with the same tools. His advice to reporters: “If you found a bug using AI tools, the chances are somebody else found it too.” In July the kernel team published 432 CVEs across a single Sunday and Monday.

While OpenAI’s scan ran, maintainers and other contributors were already fixing many of the same flaws: after ten days, 61 had been patched upstream, 43 had patches waiting and 299 were being discussed in public. OpenAI says it followed the kernel community’s guidance and has so far disclosed 304 critical findings with candidate patches. In our view the scarce resource is now the attention of those who review, test and release fixes.

What a company can do

Most companies simply run the software that receives these fixes, often in large batches. OpenAI draws the conclusion itself: for now, a low privileged account on a system that “isn’t up-to-date on its latest available patches should be considered functionally equivalent to root access for a well-resourced threat actor.” Four things follow, in our view.

Patch faster, and know what you run. Jan Schaumann, Akamai’s chief information security architect, wrote in July that prioritising individual kernel changes is no longer feasible, and told The Register that “Automated, regular, and frequent updates” seem the only reasonable approach, hard as they are for large organisations. That needs a current list of every server, device and service, and of who updates each one.

Choose suppliers who patch quickly, and ask how long a critical fix takes to reach you. Ask your software vendors how they use these models: whether they scan their own code, how they verify what the models report, and whether they take part in programmes such as Daybreak or Fairwind.

Keep sensitive data in systems you control, with access limited by role, so that a flaw in someone else’s service exposes less. Control does not remove the duty to patch, it makes the duty yours. OpenAI also recommends sandboxes and isolation to limit the damage when something is exploited.

Where we stand

We do not build security scanners. Our part is the last point on that list. Twin, which is live, gives a company’s assistants one brain with access by role, every write signed in per user and every step logged, hosted in Switzerland, the EU, the US or on the company’s own hardware. Eigna, in early access and built by our partner Eigna Labs, is a private model that runs in a company’s own cloud or on its own servers and is designed to run offline in closed networks. Like anything else a company runs, both have to be kept current.