Agente de IA PageBreak do Google achou mais de 500 falhas XSS nos próprios apps

O Google divulgou detalhes do PageBreak, um agente de IA interno que procura falhas de segurança nas aplicações web da própria empresa. Usado em grande escala, ele descobriu mais de 500 vulnerabilidades de cross-site scripting (XSS) nas aplicações web próprias do Google, algumas em domínios sensíveis, escreve o engenheiro de segurança do Google Michał Bentkowski no blog da empresa; o iThome traz os mesmos números.

Cross-site scripting é um tipo de vulnerabilidade em que um atacante consegue injetar código JavaScript em uma página web vista por outro usuário, o que pode permitir que ele aja na sessão da vítima. É uma das falhas mais comuns em aplicações web.

O problema que o PageBreak quer resolver: o ruído da IA

Usar grandes modelos de linguagem para analisar código mudou a gestão de vulnerabilidades, mas também gerou ruído, explica o Google. Muitas equipes de segurança estão sobrecarregadas porque boa parte dos relatos que recebem são hipóteses não verificadas ou falsos positivos produzidos por modelos que funcionam como analisadores estáticos de código, o que a empresa chama de AI slop. Distinguir uma falha real e explorável de uma alucinação convincente virou um grande desafio, que muitas vezes aumenta a carga das equipes de produto.

O PageBreak começou como piloto em novembro de 2025 e virou um projeto completo em janeiro de 2026. Ele pode trabalhar com diferentes modelos, mas a maior parte do uso se baseia em modelos Gemini, como o Gemini 3.1 Pro e o Gemini 3.5 Flash, segundo o Google.

Como funcionam os validadores

A escolha central de projeto é a validação determinística. Quando o agente identifica uma possível falha, repassa a hipótese a um validador especializado, escrito sem IA, que executa uma carga real contra um ambiente em funcionamento para confirmar a exploração. Candidatos não verificados nunca chegam às equipes de produto. O Google diz que isso resulta em uma taxa de falsos positivos próxima de zero, ponto também destacado pelo iThome.

• XSS: injeta uma carga JavaScript, carrega a URL em um ambiente de renderização e verifica se o código injetado realmente roda.
• Injeção de SQL: verifica se as consultas ao banco de dados podem ser manipuladas, observando a resposta ou o tempo de resposta.
• Path traversal: cria um arquivo em um local legível por todos e verifica se a aplicação consegue lê-lo.
• Execução remota de código: tenta técnicas como um atraso, a gravação de um arquivo ou o disparo de uma requisição DNS ou HTTP de saída.
• Falsificação de requisição do lado do servidor: detecta se a aplicação faz uma requisição a um serviço interno.

O Google reconhece que seus validadores ainda não cobrem todos os tipos de vulnerabilidade nem todos os cenários complexos, o que traz o risco de falhas passarem despercebidas. Por isso, achados não verificados ficam internos: servem de ponto de partida para análises mais profundas nas rodadas seguintes, mostram onde novos validadores são necessários, e o agente informa quais capacidades ou acessos lhe faltaram para confirmar um achado.

Falhas que os humanos não tinham visto

O Google também descreveu três casos de alta gravidade encontrados pelo PageBreak em aplicações que já tinham sido revisadas por seus engenheiros de segurança e por caçadores de bugs externos sem que essas falhas fossem encontradas, relata o iThome. Em um deles, o agente encontrou um XSS em admin.google.com que exigia uma assinatura válida na requisição; depois achou outro endpoint que fazia a aplicação gerar uma assinatura válida para um parâmetro malicioso, o que permitia montar uma URL de exploração que contornava a proteção por assinatura. Segundo o Google, esses casos mostram que os modelos de linguagem estão cada vez mais capazes de achar vulnerabilidades cuja exploração exige várias etapas.

O Google publicou os detalhes técnicos dessas explorações em um texto complementar no blog Bug Hunters. Entre eles está uma falha complexa de envenenamento de cache, causada pela configuração errada de um serviço, e um caso em que o agente contornou sozinho, por completo, proteções criptográficas, segundo a empresa. Esses exemplos importam porque vão além dos padrões simples de injeção que scanners clássicos já detectam.

O agente também se beneficiou de vantagens específicas do Google, diz a empresa: um repositório único de código com bilhões de linhas, sinais de segurança que ligam o tráfego HTTP real a linhas de código-fonte e um scanner já existente capaz de se autenticar em quase todas as aplicações web do Google. Para aumentar as chances, o Google roda os agentes com sementes idênticas em muitas iterações.

O que os frameworks seguros por padrão mudaram

O resultado mais marcante envolve as aplicações construídas sobre os frameworks web de alta garantia do Google, projetados para eliminar por padrão vulnerabilidades web exploráveis. Até 4 de setembro de 2026, o PageBreak tinha encontrado apenas 2 falhas XSS em centenas de aplicações construídas sobre esses frameworks, ambas restritas a aplicações internas ou endpoints de depuração com lacunas de proteção, escreve o Google. Mesmo verificados, os relatos chegam em volume sem precedentes, por isso o PageBreak trabalha com outros agentes, como o CodeMender, que geram correções automáticas, com o objetivo de reduzir o papel das equipes de produto a validar as correções propostas.

O que muda para as empresas brasileiras

Para empresas de software e equipes internas de segurança que já recebem relatos de vulnerabilidades gerados por IA, a abordagem do Google oferece uma regra prática: não agir com base na suspeita de um modelo até que um teste determinístico tenha reproduzido a exploração. O resultado dos frameworks é igualmente útil: a forma mais barata de resistir a atacantes automatizados é construir aplicações web sobre frameworks que bloqueiam por padrão categorias inteiras de falhas, em vez de caçar bugs um a um depois.