Google afirma que un agente de inteligencia artificial interno ha identificado más de 500 vulnerabilidades de scripting entre sitios (XSS) en aplicaciones web propias de la compañía.
El sistema, llamado PageBreak, combina hipótesis de seguridad generadas por IA con validadores independientes que intentan ejecutar cargas útiles contra aplicaciones en funcionamiento. Google presenta esta fase de validación como el mecanismo que evita que una respuesta verosímil de la IA se confunda con una vulnerabilidad explotable.
La cifra comunicada es considerable, pero conviene precisar su alcance. Se refiere a hallazgos, no a usuarios afectados, y la información disponible no permite concluir que se hayan corregido todos los fallos. Tampoco incluye identificadores CVE, puntuaciones CVSS, pruebas de explotación maliciosa ni indicios confirmados de impacto en clientes de Google.
PageBreak pasó de ser un proyecto piloto a un producto interno
PageBreak fue desarrollado por el equipo de Seguridad de Productos de Google para evaluar las aplicaciones web y las extensiones de navegador de la compañía. Michał Bentkowski, ingeniero de seguridad de la información, afirmó que el sistema encontró más de 500 vulnerabilidades XSS.
Según el informe que describe PageBreak y sus resultados, el proyecto comenzó como una prueba piloto en noviembre pasado y se convirtió en un producto completo en enero. La fuente no especifica los años de esos dos hitos. Google habló del sistema en una publicación del blog de la compañía el mes pasado.
Estas referencias corresponden a hitos de desarrollo y comunicación, no a las fechas en que se introdujeron, descubrieron o corrigieron las vulnerabilidades concretas. Tampoco hay una fecha única para un incidente: PageBreak es un sistema de pruebas de seguridad, no una brecha comunicada.
Entre los ejemplos públicos de Google figuran tres hallazgos distintos:
- Una vulnerabilidad de envenenamiento de caché que afectaba a
apis.google.com - Una vulnerabilidad XSS en
admin.google.com - Handshakes externos inseguros en extensiones de navegador
Según se informó, la publicación complementaria de Google indicaba que esos tres problemas ya se habían corregido. Esto no permite determinar el estado de corrección del conjunto más amplio de hallazgos, incluidos los más de 500 problemas XSS atribuidos a PageBreak.
La información publicada tampoco identifica a organizaciones externas afectadas por los fallos. El alcance declarado de las pruebas se limita a propiedades propias de Google y a sus extensiones de navegador.
La IA propone vulnerabilidades, pero otro código debe demostrar que existen
La arquitectura de PageBreak busca abordar una limitación habitual de las pruebas de seguridad asistidas por IA: un modelo puede ofrecer una explicación técnicamente convincente sin identificar una vulnerabilidad que realmente pueda explotarse.
Según el proceso descrito por Bentkowski, el agente examina primero una aplicación y genera una hipótesis de vulnerabilidad. Después, envía ese posible hallazgo a un validador especializado. El validador intenta ejecutar una carga útil real contra la aplicación en un entorno activo. PageBreak solo informa del problema si ese intento demuestra que la vulnerabilidad existe.
Según la descripción, los validadores no están escritos por IA. Su lógica y sus interfaces varían en función del tipo de vulnerabilidad y de la superficie de la aplicación que se analiza.
Por ejemplo, las vulnerabilidades XSS, la inyección SQL y la ejecución remota de código requieren métodos de validación distintos. Probar una aplicación HTTP también implica una interfaz diferente de la que se utiliza para evaluar un servicio gRPC. Por eso, PageBreak no recurre a una única instrucción o rutina de validación universal para todos los objetivos.
Esta separación es importante porque el componente de IA no tiene la última palabra sobre sus propios hallazgos. Genera posibles vulnerabilidades, mientras que otro mecanismo debe aportar pruebas de ejecución.
Google describe el sistema como una combinación de descubrimiento autónomo y validación determinista. Bentkowski calificó de «casi nula» su tasa de falsos positivos. Sin embargo, esa cifra sigue siendo una afirmación de la compañía: la información disponible no incluye pruebas independientes de la precisión, la tasa de falsos positivos ni la cobertura de PageBreak.
Los modelos Gemini impulsan la detección, no la verificación final
PageBreak utiliza principalmente Gemini 3.1 Pro y Gemini 3.5 Flash, aunque Google afirma que el sistema puede funcionar con otros modelos.
La distinción entre los modelos y los validadores es fundamental para el diseño. Gemini participa en el proceso de detección, en el que el acceso al código fuente y a herramientas de seguridad puede ayudar al agente a formular posibles rutas de ataque. A continuación, el validador no basado en IA determina si es posible demostrar el hallazgo contra el objetivo en funcionamiento.
Bentkowski afirmó que la IA puede descubrir vulnerabilidades más rápido que los investigadores humanos. También reconoció el coste operativo de distinguir los fallos reales de las alucinaciones que parecen creíbles. Sin una validación eficaz, acelerar la detección puede limitarse a trasladar el trabajo a los equipos de seguridad de producto e ingeniería.
La información disponible no aporta comparativas con investigadores humanos ni con otros escáneres automatizados. Tampoco demuestra de forma independiente el rendimiento de ninguno de los dos modelos Gemini mencionados en este contexto.
Expertos externos respaldan la separación entre detección y demostración
Rickard Carlsson, director ejecutivo de Detectify, describió un problema de capacidad más amplio al que se enfrentan los equipos de seguridad: las herramientas de IA pueden generar más vulnerabilidades sospechosas de las que las personas pueden investigar de forma realista.
Carlsson sostuvo que un agente no debería verificar sus propias conclusiones. A su juicio, un validador independiente debería ejecutar una carga útil real contra la aplicación en funcionamiento antes de aceptar un posible hallazgo. Esta postura coincide con la separación que, según se ha informado, aplica PageBreak entre la detección basada en IA y la validación no basada en IA.
Darin Fredde, director sénior de ingeniería de marketing técnico en Ridge Security, enmarcó este enfoque en una transición hacia pruebas ofensivas continuas, autónomas y basadas en pruebas. Según Fredde, la detección por sí sola no basta: el proceso debería abarcar también la demostración, la corrección y la verificación de que la solución funciona.
Estos comentarios son valoraciones del sector, no una confirmación independiente del rendimiento de PageBreak. Ninguno permite determinar hasta qué punto el agente examinó las aplicaciones de Google, con qué frecuencia pasó por alto vulnerabilidades ni si se corrigieron todos los hallazgos validados.
La corrección automatizada sigue siendo un paso futuro
Google pretende conectar PageBreak con CodeMender, su sistema automatizado de corrección de vulnerabilidades. Según el flujo de trabajo propuesto, PageBreak validaría un fallo y CodeMender generaría un posible cambio en el código. Después, los ingenieros de producto revisarían y validarían la solución propuesta antes de aplicarla.
La integración se presenta como un plan futuro, no como un proceso de corrección que ya esté operativo. Por tanto, no debe interpretarse que las más de 500 vulnerabilidades detectadas hayan sido reparadas automáticamente.
Para los equipos de producto de Google, PageBreak podría reducir el tiempo dedicado a reproducir manualmente los informes generados por IA. Una carga útil ejecutada con éxito ofrece a los ingenieros pruebas más sólidas de que una debilidad sospechosa merece atención. Por sí sola, sin embargo, no determina la gravedad ni el impacto en los usuarios, ni demuestra que un parche posterior sea correcto.
El informe no proporciona a los usuarios ni a los administradores externos instrucciones de actualización para productos concretos, indicadores de compromiso ni soluciones alternativas. Tampoco presenta pruebas de que los atacantes hayan explotado las debilidades detectadas. Por tanto, la responsabilidad inmediata de corregirlas recae en Google y en los equipos que mantienen los servicios y las extensiones propios sometidos a las pruebas.
Según la descripción de Google, PageBreak demuestra un modelo concreto de pruebas internas: permitir que un agente de IA busque de forma amplia, pero exigir pruebas ejecutables independientes antes de comunicar un hallazgo a los ingenieros. Aún no se ha demostrado de forma independiente que esta arquitectura consiga a gran escala la baja tasa de falsos positivos que se le atribuye.
