Google detalha agente PageBreak que já achou mais de 500 falhas XSS

Em paper publicado nesta semana, o Google descreve o PageBreak, agente baseado em Gemini que só reporta uma vulnerabilidade depois de reproduzi-la com um exploit real contra o sistema rodando.

O Google publicou nesta semana um paper detalhando o PageBreak, um agente de segurança baseado em modelos Gemini que investiga vulnerabilidades de forma autônoma nas aplicações web da empresa. Desde que entrou em operação plena em janeiro de 2026, o sistema já encontrou mais de 500 falhas de XSS (cross-site scripting) em produção, segundo a InfoQ, que teve acesso ao material.

O número chama atenção, mas o detalhe técnico que importa para quem trabalha com AppSec está em outro lugar: o PageBreak só reporta uma vulnerabilidade depois que um validador determinístico reproduz o exploit contra um ambiente rodando de verdade. Não é uma IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → apontando padrões de código suspeitos e torcendo para o time de produto confirmar. É um pipeline que exige prova de execução antes de qualquer alerta.

Como funciona a validação determinística

O fluxo descrito pelo Google segue uma lógica de hipótese e verificação. O modelo Gemini analisa o código e levanta hipóteses de falha, mas cada hipótese só vira um relatório se passar por um teste concreto contra o ambiente em execução. Os exemplos citados no paper são específicos: executar JavaScript↳JavaScript116 conteúdosJavaScript em 2020: O que esperarDev (Back & Front) · jan 2020Campos públicos e privados em classes JavaScript – O que vem por aí no ESNextDev (Back & Front) · abr 201929 anos de JavaScript!Dev (Back & Front) · jan 2025Ver tudo em Dev (Back & Front) → de fato para confirmar um XSS, escrever em um local de leitura pública para provar path traversal, ou disparar uma resolução DNS de saída para validar um RCE (execução remota de código).

Michał Bentkowski, engenheiro de segurança da informação↳Segurança171 conteúdosCibersegurança no Brasil: 6 passos para sair da estagnaçãoDevSecOps · jul 2025O papel do CISO para transformar a cibersegurança em uma alavanca de reputação para as empresasDevSecOps · mar 2024Itaipu Parquetec e Exército Brasileiro realizam exercício de cibersegurança em BrasíliaDev (Back & Front) · set 2025Ver tudo em DevSecOps → no Google, explica a decisão de design:

Desde o início do desenvolvimento do PageBreak, tomamos a decisão consciente de priorizar a validação determinística. Em vez de simplesmente levantar hipóteses de bugs com base em padrões de código, o sistema fecha o ciclo verificando as falhas potenciais contra ambientes em execução. Essa abordagem resulta em uma taxa de falsos positivos próxima de zero, garantindo que não sobrecarregamos os times de produto com relatórios de vulnerabilidade não verificados.

Michał Bentkowski, engenheiro de segurança da informação no GoogleEarly 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.

Esse é o ponto que separa o PageBreak de boa parte das ferramentas de "IA para achar bugs" que circulam no mercado: a validação não é feita pelo próprio modelo. Lukas Weichselbaum, engenheiro sênior staff de segurança da informação no Google, reforçou isso em publicação no LinkedIn:

Muitos relatórios de bugs gerados por IA soam convincentes, mas acabam estando errados, e os times que os recebem perdem tempo checando cada um deles. No PageBreak, o modelo pode sugerir o que quiser, mas uma descoberta só conta depois que um validador a confirma com um payload real. Os validadores são código comum escrito por engenheiros de segurança, não pelo modelo, e vivem fora do loop do agente.

Lukas Weichselbaum, engenheiro sênior staff de segurança da informação no GoogleA 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.

O que o Google faz com os achados não confirmados

Nem toda hipótese levantada pelo Gemini vira um relatório para os times de produto, mas isso não significa que ela é descartada. O Google mantém internamente os achados não determinísticos, aqueles que o modelo sugeriu mas o validador não conseguiu confirmar com exploit real, para três usos: alimentar buscas futuras mais profundas, identificar lacunas na cobertura dos validadores atuais e guiar o desenvolvimento de novos validadores.

Bentkowski reconhece o trade-off dessa escolha:

Embora a validação determinística seja nosso padrão-ouro, sabemos que nossos validadores atualmente carecem de capacidade para cobrir todos os tipos de vulnerabilidade ou cenários complexos. Isso traz o risco de falsos negativos que, de outra forma, poderiam ter sido capturados por validadores não determinísticos.

Michał Bentkowski, engenheiro de segurança da informação no GoogleWhile 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.

Em outras palavras: o sistema é conservador por escolha. Prefere deixar algumas falhas passarem a inundar os times de produto com alertas que exigem investigação manual, o problema clássico de fadiga de alerta que qualquer time de AppSec conhece bem.

Três casos reais, fora do abstrato

Num artigo separado publicado no portal Google Bug Hunters, intitulado "Google's PageBreak Project, Real-World Findings" (citado pela InfoQ), Bentkowski descreve três casos técnicos concretos encontrados pelo agente: uma vulnerabilidade de XSS, um problema de cache poisoning causado por uma má configuração de serviço, e uma falha de path traversal. São categorias clássicas de AppSec, o que sugere que o diferencial do PageBreak está menos em achar bugs inéditos e mais em escalar a investigação desses padrões conhecidos com confiabilidade alta.

O que muda para quem faz AppSec fora do Google

Aqui está o ponto que mais interessa a quem trabalha com segurança de aplicações no Brasil: o PageBreak não é um produto que vai aparecer no pip install ou no marketplace de alguma nuvem amanhã. Bentkowski é direto ao listar as dependências de infraestrutura que tornam o sistema viável: visibilidade de código ponta a ponta no monorepo do Google, sinais de segurança que conectam tráfego HTTP ao vivo com o código-fonte, e uma infraestrutura de scanning já existente com acesso autenticado às aplicações web da empresa.

Isso significa que replicar o PageBreak exatamente como está fora do Google é inviável para a imensa maioria dos times. Mas o padrão de arquitetura por trás dele é replicável em escala menor:

• Separar geração de hipótese e validação: deixe o LLM sugerir, mas exija prova de execução antes de abrir um ticket;
• Validadores como código comum, escritos e mantidos por humanos, fora do loop do agente, nunca gerados pelo próprio modelo;
• Reter os falsos negativos, em vez de descartá-los, para evoluir a cobertura dos validadores ao longo do tempo.

Para squads de segurança menores, a lição prática é usar esse princípio de validação determinística em scanners próprios integrados a ferramentas como OWASP ZAP ou Burp Suite, mesmo sem a escala de dados do Google. O ganho real não é achar mais bugs: é parar de queimar a credibilidade da IA com falsos positivos.

O que ainda fica em aberto

A InfoQ destaca um ponto importante: não há validação independente dos mais de 500 achados anunciados pelo Google. Os números vêm do próprio paper da empresa, sem auditoria externa publicada até o momento.

O Google já sinaliza o próximo passo: integrar o PageBreak a outras iniciativas agênticas de segurança, como o CodeMender, para gerar automaticamente correções para as vulnerabilidades descobertas. A meta declarada é reduzir a participação dos times de produto a apenas validar as correções geradas por IA, não mais investigar os bugs. Se esse objetivo se concretiza com a mesma taxa de confiabilidade do pipeline de detecção é algo que ainda não tem resposta pública.

Fonte: InfoQ