AI Now Finds Bugs Faster Than Anyone Can Fix Them. That Is the Real Crisis.

Google disclosed something this month that should have made more people uncomfortable. Its internal AI agent, PageBreak, has identified and verified more than 500 cross-site scripting vulnerabilities across Google's own first-party web applications, including sensitive domains. Not hypothesized. Verified, with working exploit proofs.

Here is what makes the disclosure unsettling rather than reassuring. In the same weeks Google has been celebrating its bug-finding machines, the GrapheneOS project has warned that Google is now, quote, completely overwhelmed by the volume of vulnerabilities being discovered by AI models, both internally and externally, and that the flood is affecting how Android security fixes are handled and backported. Finding the bugs was supposed to be the hard part. It turns out the hard part was what comes after.

The credibility problem, solved the right way

For the last year, LLM-based security tools have had a credibility problem. Generative models are excellent at constructing convincing vulnerability narratives while being wrong about application state, sanitization, authorization, reachability, or exploit prerequisites. Security teams have been drowning in plausible but unverified bug reports, which one of Google's own engineers described as AI slop. Each report demands human investigation, which means the tool that was supposed to reduce work was manufacturing it.

PageBreak's design decision is the answer, and it is worth stating plainly because the whole industry should copy it. The AI proposes an attack path; a separate, non-AI validator attempts to actually execute the exploit against a running application. Only vulnerabilities supported by a successful proof get escalated to product teams. Unconfirmed findings stay internal, where they can seed future scans or expose coverage gaps in the validators themselves. Google says this yields a near-zero false-positive rate, and the mechanism is the message: evidence-driven validation, not model output, is what makes a finding real.

The AI proposes an attack path; a separate validator attempts to actually execute it. Evidence, not model output, is what makes a finding real.

What 500 verified flaws actually tell us

The number is less important than the distribution. PageBreak also serves as a large-scale test of Google's high-assurance web frameworks, and as of September 4, it found only two XSS issues across hundreds of applications built on those frameworks, both confined to internal apps or debug endpoints. Secure defaults work. Contextual auto-escaping, strict Content Security Policy, Trusted Types, compile-time controls against unsafe patterns: the boring engineering discipline of secure-by-default frameworks beat the AI at its own game.

That is the optimistic half of the story, and it deserves more attention than it gets. The pessimistic half is everything else Google's estate. Five hundred verified flaws in the non-hardened apps. Real chained attacks too, including cache poisoning on a Google APIs domain and a bypass of a cryptographic-signature control on an admin endpoint. Google says it found no evidence of wild exploitation, but that is a statement about detection, not a guarantee about the past.

The flood is the threat model now

Zoom out and the asymmetry becomes the story. Attackers need one working exploit. Defenders need to find, triage, prioritize, patch, test, and ship fixes for all of them, on every affected product, across every supported version. AI has just collapsed the cost of discovery, for both sides. The same agent that proves a flaw is real can be run by anyone with a motive and a scanner, and bug-finding models do not require Google's monorepo to be effective against everyone else's software.

This is why the GrapheneOS warning matters more than the PageBreak milestone. The bottleneck has moved from finding bugs to adjudicating them: which ones are real, which ones matter, which ones get fixed first, and who writes the patch. Google's own next step points at the answer. The company is connecting PageBreak to CodeMender, an agentic initiative meant to generate proposed fixes for human review. Find, verify, fix: the full loop, automated.

The uncomfortable takeaway

There is a temptation to read this as a Google success story, and partly it is. But strip away the branding and the dynamic is stark. We spent decades building security processes around the assumption that finding vulnerabilities is expensive and rare. Every SLA, every triage queue, every patch-Tuesday cadence assumes a trickle. That assumption is now dead. The vulnerability supply is effectively infinite, and the organizations that survive this transition are the ones that automate the entire loop, discovery through remediation, not just the flashy first step.

The uncomfortable truth is that most organizations cannot do what Google did. PageBreak benefits from Google's monorepo, live traffic signals, and mature scanning infrastructure, advantages no ordinary company has. The open question of the next few years is whether evidence-driven, exploit-verified scanning becomes a commodity available to everyone, or whether it remains a capability of a few giants while everyone else faces an infinite attacker-side bug supply with 1990s-era triage processes. Google fixed its credibility problem. The remediation problem belongs to all of us.