Chrome security has quietly crossed a line. In a post published on 30 July, Google’s Chrome Security Team says large language models are now generating the candidate fix “for most vulnerabilities” in the browser — and the numbers behind that claim are startling. Chrome 149 and Chrome 150 between them fixed 1,072 security bugs, which Google says surpasses “the total number of security bugs fixed across the prior 23 milestones combined.”
That matters on Android specifically, because Chrome is the browser almost every Android phone ships with and the engine behind a great deal of in-app content. Whatever changes about how Chrome gets patched changes the security posture of the phone in your pocket.
How AI moved through the Chrome security pipeline
Google describes automation at every stage, not just one. An agent harness built on Gemini in early 2026 hunts for vulnerabilities across the codebase; Google says one find was a sandbox escape that “quietly survived in our codebase for more than 13 years.” Triage — historically 5 to 30-plus minutes of human work per report — now runs through a blended rule-based and AI pipeline that filters spam, reproduces the bug, attaches severity metadata and routes it to an owner. Google estimates this alone saves “hundreds of hours of developer time per month.”
The fix stage uses a multi-agent loop: a fixing agent proposes several candidate patches, a critic agent picks the best one, and test-writing agents produce the tests, before a human developer reviews. Google also says its Big Sleep and CodeMender tooling runs across every changelist every 24 hours, and that in May alone it “blocked over 20 vulnerabilities from reaching production.”
The part Google is not quantifying
Here is the fair, uncomfortable question. Google has published an impressive count of bugs found and fixed, and no figure at all for how often a machine-written patch was wrong, incomplete or introduced a regression. The critic-agent-plus-human-review loop is described, but not measured. For a browser this widely deployed, “we fixed 1,072 bugs” and “we fixed 1,072 bugs correctly” are different claims, and only the first one has a number attached.
There is a second consequence worth naming. Google says that by March it had received more bug reports than in the whole of 2025, and that it therefore changed its Chrome Vulnerability Reward Program “to focus researchers on bug submissions that are additive to what we are finding internally.” Read plainly: as the in-house AI gets better at the routine finds, the pool of paid work for independent security researchers narrows. That may be economically rational for Google. It also thins out the external scrutiny that has historically caught the things vendors miss about their own code.
What changes for you, and what does not
The delivery side is moving too. Google is shifting to a two-week cadence for major Chrome milestones with weekly security updates, and is now piloting two security releases per week to shrink the “patch gap” — the window after a fix lands publicly in open source but before it reaches users, during which attackers can reverse-engineer it.
The restart work is more desktop-flavoured. Google says it is investing in “dynamic patching” that would replace background child processes such as the Renderer and GPU with updated binaries on the fly, removing the need for a full browser restart in most cases; it is explicitly still research, with no ship date. A narrower change already exists in Chrome 150 on macOS, where Chrome auto-restarts to apply a pending update when it is running with no windows open. Neither of these is described for Android.
So the practical advice for Android users is unchanged and unglamorous: let Chrome update from the Play Store promptly, and actually close and reopen it afterwards rather than leaving a weeks-old process alive in the background. If you want the wider picture on Google’s on-device defences, our look at Android’s Advanced Protection changes covers the phone side of the same effort.
