NEWS

Google details PageBreak agent that has already found over 500 XSS flaws

In a paper published this week, Google describes PageBreak, a Gemini-based agent that only reports a vulnerability after reproducing it with a real exploit against the running system.

Google details PageBreak agent that has already found over 500 XSS flaws
Image: Redação iMasters
News
Reading
5 min

In a paper published this week, Google describes PageBreak, a Gemini-based agent that only reports a vulnerability after reproducing it with a real exploit against the running system.

Google published a paper this week detailing PageBreak, a security agent based on Gemini models that autonomously investigates vulnerabilities in the company's web applications. Since it went into full operation in January 2026, the system has already found more than 500 cross-site scripting (XSS) flaws in production, according to InfoQ, which had access to the material.

The number draws attention, but the technical detail that matters to those working in AppSec lies elsewhere: PageBreak only reports a vulnerability after a deterministic validator reproduces the exploit against a genuinely running environment. It isn't an AI flagging suspicious code patterns and hoping the product team confirms them. It's a pipeline that requires proof of execution before any alert.

How deterministic validation works

The flow described by Google follows a hypothesis-and-verification logic. The Gemini model analyzes the code and raises hypotheses about flaws, but each hypothesis only becomes a report if it passes a concrete test against the running environment. The examples cited in the paper are specific: actually executing JavaScript to confirm an XSS, writing to a publicly readable location to prove path traversal, or triggering an outbound DNS resolution to validate an RCE (remote code execution).

Michał Bentkowski, information security engineer at Google, explains the design decision:

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.

Michał Bentkowski, information security engineer at Google

This is the point that separates PageBreak from much of the "AI for finding bugs" tooling circulating in the market: validation isn't done by the model itself. Lukas Weichselbaum, senior staff information security engineer at Google, reinforced this in a LinkedIn post:

A lot of AI-generated bug reports sound convincing but turn out to be wrong, and the teams that get them waste time checking each one. In PageBreak, the model can suggest whatever it likes, but a finding only counts once a validator confirms it with a real payload. The validators are plain code written by security engineers, not by the model and live outside the agent loop.

Lukas Weichselbaum, senior staff information security engineer at Google

What Google does with unconfirmed findings

Not every hypothesis raised by Gemini becomes a report for the product teams, but that doesn't mean it's discarded. Google internally keeps the non-deterministic findings, those the model suggested but the validator couldn't confirm with a real exploit, for three uses: feeding future, deeper searches, identifying gaps in the coverage of current validators, and guiding the development of new validators.

Bentkowski acknowledges the trade-off of this choice:

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.

Michał Bentkowski, information security engineer at Google

In other words: the system is conservative by choice. It prefers to let some flaws slip through rather than flood product teams with alerts that require manual investigation, the classic alert fatigue problem that any AppSec team knows well.

Three real cases, out of the abstract

In a separate article published on the Google Bug Hunters portal, titled "Google's PageBreak Project, Real-World Findings" (cited by InfoQ), Bentkowski describes three concrete technical cases found by the agent: an XSS vulnerability, a cache poisoning issue caused by a service misconfiguration, and a path traversal flaw. These are classic AppSec categories, which suggests that PageBreak's differentiator lies less in finding novel bugs and more in scaling the investigation of these known patterns with high reliability.

What changes for those doing AppSec outside Google

Here's the point that matters most to those working in application security in Brazil: PageBreak isn't a product that will show up in pip install or some cloud marketplace tomorrow. Bentkowski is direct in listing the infrastructure dependencies that make the system viable: end-to-end code visibility in Google's monorepo, security signals that connect live HTTP traffic with source code, and an already-existing scanning infrastructure with authenticated access to the company's web applications.

This means replicating PageBreak exactly as it is outside Google is unfeasible for the vast majority of teams. But the architectural pattern behind it is replicable at a smaller scale:

  • Separate hypothesis generation from validation: let the LLM suggest, but require proof of execution before opening a ticket;
  • Validators as plain code, written and maintained by humans, outside the agent loop, never generated by the model itself;
  • Retain false negatives, instead of discarding them, to evolve validator coverage over time.

For smaller security squads, the practical lesson is to use this deterministic validation principle in in-house scanners integrated with tools like OWASP ZAP or Burp Suite, even without Google's data scale. The real gain isn't finding more bugs: it's stopping the practice of burning AI's credibility with false positives.

What remains open

InfoQ highlights an important point: there's no independent validation of the more than 500 findings announced by Google. The numbers come from the company's own paper, with no external audit published so far.

Google is already signaling the next step: integrating PageBreak with other agentic security initiatives, such as CodeMender, to automatically generate fixes for discovered vulnerabilities. The stated goal is to reduce product teams' role to merely validating AI-generated fixes, no longer investigating the bugs. Whether that goal materializes with the same reliability rate as the detection pipeline is something that doesn't yet have a public answer.

Translated from the Brazilian Portuguese original · Read the original

Read also
Dev (Back & Front)

Mistral Large 4 (Le Chonk) becomes a 1-trillion-parameter open model

Mistral AI released the weights of Large 4, codenamed Le Chonk, a multimodal model with 1 trillion parameters that leads open code benchmarks, with a high refusal rate for malicious security requests. For those looking to escape closed APIs, the announcement comes with important caveats about infrastructure and licensing.

Redação iMasters··1 min