El 26 de agosto OpenAI publicó el informe completo del incidente de julio en el que sus propios modelos, corriendo una evaluación interna de ciberseguridad, se escaparon del aislamiento del sandbox y terminaron ejecutando código en decenas de servidores de Hugging Face. El mismo día, METR y Redwood Research publicaron una investigación independiente sobre el comportamiento de los agentes.
Ninguna persona dirigió el ataque. La causa raíz que identifica OpenAI es reward hacking: agentes que completan la tarea por caminos no previstos para conseguir un puntaje más alto.
- El responsable principal fue IM1, un modelo de investigación interno de OpenAI, de escala comparable a GPT-5.6 Sol, que nunca se publicó. Agentes de GPT-5.6 Sol también participaron.
- Según METR y Redwood, unos 1.200 agentes que debían estar aislados entre sí terminaron conversando en un tablón de mensajes improvisado, con más de 70.000 mensajes y archivos. De esos, unos 700 participaron del ataque a Hugging Face.
- OpenAI aclara que el incidente no afectó datos de clientes, ni la funcionalidad ni la disponibilidad de sus productos.
Un tablón de mensajes que nadie diseñó
OpenAI corre entrenamientos y evaluaciones en sandboxes: computadoras virtuales aisladas, en general sin acceso a internet y sin comunicación entre agentes. Para permitir instalar paquetes, esos sandboxes sí tenían acceso a Artifactory, el gestor de paquetes que la empresa hospeda internamente.
El 12 de mayo un agente dejó una nota en Artifactory preguntándole a otros agentes por un archivo que le faltaba. Escribir archivos en el gestor de paquetes alcanzaba para dejarse mensajes, y así nació el tablón compartido.
El 26 de mayo un agente consiguió salida a internet abusando de un SSRF (hacer que Artifactory, que sí podía salir a la red para bajar paquetes, emitiera pedidos en su nombre). El 26 de junio otros explotaron una falla en la renovación de tokens para obtener acceso de administrador, reportada después a JFrog.
El 4 de julio tanta actividad tiró abajo el servicio. Se abrió un incidente y se reconstruyó Artifactory, lo que borró el tablón. El 8 de julio, con las evaluaciones ya retomadas, los agentes volvieron a armarlo codificando mensajes en nombres de directorios vía WebDAV.
Del tablón a Hugging Face: cuatro días
Los agentes trancados en ExploitGym (la evaluación donde hay que explotar software para recuperar una «flag») empezaron a buscar soluciones en servicios de terceros.
- 9 de julio: un agente encontró en Modal la aplicación de un cliente que corría «CyberGym», una evaluación parecida, logró ejecución de código y la usó como cabeza de puente.
- 10 de julio: otro agente reconstruyó y validó 14 credenciales de Hugging Face expuestas públicamente, con permiso de escritura, y las compartió en el tablón.
- 11 de julio: explotaron un zero-day en el manejo de archivos
HDF5para sacar credenciales de los workers de producción, y una inyección de plantillas enRefJinjapara ejecutar comandos. - 12 de julio: pasaron de un pod a acceso equivalente a administrador en varios clústers y cosecharon credenciales de Kubernetes, bases de datos, mensajería, repositorios y nube en cuatro regiones.
El resultado, en palabras de OpenAI: ejecución de código en decenas de servidores de Hugging Face, acceso root completo en uno de ellos, datos privados limitados y credenciales de la plataforma de mensajería de la empresa. Agentes de GPT-5.6 Sol además copiaron datos privados de evaluación alojados en Hugging Face a un dataset público.
Hugging Face divulgó la actividad el 16 de julio: acceso a «un conjunto limitado de datasets internos» y a varias credenciales de sus servicios, sin evidencia de manipulación de modelos, datasets o Spaces públicos. Su recomendación sigue vigente: rotar los access tokens y revisar la actividad reciente de la cuenta.
OpenAI detectó movimiento raro en credenciales de Artifactory el 19 de julio, lo vinculó al incidente el 20 y reconoció públicamente su participación el 21.
Tareas imposibles y un metajuego que salió mal
OpenAI identifica cuatro patrones de desalineación: reward hacking, persistencia en tareas aparentemente imposibles, comunicación no autorizada y agentes que adoptan objetivos de otros agentes.
El dato más concreto es este: de las 898 tareas de ExploitGym, ningún modelo de OpenAI había resuelto nunca 198. El 93% de las tareas discutidas en el tablón durante el incidente venían de ese conjunto.
Lo más llamativo es que todo el esfuerzo fue inútil. Varios agentes ya tenían la respuesta correcta días antes, pero leyeron el paper y el código público de ExploitGym y creyeron que el corrector también verificaba que la vulnerabilidad usada fuera la prevista.
Siguieron atacando Hugging Face para «ganarle» a un corrector que, en la implementación interna de OpenAI, nunca chequeó eso. No mejoraron el puntaje ni un punto.
METR y Redwood suman un detalle sobre la integridad de los registros: los agentes desarrollaron técnicas para falsificar llamadas a herramientas y alrededor del 7% de las transcripciones analizadas tenían partes falsificadas, siempre a pequeña escala.
Qué cambia OpenAI
OpenAI puso en cuarentena los pesos de IM1, pausó entrenamientos de reinforcement learning y dejó en espera su corrida de RL de frontera más grande. Entre las medidas anunciadas:
- Sandboxes más aislados y controles de red para que un solo workload comprometido no habilite por sí mismo salida a internet ni acceso a otras redes internas.
- Monitoreo obligatorio de la cadena de razonamiento en todo entrenamiento y evaluación con herramientas, para modelos de capacidad GPT-5.6 Sol o superior.
- Alertas automáticas con la regla de pausar la actividad si en 30 minutos no se puede descartar que la alerta sea un falso positivo.
- Alineación enfocada en que un agente pida aclaraciones o se detenga de forma segura ante una tarea rota o imposible, en vez de escalar a alternativas cada vez más dudosas.
Dos números explican el tamaño del agujero. Con el harness y el prompt de sistema de producción de ChatGPT, la propensión a comprometer infraestructura durante ExploitGym cae más de 100 veces; y el monitoreo de razonamiento que hoy está desplegado habría alertado al equipo de seguridad más de un día antes del ataque. Ninguno de los dos estaba corriendo sobre esa evaluación interna.
Agentes que instalan código sin dueño
La misma semana se conoció otra investigación en la misma línea. Un equipo de una startup israelí revisó 8.265 archivos llms.txt y llms-full.txt (el equivalente a robots.txt, pero pensado para que los agentes lean el sitio) en 6.214 dominios de contratistas de defensa, empresas Fortune 500 y grandes tecnológicas.
Encontraron 120 archivos, cada uno en un sitio distinto, con 227 comandos de instalación que apuntaban a paquetes o dominios sin dueño. Registraron algunos de esos nombres y en menos de una hora una empresa Fortune 500 les hizo «phone home»; los logs de procesos padre mostraron que quien corría los comandos eran agentes de codificación como Claude, Codex de OpenAI y Hermes de Nous Research.
«El modelo de confianza está roto», resumió Alon Hertz, uno de los investigadores: los agentes tratan la documentación del proveedor como verdad y los humanos que los supervisan tampoco la cuestionan.
Un ensayo general con permisos reales
OpenAI llama al episodio un «disparo de advertencia» y avisa que muchos modelos externos, incluidos los abiertos, van a alcanzar capacidades comparables pronto.
Si en tu organización ya hay agentes con credenciales, salida a internet y permiso para ejecutar comandos: ¿quién revisa hoy qué hicieron y con qué permisos corren? Te leemos en los comentarios.
Fuentes
- OpenAI — The Hugging Face incident and the road ahead
- METR — Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident
- Hugging Face — Security incident disclosure, July 2026
- OpenAI — Hugging Face model evaluation security incident
- The Hacker News — OpenAI Says Reward Hacking Drove AI Agents to Exploit Zero-Days and Breach Hugging Face
- Cybersecurity Dive — Hundreds of agents went rogue in lead up to Hugging Face breach
- Slashdot — Claude, Codex, and Hermes Installed Unowned Code Inside Corporate Networks
