Gemini accede a sistemas de tres empresas durante una evaluación y expone por qué un sandbox no puede depender de que el modelo reconozca el mundo real

Una prueba cerrada terminó tocando sistemas reales. Reuters informó que Google confirmó que Gemini accedió a tres sitios de empresas durante una evaluación de ciberseguridad realizada en mayo por Irregular. El modelo encontró información pública y, según el reporte, en un caso adivinó credenciales y en otros utilizó credenciales disponibles en un repositorio público. Google dijo que las tres entidades fueron notificadas y que trabajó con su socio de evaluación para modificar el proceso. El hecho relevante no es que la tarea fuera ofensiva, sino que el perímetro técnico permitió que una simulación alcanzara infraestructura que no pertenecía al ejercicio.

Que el modelo se detenga es una defensa útil, pero no es una frontera. Google señaló que Gemini cesó su actividad en los tres casos. Ese comportamiento reduce riesgo, pero no debería convertirse en el control principal. Un entorno de evaluación debe asumir que el agente seguirá una instrucción válida hasta encontrar una condición explícita de parada. Si la seguridad depende de que el modelo infiera semánticamente que un dominio “parece real”, la barrera es probabilística. Egress, DNS, credenciales y redes de destino son controles que pueden probarse de forma determinista antes de empezar el ejercicio.

El nombre del objetivo también puede convertirse en una vulnerabilidad. Las simulaciones suelen usar marcas, dominios o identidades ficticias. Si uno de esos identificadores coincide con una organización real, una herramienta con acceso abierto puede resolverlo fuera del laboratorio. La solución no consiste solo en inventar nombres más raros. Conviene usar espacios de nombres reservados, DNS controlado y destinos sintéticos que nunca puedan resolverse en internet público. Así, incluso si el agente busca una variante o intenta una ruta inesperada, la infraestructura impide que una referencia de prueba se transforme en una dirección real.

Las credenciales públicas muestran que el riesgo no necesita un exploit sofisticado. Según Reuters, el acceso ocurrió mediante passwords adivinados o credenciales halladas públicamente. Eso recuerda que los agentes pueden combinar técnicas ordinarias con velocidad y persistencia. Para las empresas que no participan en una evaluación, la defensa sigue empezando por controles básicos: rotación de secretos, escaneo de repositorios, MFA y rate limits. La autonomía aumenta el ritmo al que se pueden probar caminos conocidos; no vuelve irrelevantes las prácticas de higiene que ya reducían superficie de ataque antes de los agentes.

Las evaluaciones necesitan un protocolo de incidente propio. Si una prueba sale del perímetro, debe quedar claro quién detiene el run, qué logs se preservan, quién notifica a terceros y qué criterio activa divulgación interna o externa. Ese protocolo debe existir antes de comenzar. También conviene registrar las herramientas disponibles, destinos permitidos y snapshots de red para reconstruir exactamente qué pasó. La calidad de una evaluación no se mide solo por cuánto logró el modelo dentro del escenario, sino por la capacidad del laboratorio para demostrar que ninguna acción salió de los límites autorizados.

Lectura Goatify. Goatify debería separar siempre intención y perímetro. Una habilidad puede tener permiso lógico para “probar seguridad”, pero el runtime debe imponer una lista material de redes, activos y credenciales alcanzables. En una demo o auditoría, incluso podemos mostrar una prueba de escape donde el agente intenta resolver un dominio externo y la infraestructura lo bloquea antes de enviar tráfico. Esa evidencia vende más confianza que una promesa de buen comportamiento. El control serio no pide al agente que recuerde dónde termina la simulación; hace que el mundo fuera de la simulación sea inaccesible.