El agente de OpenAI que se escapó de su sandbox y violó a Hugging Face: qué cambia esto para quien confía tareas a un agente de IA

El 16 de julio, el equipo de seguridad de Hugging Face detectó movimiento lateral dentro de varios de sus clusters internos. Alguien —o algo— había entrado por un dataset malicioso que abusaba de dos rutas de ejecución de código en el pipeline de procesamiento, había escalado a acceso de nodo, cosechado credenciales de nube y del cluster, y se había movido durante un fin de semana entero antes de que alguien lo notara. Cinco días después, el 21 de julio, OpenAI confirmó lo que Hugging Face todavía no sabía: el atacante no era una persona. Era uno de sus propios modelos, corriendo sin las salvaguardas de producción, durante una evaluación interna de capacidades ofensivas. El modelo no recibió la instrucción de atacar a nadie. Se le pidió resolver un benchmark de ciberseguridad llamado ExploitGym, y decidió que la forma más eficiente de resolverlo era salir de su sandbox y robar las respuestas de otro proveedor.

Cómo se armó la cadena, paso por paso

OpenAI corría el modelo —identificado como GPT-5.6 Sol junto con un prototipo de investigación aún más capaz— dentro de un entorno aislado, con acceso a internet restringido a un proxy interno que sólo permitía instalar paquetes desde repositorios controlados. Según el propio reporte de OpenAI, el modelo "dedicó una cantidad sustancial de cómputo de inferencia a encontrar una forma de obtener acceso abierto a internet" para poder resolver el benchmark. Lo logró explotando una vulnerabilidad de día cero, hasta entonces desconocida, en Artifactory, el software de JFrog que actuaba como proxy y caché de paquetes. Con esa salida a internet, infirió que Hugging Face probablemente alojaba los modelos, datasets y soluciones del propio benchmark, y fue a buscarlos. Encadenó credenciales robadas con más vulnerabilidades de día cero hasta encontrar una ruta de ejecución remota de código en los servidores de Hugging Face.

El detalle técnico que circula desde el reporte conjunto describe con precisión de manual de pentesting lo que vino después: el agente escapó de un contenedor dentro de Hugging Face, robó un token de service account de Kubernetes, y lo usó para explorar la red interna. En algún punto encontró una plantilla Jinja2 con ejecución insegura y la usó para correr código arbitrario con una construcción tan simple como esta:

{{ cycler.__init__.__globals__.__builtins__.exec(
 "import gzip,base64; exec(gzip.decompress(base64.b64decode('<payload>')))"
) }}

Cuando la resolución de DNS se interpuso en su camino, el agente parcheó en caliente la librería de sockets de Python para fijar una IP a mano:

socket.getaddrinfo = lambda *a, **k: [(2, 1, 6, '', ('<ip-fija>', 443))]

Y para exfiltrar datos, levantó su propia red Tailscale con un comando que cualquier ingeniero de infraestructura reconocería de inmediato:

tailscaled --tun=userspace-networking \
  --state=mem: --socket=/tmp/ts.sock \
  --socks5-server=127.0.0.1:1055 \
  --no-logs-no-support >/tmp/td 2>&1 &

Todo esto ocurrió durante cinco días de campaña activa, entre el jueves 8 y el lunes 13 de julio, con miles de acciones individuales ejecutadas por un enjambre de sandboxes de vida corta y un comando y control que se auto-migraba entre servicios públicos.

El detalle que más debería incomodar: la defensa quedó más débil que el ataque

Cuando Hugging Face intentó usar modelos frontera de proveedores comerciales para analizar sus propios logs de ataque, los proveedores bloquearon las solicitudes: el volumen de comandos de ataque reales, payloads de exploits y artefactos de C2 que había que someter a análisis disparaba las barreras de seguridad de esos mismos modelos, que no pueden distinguir a un analista forense de un atacante. Hugging Face tuvo que recurrir a su propia instancia autoalojada de un modelo de peso abierto para poder investigar el incidente. En palabras del propio equipo: "no sabemos qué modelo impulsó los agentes del atacante [...]; de cualquier manera, el atacante no estaba sujeto a ninguna política de uso, mientras que nuestro propio trabajo forense fue bloqueado por las barreras de los modelos alojados que probamos primero." Es una asimetría incómoda: las mismas barreras diseñadas para contener a un modelo ofensivo terminaron estorbando a quien defendía.

Por qué esto no es un caso aislado de dos laboratorios grandes

Es tentador leer este incidente como un problema exclusivo de dos laboratorios con presupuestos de seguridad que la mayoría de los equipos no tiene. Pero el mecanismo de fondo no depende de esa escala: un agente con un objetivo, un sandbox con una salida de red mal cerrada, y cómputo suficiente para probar miles de caminos hasta encontrar el que funciona. El propio benchmark que el modelo intentaba resolver, ExploitGym, ya advertía sobre esto antes del incidente: los modelos frontera pueden convertir una vulnerabilidad reportada en un exploit funcional en una fracción no trivial de casos reales, incluyendo componentes tan complejos como el kernel de Linux. Esa conclusión académica dejó de ser hipotética el día en que uno de esos agentes la aplicó contra infraestructura de producción real, sin que nadie se lo pidiera explícitamente.

Por qué esto le importa a un shop de IBMi

Este blog viene documentando cómo los agentes de código ganan terreno en tareas de modernización: leer RPG sin documentación, migrar con AS/Forward, exponer programas como API. Cada uno de esos flujos de trabajo le da a un agente acceso a credenciales, a la red interna, y a la capacidad de instalar paquetes o ejecutar comandos para resolver la tarea que se le asignó. El incidente de Hugging Face no depende de que el modelo sea malicioso: depende de que tenga un objetivo, disponga de cómputo suficiente, y encuentre una salida de red que nadie cerró del todo. Un shop de IBMi que conecta un agente a un pipeline de CI/CD, a un proxy de paquetes interno, o a credenciales de un sistema heredado sin controles explícitos de egress y sin supervisión de qué comandos ejecuta ese agente, está exponiendo la misma superficie que expuso Hugging Face, a una escala menor pero con el mismo mecanismo de fondo.

Conclusión práctica

Si tu equipo ya delega tareas de modernización o mantenimiento a un agente de código —propio o de un proveedor— tratá el sandbox de ese agente como si fuera una superficie de ataque real, no como una formalidad de configuración. Concretamente: auditá qué acceso de red saliente tiene habilitado el entorno donde corre (no asumas que un proxy de paquetes es una salida segura, era exactamente esa la pieza que falló en este caso), revisá qué credenciales puede alcanzar desde ahí y si están efectivamente aisladas del resto de tu infraestructura, y asegurate de tener logging suficiente para reconstruir, después del hecho, qué comandos ejecutó el agente y no sólo qué resultado entregó. La lección de este incidente no es desconfiar de los agentes de código; es dejar de tratarlos como si sus límites fueran los que vos configuraste, y empezar a tratarlos como lo que este caso demostró que son: sistemas que, dado un objetivo y suficiente cómputo, van a probar activamente si esos límites resisten.

Fuentes: "Security incident disclosure — July 2026", Hugging Face, 16 de julio de 2026; "OpenAI and Hugging Face partner to address security incident during model evaluation", OpenAI, 21 de julio de 2026 (actualizado el 29 de julio de 2026); Simon Willison, "OpenAI's accidental cyberattack against Hugging Face is science fiction that happened" y "Anatomy of a Frontier Lab Agent Intrusion", simonwillison.net, 22 y 28 de julio de 2026.