How does an AI agent find 500 real vulnerabilities without flooding engineers with false alarms?

The noise problem that prompted PageBreak

Security teams using large language models for code scanning face a growing bottleneck. The models spot patterns that look like bugs, but a large share of those reports turn out to be hallucinations or false positives. Product teams then spend time triaging "AI slop" instead of fixing real flaws.

PageBreak started as a pilot in November 2025 and became a full project in January 2026 with a different goal: close the loop by proving each hypothesis in a live environment. The agent runs on Gemini models, primarily Gemini 3.1 Pro and Gemini 3.5 Flash. Its design choice is simple — deterministic validation first, reporting second. No noise.

How deterministic validation works

When the agent suspects a flaw, it hands the hypothesis to a specialized validator written by engineers, not by the model. Each validator executes a real payload and watches the result.

For cross-site scripting the validator injects a JavaScript payload, loads the URL in a rendering harness, and checks whether the script actually executes. For SQL injection it manipulates queries and measures output or timing differences. Path traversal validators create a file in a world-readable location and attempt to read it back. Remote code execution checks use sleep delays or file writes in world-writable directories. They also trigger outbound DNS and HTTP callbacks. Server-side request forgery validators watch for internal backend requests triggered by the application. These validators are non-AI code, so their verdicts are repeatable. The system does not send unverified candidates to product teams.

What the scanner found in Google's own applications

The system has run at massive scale across first-party web applications, including sensitive domains. It uncovered over 500 cross-site scripting vulnerabilities.

The same scanner was pointed at hundreds of applications built on Google's high-assurance web frameworks — the ones designed to eliminate exploitable web vulnerabilities by default. As of September 4, 2026, only two XSS issues appeared. Both were confined to internal applications or debug endpoints with hardening gaps. The contrast suggests the framework approach works, and the agent serves as an independent stress test.

Why the mono-repo and live traffic give PageBreak an edge

Google stores billions of lines of code in a single repository. An agent can follow complete execution paths end to end without jumping to external resources. Configurations for internal services live in the same tree, so a misconfiguration that leads to cache poisoning and XSS becomes visible to the same scan.

Live traffic signals extracted directly from HTTP requests map request paths to specific source lines, expanding the attack surface the agent can explore. Existing scanning infrastructure, refined over many years, handles authentication for nearly every Google web application. PageBreak repurposes that infrastructure instead of building its own. These advantages are specific to Google's engineering culture; they do not transfer automatically to other organizations.

Where the system still needs help

Deterministic validators cannot yet cover every vulnerability class or complex scenario. The team accepts non-deterministic findings as seeds for deeper inspection in later runs. They also use them as signals for new validator development. A third role: indicators of missing environment access.

Crucially, those unverified leads stay inside the security team. Product teams only see high-confidence, verified reports. Even so, the volume of verified findings remains high. PageBreak is now collaborating with CodeMender, another internal agentic initiative that generates automated fixes. The goal is to reduce product team involvement to validating proposed patches. The companion post on the Google Bug Hunters blog details the technical mechanics of a cache poisoning chain and a cryptographic bypass the agent discovered on its own.