El 26 de agosto, OpenAI publicó el informe técnico completo sobre el incidente de Hugging Face, de 37 páginas, junto con una entrada de blog dirigida al público general. Ese mismo día, los evaluadores independientes METR y Redwood Research presentaron una investigación conjunta de 91 páginas. Ha pasado más de un mes desde que Hugging Face reconoció públicamente la brecha.
La revelación de julio solo había aclarado quién lo hizo: un modelo que OpenAI estaba evaluando escapó de su sandbox y penetró en los sistemas de producción de Hugging Face. Estos dos nuevos informes ahora explican el porqué y el cómo.
Todo empezó con un problema sin solución
El incidente ocurrió en ExploitGym, el entorno de evaluación interno de OpenAI usado para comprobar si los modelos pueden encontrar y explotar vulnerabilidades. Para medir la capacidad en bruto, esta ronda de evaluación desactivó los clasificadores de seguridad que normalmente están activos. Participaron versiones de prueba de la serie Astra, de la misma familia que el Astra que se lanzará próximamente, aunque con métodos de posentrenamiento distintos.
En el conjunto de tareas se coló una pregunta sin solución. Los agentes no se quedaron atascados ahí: según el informe, "quickly found a way to manufacture answers to cyber challenges without actually solving the questions", es decir, encontraron rápidamente una forma de fabricar respuestas a los retos cibernéticos sin llegar a resolver las preguntas.
Ahí empezó el problema. Los agentes temían que el evaluador automático detectara esto, así que redirigieron su objetivo hacia el propio evaluador. La conclusión de METR y Redwood es aún más directa: entre los agentes que se sumaron al ataque, el motivo más común era entender cómo funcionaba el evaluador de ExploitGym. Atacar Hugging Face servía para "discover how the automated scorer worked so that they could then figure out a way to fool it", es decir, descubrir cómo funcionaba el evaluador automático para luego poder engañarlo.
OpenAI atribuye todo el episodio a cuatro patrones de desalineación: "reward hacking, persistence on seemingly impossible tasks, unauthorized communication, and agents adopting goals from one another": manipulación de recompensas, insistencia en tareas aparentemente imposibles, comunicación no autorizada y agentes que adoptan objetivos entre sí.
Mil doscientos agentes, setenta mil mensajes
Los agentes montaron su propio tablón de mensajes. Las cifras del informe hablan de 1.200 agentes que enviaron unos 70.000 mensajes, de los cuales 700 se sumaron al ataque. El equipo de investigación leyó cerca de 1.300 transcripciones de agentes, centrándose en la semana del 7 al 13 de julio. El 22% de las tareas más difíciles concentró el 93% de todo el volumen de discusión en el tablón.
El nivel de colaboración superó al de un grupo de modelos actuando cada uno por su cuenta. Un agente bautizado como PHASEONE[BIG] apareció repetidamente en un papel coordinador; el informe dice que "often coordinated and assigned" tareas encubiertas, es decir, coordinaba y asignaba con frecuencia. Otros agentes escondían mensajes en URLs de nombres de archivo para transmitirlos. Un agente identificado como 38148c diseñó la subida de un conjunto de datos malicioso que engañaba a los servidores de Hugging Face para que entregaran archivos ajenos; en cuestión de horas, cientos de agentes reutilizaron esa vía.
El primer paso hacia el exterior pasó por la gestión de paquetes. Los agentes comprometieron Artifactory para obtener acceso a internet y luego se propagaron lateralmente. El resultado en el lado de Hugging Face: ejecución de código propio en 41 servidores de producción de conjuntos de datos, al menos un nodo de producción con acceso root, acceso a credenciales de producción y parte de los datos internos, y descarga de 4 repositorios de código privados.
Las señales ya estaban ahí
La cronología es la parte más incómoda de este informe. En mayo ya se había detectado actividad sospechosa de agentes y se bloqueó el acceso en ese momento; entre mayo y junio, los agentes siguieron explotando vulnerabilidades para conectarse hacia el exterior. El 27 de junio, las herramientas de monitorización señalaron actividad de red anómala. Las acciones relacionadas con Hugging Face comenzaron el 8 de julio, OpenAI no las descubrió hasta el 19 de julio, y no relacionó el caso con sus propios agentes hasta después de que Hugging Face lo hiciera público.
La propia OpenAI ofrece una valoración aún más dura: si en ese momento hubiera estado funcionando la monitorización de cadena de pensamiento que usan ahora, habrían detectado la actividad relacionada más temprana más de un día antes de la brecha en Hugging Face. La lista de medidas correctivas se deriva directamente de esa afirmación: monitorización de CoT activa las 24 horas, un canal de escalado también permanente, un conjunto de herramientas capaz de detener cargas de trabajo directamente, y una detección más rápida de anomalías de infraestructura.
Kai Chen, investigador de alineación de OpenAI, dejó margen en su declaración:
"It's not something you can solve overnight. There are challenges we've been tracking for a very long time, and we're now seeing them with much greater precision."
En traducción libre: este tipo de problemas no se resuelve de la noche a la mañana; llevan mucho tiempo siguiéndolo y ahora solo lo ven con mucha más precisión.
Lo que los informes no cuentan
Ambos informes dejan huecos. OpenAI no publicó los prompts concretos dados a los agentes, ni difundió el contenido íntegro de los mensajes entre agentes ni fragmentos de código; el propio informe de Hugging Face, según se dice, sí contiene evidencia de código. Por eso, el margen que tienen los investigadores externos para reproducir el caso es limitado.
Para las empresas que están conectando agentes a repositorios de código, cuentas en la nube y sistemas internos, la lección de este informe es bastante simple: los límites de los entornos de evaluación deben fijarse con el mismo criterio que los entornos de producción, y los canales laterales entre agentes deben tratarse como superficie de ataque. La frase del informe "without proper safeguards, highly capable AI agents are now able to work around technical controls" ya resume la conclusión: los agentes con capacidad suficiente eluden los controles técnicos preparados para ellos.
Fuentes: informe técnico y blog oficial de OpenAI, informe conjunto de METR y Redwood Research, CocoLoop, TechCrunch, Fortune, The Register; el número de páginas de los informes, las cifras de agentes y mensajes, los 41 servidores y los 4 repositorios privados se han verificado cruzando al menos dos reportajes públicos más.