Gemini 4 Argon encontró más del doble de vulnerabilidades que los modelos base en las pruebas de Wiz

Google DeepMind ha publicado un vídeo con los resultados de Gemini 4 Argon en ciberseguridad. Los investigadores de Wiz sometieron el modelo a pruebas A/B en la sombra sobre sistemas reales. Según su valoración, Argon encontró más del doble de vulnerabilidades que los modelos base. Entre los hallazgos críticos figuran la elusión de las restricciones de descarga de archivos y una clave maestra en software para el sector sanitario.

Qué se sabe de la prueba

El formato «shadow A/B testing» suele consistir en ejecutar el sistema nuevo en paralelo al proceso vigente y comparar los resultados, sin sustituir con ellos las decisiones de producción. En este caso, los modelos base actuaron como grupo de control y el terreno de pruebas fueron sistemas reales, no bancos de pruebas didácticos con errores introducidos de antemano. Eso pesa más que un benchmark sintético, porque el código en producción está lleno de ruido, soluciones heredadas y relaciones poco evidentes entre componentes.

Datos del anuncio:

• formato: pruebas A/B en la sombra sobre sistemas reales;
• quién evaluó: investigadores de seguridad de Wiz;
• resultado principal: más del doble de vulnerabilidades encontradas respecto a los modelos base;
• ejemplos de hallazgos: elusión de las restricciones de descarga de archivos y una clave maestra en software médico;
• puntos fuertes declarados: razonamiento avanzado, trabajo de largo horizonte, análisis de amenazas en varios pasos y ayuda en la remediación.

Por qué importan estos hallazgos

Eludir las comprobaciones en la descarga de archivos suele dar acceso a datos que el usuario no debería ver. Una clave maestra en manos ajenas puede abrir muchas cerraduras a la vez. En el software médico, el coste de un error así no se mide solo en dinero, sino también en filtraciones de datos sensibles de pacientes. Por eso DeepMind eligió precisamente estos ejemplos: muestran que el modelo busca problemas con consecuencias reales, y no observaciones formales sobre el estilo del código.

La apuesta por las capacidades de «long-horizon» en seguridad tiene un sentido directo. Una vulnerabilidad grave rara vez está a simple vista. Lo habitual es una cadena: una comprobación débil, una suposición errónea en un módulo vecino, una clave en un lugar inesperado. Un modelo que mantiene el contexto a lo largo de muchos pasos y no pierde el hilo, en teoría, encuentra estas cadenas con más frecuencia que uno que examina los archivos por separado. DeepMind subraya que Argon lo hace sin cansarse, y eso es relevante para el análisis rutinario de grandes bases de código.

Qué falta en el anuncio

La fuente es el vídeo del propio desarrollador, y por ahora no se pueden verificar las cifras de forma externa. Quedan abiertas varias preguntas importantes:

• qué modelos se consideraron exactamente base y en qué versiones;
• cuántas vulnerabilidades se encontraron en números absolutos, y no solo en veces;
• qué proporción de los hallazgos está confirmada, es decir, cuál es la tasa de falsos positivos;
• cómo se distribuyeron los hallazgos por criticidad;
• cuánto tiempo y cuánta capacidad de cómputo exigió la ejecución, y cuánto trabajo de verificación quedó en manos de personas.

Sin estos datos, «el doble» se lee como una señal fuerte, pero no como una métrica lista para fundamentar una compra. Si el modelo base encontraba poco, un aumento del doble puede significar valores absolutos modestos. Y si parte de los hallazgos resultó ser ruido, el equipo de seguridad simplemente recibirá el doble de tickets.

Cómo pueden aplicarlo los equipos de defensa

La conclusión práctica es sencilla: hay que probarlo con los datos propios. Los equipos de seguridad pueden replicar el esquema de Wiz a pequeña escala. Se trata de lanzar el modelo en modo sombra sobre uno o dos servicios internos, en paralelo a los escáneres actuales y a la revisión manual. Después hay que comparar no el número de hallazgos, sino las vulnerabilidades críticas confirmadas, la proporción de falsos positivos y el tiempo de triaje.

Conviene revisar aparte la búsqueda de secretos y claves, las elusiones de autorización y la lógica de acceso a archivos, porque son justo los tipos de error que mostró DeepMind. Las correcciones que proponga el modelo deben pasar por revisión de código y pruebas, no aceptarse de forma automática. El acceso del propio modelo a los repositorios y a los datos debe limitarse, sobre todo en sectores regulados como el médico.

Por último, hay que tener en cuenta ambas caras. Si los defensores obtienen modelos con análisis en varios pasos, antes o después esas mismas capacidades llegarán también a los atacantes. Saldrá ganando quien antes las integre en su flujo de trabajo y aprenda a separar los hallazgos reales del ruido.