Google Says Its AI Security Agent Found More Than 500 Web App Vulnerabilities

PageBreak runs suspected attacks against live applications before alerting product teams. That cuts unverified reports, but may leave some real flaws waiting for a way to confirm them.

By 3 min read
Google Says Its AI Security Agent Found More Than 500 Web App Vulnerabilities
Google Says Its AI Security Agent Found More Than 500 Web App Vulnerabilities

Listen to this story

The audio brief

About 1:39
0:001:39
Read transcript
Google says its internal AI security agent has found more than 500 cross-site scripting flaws in the company’s web apps. The key is that a suspicious code pattern doesn’t automatically become an alert: PageBreak tries to prove the bug on a live application first. For a cross-site scripting flaw, a specialized validator injects JavaScript and checks whether it actually runs when the page loads. Other validators test for effects such as altered database-query results or access to files the app should not be able to read. If the tools can’t confirm a suspected flaw, Google keeps it as a lead rather than sending it to product teams. That evidence gate, Google says, gives sent reports a near-zero false-positive rate. But it creates a limit too: a real vulnerability can remain unreported if a validator can’t reproduce it. PageBreak began as a pilot in November 2025 and became a full project in January 2026. Google says it relies mostly on Gemini, and uses existing traffic and code-repository signals to investigate complex applications. As of September 4, it had found two cross-site scripting flaws across hundreds of apps built on Google’s high-assurance frameworks—both in internal apps or debug endpoints with hardening gaps. Even verified reports leave teams with a substantial repair workload. Google is connecting PageBreak with CodeMender, which generates fixes, but has not said these findings are already repaired. The test ahead is whether validators can cover more edge cases while turning confirmed alerts into repairs teams can simply check.

Story brief

3 key points

Google says its internal PageBreak project has logged more than 500 XSS vulnerabilities across first-party web apps, but its defining choice is a strict evidence gate: specialized validators execute attacks against live apps before findings reach product teams. The project moved from a November 2025 pilot to full status in January 2026 and relies mostly on Gemini. Verified reports still create substantial...

  1. 01

    For XSS, a validator injects JavaScript and checks whether it runs; other validators test database-query effects and unauthorized file reads.

  2. 02

    As of September 4, PageBreak found two XSS vulnerabilities across hundreds of apps built on Google’s high-assurance web frameworks.

  3. 03

    Google reports a near-zero false-positive rate for sent findings, but acknowledges validators can miss real flaws they cannot test.

An AI-generated warning is not enough to get a vulnerability report onto a Google product team’s desk. In a September 24 account of its internal PageBreak project, Google said the agent has found more than 500 cross-site scripting flaws in its web applications. Its distinguishing step is to run suspected attacks against working applications and check whether they succeed.

From pilot to proof

Google’s Product Security team built PageBreak to test the company’s own web applications. It began as a pilot in November 2025 and became a full project in January 2026. Google says most of its PageBreak usage relies on Gemini models, though the agent can work with different models.

The team designed it around a familiar bottleneck: a plausible AI-generated bug report can still be wrong. Google says PageBreak passes a suspected flaw to a specialized validator, which tries a real attack payload against the running application. The validator’s job is not to offer another opinion about the code. It checks for an observable result.

What a validator actually checks

For cross-site scripting, or XSS, the validator injects JavaScript and checks whether it runs when the page loads. Other validators look for evidence that an injected database query changed a result or its timing, or that an application could read a file outside its intended path. Google says the validators are specialized tools, not code written by the AI agent.

That proof requirement controls who receives a report. PageBreak keeps findings it cannot verify as leads for later scans and for improving its validators, but does not send those candidates to product teams. Google says this approach produces a near-zero false-positive rate for the findings it does send. It also acknowledges the other side of the tradeoff: a validator that cannot handle a complex case may miss a real flaw.

Google’s reported finding
More than 500Cross-site scripting vulnerabilities

Google says PageBreak uncovered more than 500 XSS vulnerabilities across its first-party web applications.

Where the findings landed

PageBreak’s reach depends partly on Google’s existing security infrastructure. Google says the agent can use live web-traffic signals to connect web paths to source code, then use established scanners to test applications that require authentication. Its shared code repository also lets the agent trace how different services interact. Those advantages matter when a suspected weakness depends on more than one piece of an application.

Google also tested applications built on its high-assurance web frameworks, which are designed to prevent exploitable web flaws by default. As of September 4, PageBreak had identified two XSS vulnerabilities across hundreds of those applications. Google says both were confined to internal applications or debug endpoints with hardening gaps. That is a result for the applications tested, not a like-for-like vulnerability rate against all the other sites PageBreak scanned.

The next handoff is a fix

Verification has not eliminated the workload. Google says product teams still face an unprecedented volume of reports, even with PageBreak filtering for high-confidence findings. The project is working with other internal AI efforts, including CodeMender, that generate automated bug fixes. Google plans to deepen that connection so teams would spend less time handling reports and primarily validate proposed repairs.

For now, PageBreak’s published result is a discovery count, not a count of completed fixes. The next test of the workflow is whether its verified alerts can become repairs that product teams can check without inheriting another large queue. Expanding validation coverage matters too: Google’s own account leaves open how many useful leads remain unconfirmed because its tools cannot yet test them.

Sources

  1. blog.googleAgentic Hacks, Real Proofs: Inside Google's PageBreak Project

Loading discussion...

YOUR READING SPACE

Notifications