Google has published details PageBreakan internal I have an agent that hunt for Vulnerability in the company’s own web applications. It turned up more than 500 cross-site scripting errors, some on sensitive domains.
The number that deserves more attention sits further on the post. Across hundreds of applications built on Google’s high-assurance web framework, PageBreak found two XSS bugs. Both were in internal apps or debug endpoints with hardening gaps.
Same scanner, same company, same year. The difference was how the applications were built.
The problem PageBreak was built to solve
Google’s framing of the current state of AI security scanning is unusually blunt for a corporate blog. It calls the issue “AI Sleep”: Noise, unverified hypotheses and false positives from models acting as static code analyzers.
The result is that the security teams are worse. Sorting out a real exploitable bug from a convincing hallucination takes work, and that work lands on product teams who are supposed to get help.
PageBreak started as a pilot in November 2025 and became a full project in January 2026. It mostly runs out Gemini 3.1 Pro and Gemini 3.5 Flashalthough Google says it works with other models as well.
Evidence instead of suspicion
The design choice that makes it work is that PageBreak must prove a bug before you report it.
When the agent thinks it has found something, it passes the hypothesis to a validator, and these validators are conventional software rather than AI. Each runs a real payload against a live environment:
For XSS it injects JavaScript and see a rendering harness to see if the code actually executes. For SQL injection, it manipulates queries and controls the output or timing. For path traversal, it creates a file in a world-readable location and tries to read it through the application. For remote code execution, it tries a sleep delay, writes a file somewhere globally, or triggers an outbound DNS or HTTP request. For SSRF, it looks for internal backend requests that reach services they shouldn’t.
Google reports a near-zero false positive rate from this approach.
There is also a practical behind-the-scenes detail. Models wander in unproductive ways, so Google runs the agent repeatedly with identical seeds, improving the chances that at least one run will find the working exploit.
What Google keeps for itself
PageBreak also generates conclusions its validators can not confirm. They never reach product teams.
Google uses them internally three ways: as seeds for deeper inspection and subsequent scans, as a map of where its validators fall short, and as a record of what access or capability the agent said was missing. The latter is a neat idea, letting the agent submit its own feature requests.
Why is it hard to copy
Google is honest that certain benefits here are specific to how it works.
Its monorepo means that the agent can follow an end-to-end execution path without leaving the codebase, including service configurations. Security signals map live HTTP traffic back to specific lines of source code, allowing the agent to find attack surfaces it wouldn’t otherwise know about. And PageBreak uses a scanning stack Google has been building since at least 2014, including tools that can authenticate to almost any internal Google application.
An organization without a monorepo, without traffic-to-source mapping, and without a decade of scanning infrastructure will not reproduce this by pointing Gemini to a repository.
Where it continues
Even with only verified bugs reaching them, Google says product teams are facing an unprecedented volume of reports. The answer they’re pursuing is to connect PageBreak with CodeMender, its automated patch-generation agent, so that the eventual human worker approves a proposed fix instead of investigating a report.
That is the honest form of the argument. Agent scanning finds more than people can fix, which creates a bottleneck one step further down, and the proposed solution is another agent.
Which brings the two-XSS figure back into focus. Google has proven that AI can find vulnerabilities at scale and prove them. It also proved, in the same post, that building on a framework that excludes these vulnerabilities by default is a significantly cheaper way to not have them.