Agentic Hacks, Real Proofs: Inside Google's PageBreak Project

Security landscape in 2026

The application of Large Language Models (LLMs) to security scanning has revolutionized the vulnerability management landscape. But, it has also introduced a significant operational bottleneck: noise. Despite advancements in the models' capabilities to identify vulnerabilities, many security teams are finding themselves overwhelmed as a significant portion of the candidate reports they receive is "AI slop" – noisy, unverified hypotheses or false positives generated by LLMs acting as static code analyzers.

Distinguishing a genuine, exploitable flaw from a convincing hallucination has become a major challenge, often increasing the burden on product teams, rather than reducing it.

PageBreak is an internal AI agent of Google's Product Security team developed to test the security of our first-party web applications and address this challenge. Starting as a pilot in November 2025 and moving to a fully-fledged project in January 2026, its mission is to autonomously scale vulnerability discovery while minimizing manual toil.

While PageBreak is flexible and can work with different models, a vast majority of our usage is based on Gemini models, such as Gemini 3.1 Pro or Gemini 3.5 Flash.

Early on in the development of PageBreak, we made a conscious decision to prioritize deterministic validation. Rather than simply hypothesizing bugs based on code patterns, the system closes the loop by verifying potential flaws against running environments. This approach results in a near-zero false positive rate, ensuring that we avoid overloading product teams with unverified vulnerability reports. Proceeding this way has proved to be highly successful: we have run PageBreak on a massive scale and it uncovered over 500 Cross-Site Scripting (XSS) vulnerabilities across Google first-party web applications (even on sensitive domains).

How Agent Validators Work

The core of this deterministic approach lies in its suite of specialized, non-AI-written validators. When the agent identifies a potential flaw, it passes the hypothesis to a validator which then executes a real payload to confirm the exploit.

The validation logic and interface vary based on the vulnerability class and the application surface (such as HTTP or gRPC). Here are some examples of validators for different types of vulnerabilities:

• XSS: Injects a specific JavaScript payload and invokes a rendering harness or scanning infrastructure to load the URL and monitor the execution context to detect if the injected JavaScript actually runs.
• SQL Injection: Verifies if database queries can be manipulated by injecting payloads and verifying the output and/or timing.
• Path Traversal: Creates a new file in a world-readable location and checks if it can read the file in the application.
• Remote Code Execution (RCE): Attempts to confirm code execution by trying different techniques, such as introducing a sleep delay, writing a file in a world-writable location and verifying its creation, or triggering outbound DNS/HTTP requests.
• Server-Side Request Forgery (SSRF): Detects internal backend requests triggered by the application and checks if an outbound request to an internal service has been made.

Internal Feedback Loop: Non-Deterministic Findings

While deterministic validation is our gold standard, we are aware that our validators are currently lacking in capabilities to cover all vulnerability types or complex scenarios. This comes with the risk of false negatives that might have otherwise been caught by non-deterministic validators. Therefore we complement deterministic validation with non-deterministic findings because doing so has the following benefits:

• Seeding future runs: Non-deterministic findings act as seeds for deeper inspection in subsequent scans.
• Validator development: Non-deterministic findings highlight where our automated validators fall short, guiding the development of new validation tools.
• Missing capabilities: We let the PageBreak agent report what capabilities or environment access it is missing in order to validate a report. This feedback guides our future improvements.

Crucially, we do not send these unverified candidates to product teams, preserving their focus for high-confidence alerts.

PageBreak vs a High-Assurance Framework

In 2025 we published the Secure by Design: Google's Blueprint for a High-Assurance Web Framework blog post where we detailed our approach to building and deploying a high-assurance web framework that systematically eliminates exploitable web vulnerabilities by default.

When put to the test against PageBreak, applications built on our high-assurance web frameworks withstood the agentic attacker remarkably well. As of September 4, 2026, the scanner identified only 2 XSS vulnerabilities across hundreds of web applications built on these frameworks and those were limited to internal applications or debug endpoints with hardening gaps. This real-world validation underlines the immense value of a safe-by-design framework-based approach to building secure software.

The present and the future

Projects such as PageBreak demonstrate that LLMs are increasingly adept at identifying complex vulnerability chains. While pure code scanners can infer intricate code flows, they remain prone to hallucinations and incorrect assumptions. Consequently, providing specialized tooling for agents remains a critical differentiator. Even with such tooling, models can still deviate into unproductive paths; this is why we execute agents with identical seeds across numerous iterations, maximizing the probability of discovering the correct exploit trajectory.

While some solutions for improving agents are applicable industry-wide, several factors within Google’s engineering culture provide PageBreak with unique advantages. For instance:

• Google Mono-Repo – By having billions of lines of code within a single repository, Google allows an agent to follow complete execution paths end-to-end without ever having to consult external resources. This also includes configurations for various services run by Google; see the cache poisoning example in our companion post for an example of XSS caused by a service misconfiguration.
• Security Signals – By leveraging security-relevant data extracted directly from live HTTP traffic, the agent can map HTTP paths to specific lines of source code, enabling it to discover and explore expanded attack surfaces.
• Existing scanning infrastructure – PageBreak repurposes Google's established suite of web application scanners to execute targeted security checks. For example, by leveraging an existing scanner that’s been built out over many years, which is capable of authentication to nearly every Google web application, PageBreak can discover and evaluate vulnerabilities across Google’s internal sites that would otherwise be difficult to scan or would even be inaccessible to most security engineers.

Although PageBreak aims to restrict reported findings to high-confidence, verified vulnerabilities only, product teams continue to face an unprecedented volume of reports. To address this challenge, PageBreak is collaborating directly with other agentic initiatives (including CodeMender) across Google which are responsible for generating automated bug fixes. Looking ahead, we plan to deepen this integration so that product team involvement is ultimately reduced to simply validating proposed fixes. By turning LLMs into highly validated, self-correcting allies, projects like PageBreak are paving the way for a future where autonomous defense scales faster than the vulnerabilities they seek to find.

Further reading

While this post covers the architecture and philosophy behind our agentic scanner, we've also published a deep dive into the actual vulnerabilities it has found. If you are interested in the technical details of these exploits (including how PageBreak successfully discovered a complex cache poisoning flaw and bypassed cryptographic protections entirely on its own), head over to our companion post on the Google Bug Hunters blog.