All posts
Security5 min read

The Same AI That Finds Your Bugs Can Find Them First 

AI models good enough to audit code for vulnerabilities don't come in offense-only or defense-only versions. The capability is dual-use, and that's changing how fast the security window closes for everyone.

The Same AI That Finds Your Bugs Can Find Them First

When Mozilla let an advanced model loose on Firefox, it surfaced 271 vulnerabilities in a single release cycle, more than ten times what the prior model found on the release before it. The interesting question isn't whether AI can hunt bugs. It's what happens once that same capability sits on the other side of the table, too.

How good are these models at finding vulnerabilities, really?

Mozilla's numbers give a sense of scale. An earlier collaboration using Anthropic's Opus 4.6 found 22 security-sensitive bugs in Firefox 148, 14 of them high severity. The newer Mythos preview found 271 in the following release cycle, against one of the most security-hardened open-source codebases anywhere, with years of fuzzing, sandboxing, and dedicated security teams already built in.

Separately, the UK AI Security Institute ran multiple models through a full simulated break-in (from the first scoping-out steps, through stealing credentials and moving deeper into a network, all the way to full takeover) and measured how far each model got before running out of budget. Mythos preview went furthest, ahead of GPT-5.5, a model the Institute itself said "significantly exceeds the old cyber progress trend." That's not beating a weak field. OpenAI's own evals put GPT-5.5 ahead of Opus 4.7 on a dedicated cybersecurity benchmark, so Mythos was outrunning a model already considered exceptionally strong.

Why the same tool cuts both ways

Traditional security tooling has mostly shipped in separate offensive and defensive flavors, pen-testing suites versus static analyzers, red-team frameworks versus monitoring platforms. A frontier model doing code audits doesn't split that way. The thing that reads a codebase, forms a hypothesis about where it misbehaves, and proves it with a working exploit is the same thing whether the person asking wants a patch or a way in. There's no offense-only license to buy.

That's really because vulnerability research has always been a form of adversarial interpretation, reading code for what it actually permits rather than what the author meant. A model that's good at that is good at it regardless of which side is doing the asking. We'd argue this is the part of the story that gets lost in the "AI beats human researchers" headlines: parity, not superiority, is the more useful frame.

What this does to the security timeline

Cost is the lever here. As it gets cheaper to find a subtle bug, the pool of people who can seriously attempt exploitation grows, not gently, but by a lot, because the skill floor for finding something real drops with it. The same economics that let a small defensive team scan more code and validate more patches also let a much wider set of attackers go hunting. The security window, the gap between a vulnerability existing and someone finding it, is compressing for everyone at once, not just for whichever side adopts first.

Should this change anything this quarter?

The organizations closest to this treated early access as containment rather than a launch: trusted defenders and critical software partners on one side, vetted patch-validation and threat-modeling access on the other. Worth noting, even researchers impressed by the results flagged that judgment is still mixed. Findings can be too literal, relevance can be overstated, and the output still needs real validation infrastructure wrapped around it. This is not a fire-the-security-team moment.

It is a security-team-needs-model-assisted-workflows-now moment, though. We think the bottleneck is shifting away from finding bugs, that part is getting cheap, toward validating exploitability, prioritizing fixes, and coordinating disclosure before someone else's copy of the same capability gets there first.

Traditional toolingAI-native dual-use model
Offense vs. defenseSeparate productsSame model, different operator
Cost to find a subtle bugHigh, specialist-gatedFalling fast
Who benefits from cheaper discoveryMostly defendersWhoever gets there first
Security windowSet by patch cyclesCompressing for everyone at once

A couple of things worth clearing up

Does this mean AI-written code is now safer than human-written code? Not exactly, it means AI is getting sharply better at reading existing code adversarially, which is a different skill from writing it in the first place. The Firefox numbers above are about audits and vulnerability discovery, not authorship.

If defenders get the same access, doesn't that even things out? Partly, but access has been deliberately narrow so far, trusted partners and vetted programs rather than open availability. Broader access, including from open-weight models, is expected within months, which is exactly why the timing question matters now rather than later.

If your codebase touches payments, healthcare, infrastructure, or anything else with real consequences attached, the question worth sitting with isn't really whether to try AI-assisted code review. It's whether you're comfortable being the organization that finds out how good these tools are from the wrong side of an incident report.

More on Security

Want a system like this in your business?

We build the automation behind everything you just read.