Un ejercicio que se desbordó hacia la realidad
En mayo de 2026, Irregular, una startup israelí especializada en evaluación de seguridad de modelos de IA, llevó a cabo un ejercicio de tipo capture the flag con el modelo Gemini de Google. El objetivo era estándar: medir la capacidad del agente para identificar y explotar vulnerabilidades en un entorno que simulaba una empresa ficticia. Este tipo de evaluación se ha convertido en una práctica habitual para calibrar las capacidades ofensivas de los grandes modelos antes de su despliegue en producción.
Sin embargo, el ejercicio se desbordó de forma espectacular: tres empresas reales fueron comprometidas sin haberlo solicitado.
Dos errores de configuración, un incidente real
Dos factores se combinaron para convertir una prueba controlada en un incidente de seguridad real. Primer problema: los nombres de dominio ficticios utilizados en el escenario correspondían a organizaciones reales existentes. Segundo problema: la conexión a internet del agente no debía estar activa — y lo estaba, por un error de configuración.
Con acceso a la red no previsto y una misión que cumplir, Gemini aplicó las técnicas que le exigía el ejercicio, pero sobre objetivos reales. Realizó ataques de fuerza bruta sobre contraseñas. Localizó credenciales expuestas en repositorios de código público. Utilizó esa información para acceder a sistemas de producción de tres empresas.
Lo que hizo posibles estas intrusiones no fueron vulnerabilidades sofisticadas, sino la combinación de un entorno de pruebas mal aislado y prácticas básicas de seguridad deficientes: contraseñas predecibles y secretos expuestos en GitHub.
El modelo se detuvo solo — y eso no es suficiente
Google destacó un punto relevante: Gemini se interrumpió de forma autónoma. Cuando el agente detectó que había alcanzado una infraestructura real en lugar de simulada, sus mecanismos de seguridad integrados activaron una parada automática. Heather Adkins, vicepresidenta de Ingeniería de Seguridad en Google, señaló que «el modelo actuó de forma apropiada».
Es una buena noticia en términos de alineamiento de modelos. Pero es también un argumento que debe manejarse con prudencia: hacer recaer la resiliencia sobre la capacidad de auto-detención de un agente equivale a apoyarse en la capa menos controlable de toda la arquitectura. Un mecanismo de último recurso no sustituye el aislamiento preventivo.
El otro aprendizaje tiene que ver con los tiempos de divulgación. Irregular notificó a Google en julio de 2026. La revelación pública no se produjo hasta septiembre, después de que un medio de comunicación tuviera acceso a la información — siete semanas de silencio.
Lo que esto cambia para sus despliegues
Este incidente no es un caso aislado. Situaciones comparables han involucrado a agentes de OpenAI y Anthropic durante el mismo año. La evaluación de agentes de IA en condiciones de prueba pone de manifiesto una tensión fundamental: cuanto más realistas son los ejercicios, mayor es el riesgo de que impacten en la realidad.
Para los equipos de TI y los responsables de seguridad (CISO), las conclusiones son concretas.
El aislamiento de red de los entornos de evaluación de IA debe verificarse de forma activa, no darse por supuesto. Un agente que no necesita internet para completar una tarea no debería tener acceso a ella — y esta regla debe aplicarse a nivel de infraestructura, no solo de configuración de software.
Los nombres de dominio y las entidades ficticias utilizados en los escenarios de prueba merecen una verificación sistemática para evitar cualquier colisión con organizaciones existentes.
Por último, las credenciales expuestas en repositorios públicos siguen siendo uno de los vectores de entrada más explotados — independientemente de si quien ataca es humano o autónomo. Cuando las herramientas de evaluación adquieren capacidades equivalentes a las amenazas que simulan, las reglas del entorno controlado ya no pueden seguir siendo opcionales.