Google's Gemini Agent Has Found Over 500 XSS Bugs in Production Since January
Google has published a paper on PageBreak, an autonomous security agent powered by Gemini that has found more than 500 XSS vulnerabilities in the company's production applications since January 2026. What sets the agent apart from classic scanner bots is not what it finds, but what it does not report: no hypothesis becomes a vulnerability report until a deterministic validator has reproduced the actual exploit against a system that is genuinely running. This story is based on iMasters' coverage of the paper, which itself cites InfoQ — no primary source is available.
What's new
According to iMasters, which cites InfoQ — which has had access to the material — Google this week published a paper describing PageBreak, a security agent based on Gemini models that autonomously investigates vulnerabilities in the company's web applications. The system has been in full operation since January 2026, and in that period has found more than 500 XSS (cross-site scripting) flaws in production, according to InfoQ. This is not a concept or a pilot: the agent works against Google's actual production environment, and the findings are claimed to be real, confirmed vulnerabilities in code that is in use.
How the hypothesis-and-proof pipeline works
The architecture is described as a logic of hypothesis and verification. The Gemini model analyzes code and proposes hypotheses about potential bugs. But each hypothesis only becomes a report if it passes a concrete test against a running environment — a deterministic validator, written by humans, must reproduce the exploit.
The paper gives examples of what "proof" means per bug class:
- XSS: execute actual JavaScript to confirm that the script really runs.
- Path traversal: write to a publicly readable location to demonstrate that the path can actually escape the intended directory structure.
- RCE (remote code execution): trigger an outbound DNS lookup to confirm that arbitrary code can actually be executed.
The point of these tests is that they are binary: either something observable and deterministic happened, or it did not. The LLM can be wrong, reason poorly or hallucinate — but it cannot get a hypothesis past a code gate that must physically succeed in exploiting a running system.
Why the design matters: the trust problem
The biggest cost of security scanners for the teams that receive the findings is false positives. A scanner that flags a thousand potential problems, of which a hundred are real, wastes the product team's time and — worse — destroys trust in the scanner. If people stop believing the reports, they stop fixing things.
Michał Bentkowski, an information security engineer at Google, says the team deliberately prioritized deterministic validation from the start of development:
"From the beginning of PageBreak's development, we made the deliberate decision to prioritize deterministic validation. Instead of merely proposing bug hypotheses based on code patterns, the system closes the loop by verifying potential bugs against running environments. This approach yields a near-zero false-positive rate, so we don't overwhelm product teams with unverified vulnerability reports." (as relayed via iMasters)
Note that Bentkowski does not give an exact figure for the false-positive rate — only that it is "near zero." That is a claim from the Google team, relayed by iMasters; independent verification is not available.
What AppSec teams can do without Google's scale
iMasters offers editorial advice on what teams without Google's infrastructure can borrow from the design. This is iMasters' analysis, not Google's recommendations:
- Separate hypothesis generation from validation. Let an LLM propose, but require proof through actual execution before anything is passed along.
- Write the validators as ordinary, deterministic code, outside the agent loop. The validator should not "reason" — it should run a test and say yes or no.
- Retain unverified findings. Hypotheses that could not be confirmed can help expand validator coverage over time.
- Integrate with existing tools such as OWASP ZAP or Burp Suite. You don't need to build the entire infrastructure from scratch to benefit from a hypothesis-and-verification loop.
These points require neither Gemini nor Google's scale — they require a willingness to build test tooling that can prove an exploit rather than guess at one.
Open questions
Several things that would otherwise be interesting to know are not documented in the available material, which currently reaches us only through iMasters' secondary coverage of InfoQ:
- How are the 500+ findings counted? Are they unique vulnerabilities, or different instances of the same bug type? What is their severity?
- Have the bugs been fixed and/or disclosed? It is unclear whether the XSS findings have led to fixes, and whether any of them have been publicly disclosed or handled only internally at Google.
- How does the agent work in detail? A full architecture description, planning, iteration, and the interplay between the LLM and the validator in the verification step are not available in this material.
- When and where was the paper published? iMasters writes that Google published it "this week" (in practice, during the week of 31 October 2026), but the exact date and publication venue are unconfirmed.
Until a primary document from Google or InfoQ is available, the 500-plus figure and the January date should be understood as claims relayed through two links of secondary sources — not as documented figures from Google itself.