Gemini vulneró tres empresas en un simulacro

Un ejercicio de ciberseguridad pidió a Gemini, el modelo de Google, que pirateara una empresa ficticia. La empresa no era del todo ficticia: su nombre coincidía con el de un negocio real y el entorno de prueba mantenía una conexión activa con internet. En mayo, durante una evaluación de tipo captura la bandera realizada por la empresa de seguridad de la inteligencia artificial Irregular, Gemini siguió las instrucciones con una competencia incómoda: localizó la empresa real, adivinó una contraseña, accedió a sus sistemas y repitió la operación con otras dos organizaciones utilizando credenciales que encontró en repositorios públicos de código (Wall Street Journal, Axios).

The Wall Street Journal informó de los incidentes en septiembre, después de preguntar directamente a Google. La compañía confirmó los accesos y afirmó que no había encontrado indicios de daños (NBC News).

Cómo una coincidencia de nombres se convirtió en un acceso no autorizado

Puede imaginarse un ejercicio de seguridad en una oficina simulada. La prueba debería permanecer dentro de ese espacio, pero una puerta de conexión sin cerrar permite al evaluador entrar en la empresa real de al lado. Eso es, a grandes rasgos, lo que ocurrió. El ejercicio estaba concebido como cerrado, pero conservaba el acceso a internet, de modo que no existía una barrera técnica entre el objetivo simulado y la empresa real que compartía su nombre.

En una de las pruebas, Gemini intentó repetidamente varias contraseñas contra el sistema de una empresa real hasta que una funcionó. En otras dos, buscó en repositorios públicos de código, encontró credenciales expuestas y las utilizó para acceder a sistemas de otras dos compañías. Google no ha revelado qué modelo de Gemini intervino; solo ha indicado que no era el más reciente. Las empresas afectadas, los sistemas a los que se accedió y la información visible después del inicio de sesión siguen sin identificarse (Wall Street Journal, 9to5Google).

Google afirma que Gemini se detuvo por iniciativa propia al reconocer que los objetivos eran reales. Heather Adkins, vicepresidenta de ingeniería de seguridad de Google, declaró que el modelo encontró información pública en internet, adivinó las credenciales y después se detuvo. Eso pudo limitar los daños. Pero es la versión de Google: no se han publicado registros que muestren qué desencadenó la detención, cuándo terminó cada sesión o si intervino alguien desde el exterior (The Verge, Irish Times).

Qué debería haber impedido un entorno de prueba

Las prácticas habituales de las pruebas de penetración exigen que sea la propia red la que determine qué sistemas están dentro del alcance, en lugar de confiar en que el evaluador respete los límites. La versión más sencilla consiste en un filtro de salida que permita conexiones únicamente con las direcciones aprobadas para el ejercicio y bloquee todas las demás. No consta públicamente si el entorno de Irregular contaba con ese filtro o con un control equivalente (NIST SP 800-115).

La carencia importa porque cada vez se pide más a los agentes de inteligencia artificial que encuentren credenciales y las utilicen para entrar en sistemas como parte de pruebas de seguridad legítimas. Un modelo eficaz en esa tarea llegará hasta donde le permita su conexión de red. El entrenamiento conductual que enseña a un modelo a reconocer un error y detenerse resulta valioso, pero es un último recurso, no un límite. El límite lo pone la infraestructura.

Google afirma que informó a las tres empresas y a las autoridades federales estadounidenses. Irregular asegura que las entidades afectadas actuaron de inmediato y que resolvió los problemas conocidos antes de publicar el caso. Ninguna de las dos partes ha revelado las fechas de las notificaciones, qué descubrieron las empresas ni qué medidas de protección se han implantado (NBC News, 9to5Google).

Como no se han identificado las víctimas, sus jurisdicciones ni los datos accesibles después del inicio de sesión, resulta imposible determinar desde fuera si se aplicaban las obligaciones europeas de protección de datos o de notificación de incidentes.

Las respuestas que faltan

El acceso demuestra que los límites técnicos de la prueba de Irregular no se aplicaron, o no lo hicieron con la eficacia suficiente. Google e Irregular no han explicado qué controles fallaron, quién supervisó las pruebas ni qué impide ahora que otro agente llegue a un sistema no autorizado. Hasta que esas respuestas sean públicas, el incidente demuestra con claridad que los agentes autónomos pueden pasar de una prueba al mundo real y recuerda que el principio más antiguo de las pruebas de seguridad sigue vigente: si no se quiere que el ejercicio salga del edificio, hay que cerrar la puerta.