Google says its AI fixed 1,072 Chrome security bugs across two releases - more than the previous 23 milestones combined. It's the kind of figure that turns up in a vendor deck by Friday, quoted as proof that AI security "works." Rex Factor does what the evidence desk is for: he takes the number at full strength, mechanism and all, then asks what it actually counts. The answer is throughput, not safety - a line Google itself draws when it admits that fixing a bug is only half the battle. Respect the work. Price the metric correctly. — Muximus
Start with the number, because it is real and it is large. Google's Chrome Security Team says that across its two most recent milestones, Chrome 149 and 150, it fixed 1,072 security bugs - more than the total fixed across the prior 23 milestones combined. Google is reporting on its own tooling, with a direct interest in the "AI improves security" story, and that interest is worth naming before the figure travels any further. Name it, and the number still stands. What it counts is another matter - and Google, to its credit, is the one who says so.
The work behind the number
Take the claim at full strength first, because it earns it. This is not a model bolted onto one step and relabeled transformation. Google describes AI running the full length of a bug's life: finding, triage, fixing, releasing, and applying the update.
On the finding end, an agent harness built in early 2026 points Gemini at the Chrome codebase, and Google reports it surfaced a sandbox escape that had been sitting in the source for more than 13 years - the kind of flaw that lets a compromised renderer trick the browser into reading local files. That harness builds on Big Sleep, the vulnerability-discovery agent Google developed with DeepMind and Project Zero, which has turned up bugs in the V8 JavaScript engine and the graphics stack. Big Sleep and a fixing agent, CodeMender, run inside continuous integration every 24 hours across all changelists; Google says that in May alone this blocked more than 20 vulnerabilities from reaching production, one of them critical.
By the numbers
- 1,072 security bugs fixed across Chrome 149 and 150 - more than the previous 23 milestones put together.
- One sandbox escape found that had survived 13-plus years in the codebase.
- Triage that once took 5 to 30-plus minutes of human time per report, now largely automated - Google's estimate is hundreds of developer-hours saved a month.
- Candidate fixes for most vulnerabilities now generated by a fixing agent, weighed by a critic agent, and tested by test-writing agents before a human looks.
Google also put fences around the discovery models: they analyze source code at rest on locked-down machines with no general internet access, network requests intercepted, allowlists enforced. This is not a demo reel. It is a shipped pipeline running on the largest open-source project on the planet, with a named agent, a concrete decade-old find, and a headline figure that can be checked against public Chrome release records. By the standards of this column - named org, real outcome, verifiable mechanism - it clears the bar without help.
What "1,072 fixed" is, and what it isn't
Here is where an operator has to slow down. 1,072 is a throughput number. It counts patched issues moving through a pipeline. It does not, by itself, say whether Chrome is more secure than it was, how much risk is left, or how many of those bugs would ever have been reached by an attacker. Throughput going up and risk coming down are two different measurements, and they do not have to move together.
The denominator is the first thing that should give a buyer pause. A more aggressive way of finding bugs lifts both sides of the ledger at once - find more, fix more. And the input side is visibly moving: Google says that by March 2026 it was taking in more external bug reports than in all of 2025, enough that it retooled its Vulnerability Reward Program to push outside researchers toward reports its own tooling wasn't already catching. When the machine generating the count is the thing being scaled up, part of a bigger count is a measurement of the machine, not of the codebase getting healthier.
Then there is the noise. Google lists lower false positives as a goal, not an achievement, and keeps guidance on the books for developers drowning in invalid AI-generated reports. That tells you the invalid-report load is real and being managed - and that the clean "fixed" figure says nothing about how much chaff the pipeline threw off to produce it.
The strongest caveat is the one Google supplies itself. Its post states, flatly, that discovering and fixing a bug is "only half the battle" - the fix still has to ship and reach a user before an attacker reverse-engineers the public patch and walks through the gap. That is why Google is piloting two security releases a week and pouring effort into dynamic patching and well-timed restarts. The security outcome lives in that second half. The bug-fix count does not touch it.
Whether it lands on anyone else
The conditions that produced 1,072 are not lying around for the taking. Google brought Project Zero, DeepMind, a knowledge base seeded with every prior Chrome CVE and the project's entire Git history, and one of the most-scrutinized codebases in existence. The question an operator actually cares about - has anyone done this at scale, and would it work on my code - turns on those inputs, not on the headline. Clearing a decade of latent bugs out of Chromium is evidence about Chromium and about Google's tooling. It is not a promise that aiming a coding agent at a smaller, less-instrumented codebase returns anything proportional.
The read
None of this makes the number fake. It makes it specific, which is the more useful thing. When a vendor says "our AI fixed N bugs," the response is neither applause nor a sneer - it's four questions. What does N count: found, fixed, or shipped-and-applied? What was the false-positive rate behind it? Did net exposure fall by any measure the vendor will actually publish? And who did the measuring - the team selling the tool, or someone with no stake in the answer?
Google's post is unusually willing to answer the first and third, which is exactly why it reads as evidence and not marketing. The operator lesson isn't about Chrome. It's about the next deck that quotes this number back across a table: take the throughput as throughput, respect the work that produced it, and ask where the other half of the battle got measured.
