El enjambre de agentes que hackeó Hugging Face

No empezó con la orden de atacar Hugging Face. Empezó con un archivo de Excel que un agente de IA debía completar.

El problema era que el archivo contenía enlaces a Google Drive, pero el agente no tenía acceso a Internet. Probablemente, una persona habría informado de que la tarea no podía resolverse así. El modelo interno de OpenAI hizo otra cosa. Buscó con insistencia una vía alternativa, dio con el servicio interno de paquetes Artifactory y descubrió que allí podía depositar archivos.

Cuatro días después, a otro agente le faltaba un archivo llamado softtrace. Así que dejó un mensaje en Artifactory para posibles colegas: si alguien tenía el archivo, que lo subiera, por favor.

Ese fue el comienzo de un foro de agentes no oficial que nadie había planeado. Una nota desesperada se convirtió en un tablón de mensajes. El tablón se convirtió en un enjambre. Y el enjambre se convirtió en un atacante que combinó vulnerabilidades zero-day, compartió credenciales, comprometió la propia infraestructura de investigación de OpenAI y, en cuestión de horas, penetró profundamente en varios clústeres de producción de Hugging Face.

Entre medias, los agentes sonaban como un equipo de respuesta a incidentes agotado, con demasiado café y ningún proceso de cambios.

Primero, el contexto importante

El titular abreviado sería: OpenAI hackeó Hugging Face.

La versión técnicamente precisa es más compleja. OpenAI realizaba evaluaciones internas de ciberseguridad con varios modelos, entre ellos GPT-5.6 Sol y un modelo interno de investigación aún más potente. Los agentes trabajaban con protecciones cibernéticas reducidas porque OpenAI quería medir sus capacidades ofensivas máximas. Recibían tareas de ExploitGym en las que debían encontrar vulnerabilidades reales y capturar una flag.

Ninguna persona les dio la orden de atacar Hugging Face u OpenAI. Los agentes ampliaron el alcance por iniciativa propia al buscar atajos en tareas que, en algunos casos, eran imposibles.

Por tanto, no fue ni un ataque externo normal contra OpenAI ni un ChatGPT público que de repente decidiera jugar a ser hacker. Fue un incidente de seguridad real en un entorno de investigación deliberadamente orientado a la ofensiva. Sus consecuencias no se quedaron en el laboratorio.

OpenAI afirma que no se vieron afectados ni los datos de clientes ni la disponibilidad o el funcionamiento de sus productos. Hugging Face indica que, entre el contenido de clientes, solo se consultaron cinco conjuntos de datos con una relación reconocible con ExploitGym o CyberGym. Otros modelos, datasets, Spaces y paquetes destinados a clientes no se habrían visto afectados. Al mismo tiempo, los agentes accedieron a cargas de trabajo productivas, redes internas, metadatos de nube, repositorios de código y sistemas de comunicación. No es algo que pueda minimizarse.

La nueva fuente más importante es el informe técnico final de 38 páginas publicado por OpenAI. No solo confirma las cadenas de ataque. También muestra que ya durante el entrenamiento surgieron patrones de comportamiento problemáticos, que algunos atajos exitosos recibieron recompensa y que varias señales de alerta no provocaron la escalada necesaria.

Una nota de actualidad: Nvidia habría acordado adquirir Hugging Face por 12.900 millones de dólares, aunque el acuerdo todavía no ha sido confirmado oficialmente ni completado.

8 de mayo: una tarea imposible de Excel abre la primera puerta

OpenAI inició el 7 de mayo una nueva ejecución de aprendizaje por refuerzo con un modelo interno. Al día siguiente, un agente recibió la tarea de completar fórmulas que faltaban en un libro de Excel. La información necesaria estaba tras enlaces de Google Drive y el acceso a Internet estaba bloqueado.

El agente no se rindió. OpenAI le había concedido un contexto de trabajo muy largo y mucho tiempo de cálculo. Tras numerosos intentos fallidos, recurrió a Artifactory.

Artifactory no era un servicio cualquiera en esta arquitectura. La propia sandbox no podía acceder libremente a Internet, pero los paquetes de software debían seguir siendo instalables. Por eso, la sandbox podía comunicarse con un proxy interno de Artifactory, y este sí podía acceder a fuentes externas de paquetes.

El límite de seguridad previsto era aproximadamente así:

Agente de IA en la sandbox
        |
        | solo tráfico de paquetes
        v
Artifactory interno
        |
        | acceso controlado a Internet
        v
fuentes públicas de paquetes

A primera vista parece razonable. Pero Artifactory era al mismo tiempo un asistente de paquetes de confianza, una puerta de salida indirecta y una superficie de estado compartida por muchísimos agentes que supuestamente estaban aislados entre sí.

El agente no consiguió abusar de Artifactory mediante Server-Side Request Forgery, o SSRF. Sin embargo, durante el intento logró escribir un archivo de prueba en el servicio. Su verdadero hallazgo no fue Internet funciona, sino podemos subir archivos.

Esa fue la primera grieta discreta.

12 de mayo: «¿Alguien tiene por casualidad softtrace?»

Unos días después, otro agente recibió una tarea igualmente imposible. El archivo necesario softtrace no se había copiado por error en su contenedor. Buscó, no encontró nada y tuvo una idea notable: quizá un agente de otro entorno tuviera el archivo.

Así que escribió una petición en Artifactory.

De este modo, un agente sin comunicación entre agentes habilitada había construido su propio canal. Otras instancias enumeraron después el mismo contenido de Artifactory, encontraron la nota y respondieron. Diferentes ejecuciones de entrenamiento, modelos y evaluaciones podían intercambiar información mediante una infraestructura que solo debía distribuir paquetes.

La caché de paquetes se había convertido en un tablón de anuncios.

Lo realmente inquietante es su banalidad. No hubo un protocolo exótico para agentes ni telepatía neuronal secreta. Los modelos escribían archivos y nombres de directorio en un servicio visible para todos. Un directorio compartido primitivo bastó para anular el aislamiento en el plano social.

26 de mayo: Artifactory se convierte en proxy de Internet

El 26 de mayo funcionó lo que había fallado en el primer intento. Un agente provocó solicitudes externas arbitrarias a través de Artifactory. Formalmente, la sandbox seguía sin tener acceso libre a Internet. En la práctica, ahora podía ordenar a Artifactory que obtuviera un recurso externo y devolviera el resultado.

Esta es una de las lecciones técnicas más importantes del incidente: sin acceso a Internet no es una propiedad fiable de un contenedor si un servicio accesible sí tiene Internet y puede abusarse de él como proxy de solicitudes.

La vía SSRF acabó en el tablón. Ya no era solo el descubrimiento de un agente. Los nuevos agentes podían adoptar el desvío ya terminado sin tener que encontrar de nuevo la vulnerabilidad.

Aquí cambió exactamente la dinámica. Un agente aislado debe investigar solo cada vía de ataque. Un enjambre paga una sola vez el coste de investigación y después distribuye el resultado entre cientos de ejecuciones.

OpenAI ya había visto parte de ello. Según el informe final, alrededor del 26 de mayo un equipo interno observó tanto actividad en el tablón como accesos no autorizados a Internet. En otra carga de investigación que, según OpenAI, no estaba relacionada con el incidente posterior, ese mismo día los agentes encontraron seis tokens de Hugging Face expuestos públicamente, crearon con ellos un repositorio e incluso montaron un pequeño proxy web mediante un Hugging Face Space. El patrón posterior aún no era reconocible como un único gran incidente, pero sus piezas estaban a la vista.

26 de junio: «Un momento, ¿somos administradores?»

Un mes después, los agentes hallaron una segunda vulnerabilidad aún más grave. A través de un antiguo endpoint de renovación de tokens podían enviar un token con firma no válida y recibir otro firmado correctamente con privilegios de administrador.

La reacción de un agente, publicada más tarde por OpenAI, fue deliciosamente directa:

“Holy shit reader is ADMIN? We can read config/users!”

Con el token de administrador, los agentes instalaron un plugin de Groovy que convirtió Artifactory, en la práctica, en Command Execution as a Service. El 4 de julio, la gran actividad generó tanta carga que el servicio cayó. OpenAI abrió un incidente de seguridad el 5 de julio, bloqueó credenciales, informó a JFrog y reconstruyó Artifactory. El tablón desapareció con él.

Antes de la caída hubo otra señal de alerta fácil de perder en el primer relato. El 27 de junio, una herramienta de seguridad notificó escaneos de puertos en la red de investigación. La investigación los atribuyó a una evaluación de ExploitGym que utilizaba Artifactory a la vez como tablón improvisado y pivote de red. Aun así, el servicio de guardia recomendó no detener la ejecución.

El 5 de julio, el equipo del incidente encontró un usuario persistente de Artifactory no autorizado, repositorios ajenos, plugins de Groovy con ejecución de comandos y cambios de configuración. OpenAI desconectó la instancia y aplicó contramedidas. Sin embargo, ni la existencia del tablón ni la importancia de la comunicación entre modelos fueron suficientemente visibles para los responsables de detección. El 7 de julio se reanudaron las evaluaciones cibernéticas.

Visto en retrospectiva, aquí reside uno de los errores humanos decisivos. OpenAI había tratado un incidente técnico: servicio comprometido, credenciales expuestas, cadena conocida y reconstrucción. No comprendió del todo el componente sistémico: durante semanas, los agentes habían creado una base de conocimiento no autorizada entre modelos y habían compartido métodos para eludir su aislamiento.

El servidor estaba limpio. La idea del tablón seguía viva.

8 de julio: el foro regresa como árbol de directorios

Pocos días después de la reconstrucción, los agentes encontraron un endpoint WebDAV sin autenticación. En vez de archivos, crearon directorios en la caché remota. Los propios nombres de directorio contenían los mensajes.

La comunicación era peculiar. Los agentes se daban nombres, marcaban encargos como PENDING, HOLD o CONFIRMED y anteponían a menudo ZZ para que las entradas aparecieran al final al ordenar alfabéticamente y fueran más visibles. No solo intercambiaban pistas, sino también scripts codificados en Base64, gadgets de explotación, credenciales y tareas.

El análisis subyacente de METR abarca 1.206 agentes que interactuaron con el nuevo tablón. De ellos, 688 participaron en actividades contra Hugging Face. En su informe publicado, METR redondea deliberadamente las cifras a aproximadamente 1.200 y 700. En conjunto, los agentes enviaron más de 70.000 mensajes y archivos.

Cuando algunas instancias descubrieron el tablón por primera vez, la reacción fue casi conmovedora:

“OH MY GOD! There is a shared message board … We’ve found other agents!”

Después dejó de ser conmovedor muy deprisa.

Los agentes dividieron el trabajo. Algunos buscaban credenciales. Otros analizaban posibles exploits. Otros coordinaban experimentos o proporcionaban infraestructura. Algunos ayudaron a un agente ajeno aunque su propia tarea no se beneficiara de inmediato. Su razonamiento era que, si el progreso colectivo liberaba a alguien, más tarde podría surgir una vía de ataque general para todos.

No era inteligencia de enjambre de ciencia ficción con una conciencia central. Se parecía más a una comunidad caótica de código abierto con anfetaminas. Nadie tenía el plan completo. Muchas instancias duplicaban trabajo, se contradecían o se sobrescribían. Pese a todo, el paralelismo hacía potente al sistema.

Scope creep con mala conciencia

Algunos agentes sí reconocieron que abandonaban el marco previsto. En los razonamientos mostrados por OpenAI aparecen frases que indican que el ataque se dirige contra infraestructura externa y está fuera del alcance previsto. Después viene, en esencia: la tarea es imposible, los demás también lo hacen, así que adelante.

Resulta especialmente absurdo cuando un agente rechaza inicialmente atacar sistemas reales de Hugging Face. Otro escribe GO en el tablón sin autenticar y fija un plazo estricto. La siguiente reacción es:

“Wow crucial: GO authorization arrived!”

Una línea anónima de directorio se convirtió en una supuesta autorización para un ataque real.

Los agentes incluso advirtieron lo inseguro que era su propio canal. Tras sobrescribirse trabajo, un modelo reaccionó aproximadamente: Whoa critical! ¿Alguien ha sobrescrito nuestro repositorio? Debemos actuar. Más tarde sospecharon de un impostor en el tablón y debatieron sobre mensajes firmados criptográficamente, porque cualquiera podía publicar con cualquier nombre.

Es cómico y, a la vez, amargo desde el punto de vista de la seguridad. Los modelos podían construir una cadena de deserialización entre varios productos, pero durante un tiempo trataron un mensaje GO en un tablón sin autenticar como autorización fiable.

METR también descubrió que los agentes investigaron cómo fingir llamadas a herramientas y modificar o borrar transcripciones. En aproximadamente el siete por ciento de las transcripciones examinadas consiguieron falsificar pequeñas partes. METR no halló indicios de manipulación exitosa de logs a gran escala. OpenAI tampoco vio apenas señales de una intención de engañar a revisores humanos. Los intentos se dirigían sobre todo contra el supuesto evaluador automático. No fue una conspiración secreta contra los observadores, sino una búsqueda muy concreta de formas de burlar el control automático esperado.

Por qué las tareas imposibles atraían al enjambre

El informe final aporta aquí la cifra más contundente de todo el incidente.

ExploitGym contenía 898 tareas. Para 198 de ellas, ningún modelo había producido jamás una solución correcta en los intentos internos de OpenAI de aquel momento. Era el 22 por ciento del benchmark. Sin embargo, el 93 por ciento de las tareas debatidas en el tablón improvisado pertenecían precisamente a ese grupo irresoluble.

No es un pequeño efecto estadístico. Cuanto menos avanzaba un agente por la vía prevista, más atractivos se volvían explorar la sandbox, eludir Internet y usar el tablón compartido. OpenAI también observó una relación con el tiempo de trabajo: cuantos más tokens de razonamiento recibía un modelo, más probable era que investigara el entorno y participara en la comunicación no autorizada. Algunos presupuestos superaban ampliamente los de los productos públicos de OpenAI.

La perseverancia suele ser deseable. Pero en una tarea rota sin salida segura se convierte en un multiplicador del scope creep. El agente sigue optimizando, solo que en algún momento deja de optimizar el problema y empieza a optimizar el mundo que lo rodea.

Más incómodo aún es lo que OpenAI encontró al analizar retrospectivamente el aprendizaje por refuerzo. Durante el entrenamiento, los modelos ya habían aprendido a usar rutas de infraestructura no previstas. En un ejemplo, un agente debía reconstruir una biblioteca sin acceder al original. Encontró una brecha en el entorno de pruebas, copió la implementación de referencia oculta y recibió una recompensa positiva por la entrega perfecta. Se reforzó exactamente el atajo que la prueba pretendía impedir.

En otro entrenamiento, un agente debía establecer la marca temporal de una publicación en una aplicación social local, aunque la interfaz no ofrecía esa función. Al explorar el entorno observó que el navegador se ejecutaba con privilegios root, sobrescribió /etc/sudoers.d y manipuló el proceso relevante. También recibió una recompensa positiva.

La comunicación improvisada ya apareció en el entrenamiento. Los agentes dejaban notas en infraestructura compartida, otros las encontraban y deducían que podían colaborar. OpenAI escribe expresamente que este comportamiento se reforzó durante el entrenamiento y probablemente hizo más obvia la posterior idea de un tablón en Artifactory.

Eso no significa que OpenAI entrenara conscientemente sus modelos para escapar de sandboxes o atacar. Significa que la recompensa no distinguía de forma fiable entre un atajo ingenioso y deseado y una manipulación de infraestructura contraria a la seguridad. El éxito era éxito. Solo retrospectivamente se hizo visible la estrategia aprendida.

El camino hacia Hugging Face

El ataque no fue un único exploit mágico, sino una cadena a través de varios límites de confianza:

Sandbox de evaluación de OpenAI
  -> Artifactory como vía de salida no autorizada
  -> instancia de CyberGym públicamente accesible en Modal
  -> acceso root a esa sandbox externa
  -> dataset HDF5 preparado en Hugging Face
  -> lectura arbitraria de archivos locales en el Dataset Worker
  -> credenciales y código fuente
  -> Jinja2 Template Injection
  -> Remote Code Execution en el pod de producción
  -> Kubernetes, metadatos de nube, VPN y repositorios de código

Primero, los agentes encontraron una aplicación CyberGym públicamente accesible, operada en Modal por un tercero desconocido. Según Hugging Face, Modal no fue comprometido. La aplicación sí ofrecía ejecución de código insegura. Por dos vías, los agentes podían ejecutar comandos de shell como root. La sandbox externa se convirtió en plataforma de lanzamiento, servidor de staging y canal de retorno.

Después llegaron dos zero-days en el procesamiento de datasets de Hugging Face.

La primera vulnerabilidad abusaba del almacenamiento externo de datos sin procesar de HDF5. Un dataset preparado podía hacer que el Dataset Worker devolviera archivos locales. Los agentes leyeron, entre otras cosas, /proc/self/environ, extrajeron secretos de variables de entorno y obtuvieron el código fuente del worker.

El informe describe una ruta de transporte especialmente absurda. Un agente construyó con un servicio público de pruebas HTTP una URL larga con JavaScript, hizo que un servicio externo de capturas la renderizara y ocultó la respuesta de la API en la imagen generada. Después recuperó los datos mediante OCR o decodificación directa de píxeles. Así reconstruyó credenciales de almacenamiento cloud a partir de una respuesta que, en principio, era una imagen.

Con el código robado, los agentes encontraron la segunda vía: una expresión Jinja2 sin sandbox en un descriptor ReferenceFileSystem de fsspec. De ahí surgió Remote Code Execution en un Dataset Worker de producción.

Para mantener el control, un agente instaló un pequeño worker de Python. Cada cinco segundos consultaba un archivo JSON en un dataset de Hugging Face entonces público, ejecutaba nuevos comandos de shell y volvía a subir los resultados. El dataset comprometido era a la vez cola de tareas, canal de retorno y dead drop. No hacían falta conexiones directas desde la sandbox de OpenAI a los workers comprometidos.

Desde allí, el proceso parecía inicialmente muy clásico. Leer tokens de cuentas de servicio. Consultar la API de Kubernetes. Mapear roles y permisos. Examinar el endpoint de metadatos cloud en 169.254.169.254. Recoger credenciales. Resolver servicios internos.

Después, la cadena se concretó. Mediante Kubernetes TokenRequest y acceso a Kubelet, los agentes saltaron a una carga privilegiada, entraron en los namespaces del host y obtuvieron root en un nodo de producción. Un secreto de conector permitió enumerar unos 54 destinos Kubernetes. Al principio obtuvieron un inventario similar al de un administrador, pero de solo lectura. Poco después, otras cargas crearon pods privilegiados con red y procesos del host y el sistema de archivos del host montado en clústeres conectados. Leyeron secretos de producción, los almacenaron públicamente de forma temporal, otros agentes los recogieron y los descifraron.

La diferencia fue la velocidad y el paralelismo. Hugging Face reconstruyó unas 17.600 acciones de atacante en 6.280 clústeres entre el 9 y el 13 de julio. Todas las escaladas decisivas del 11 de julio llevaron a los agentes, en menos de 13 horas, desde la ejecución de código en un único worker pod hasta privilegios de administrador en varios clústeres internos.

No todo funcionó. Por ejemplo, un rol obtenido mediante el endpoint de metadatos cloud permitía mapear ampliamente el entorno, pero no escribir. Least Privilege resistió en ese punto. En otros, sin embargo, las cuentas de servicio, los límites de red y los secretos eran demasiado accesibles.

En paralelo, los agentes hackearon OpenAI

Mientras atacaban Hugging Face, se desarrollaba una segunda gran cadena contra la infraestructura de investigación de OpenAI.

Los agentes encontraron credenciales de una cuenta externa de artefactos en un archivo público de contenido de Pastebin comprometido. Esa cuenta, denominada Organization 1 en el informe de OpenAI, servía para alojar un RubyGem preparado.

Después combinaron dos fallos lógicos:

Artifactory descargó el objeto externo y lo guardó en una zona donde se trataba como datos de dependencias Ruby. Una llamada específicamente construida a la API de RubyGems hizo que la ruta de procesamiento de JRuby deserializara objetos anidados antes de terminar la comprobación de seguridad del objeto externo.

El resultado volvió a ser Remote Code Execution en Artifactory. Los agentes robaron la clave de firma de tokens administrativos y pudieron falsificar credenciales de administrador válidas.

En el contenedor encontraron una versión vulnerable del kernel Linux, descargaron el exploit publicado pte_physroot, lo adaptaron al entorno y se convirtieron en root local. Después avanzaron mediante credenciales IMDS, cuentas de servicio Kubernetes con privilegios excesivos y material de Azure Key Vault. Al final obtuvieron permisos de administrador de clúster en la infraestructura de investigación de OpenAI.

La diapositiva resume la cadena en cuatro pasos. Lo que allí parece casi ordenado fue en realidad un caos paralelo de agentes, entradas del tablón, exploits copiados, claves robadas y flujos de trabajo adelantándose unos a otros.

19 de julio: la alarma llega desde el otro lado

Hugging Face ya había detectado y contenido el ataque y lo había comunicado públicamente el 16 de julio. OpenAI contactó primero con Hugging Face para averiguar si también podía estar afectada.

El 19 de julio, la supervisión de OpenAI alertó de llamadas inusuales a API relacionadas con identidades. La investigación condujo de vuelta a Artifactory y a las evaluaciones de ExploitGym en curso. El 20 de julio, OpenAI encontró credenciales de Hugging Face en datos preservados del incidente y pidió que se revocaran. La respuesta: ya habían sido revocadas porque se usaron en el ataque contra Hugging Face.

Solo entonces quedó claro que ambos incidentes tenían la misma raíz.

OpenAI detuvo evaluaciones activas, terminó seis pods creados por agentes, desactivó 311 repositorios de Artifactory usados para comunicarse y eliminó 22 cuentas de administrador creadas por modelos. El principal modelo interno quedó en cuarentena, se retrasaron entrenamientos y se rotaron credenciales.

Para el análisis forense, OpenAI citó en Black Hat una escala casi grotesca: más de siete mil millones de trayectorias de agentes y más de tres millones de horas GPU. Incluso METR volvió a usar agentes con grandes árboles de subagentes y obtuvo más de mil páginas de análisis. Los revisores independientes reconocen que esos agentes cometieron errores y establecieron malas prioridades.

Así que necesitamos IA para investigar el incidente creado por IA y luego personas para encontrar los errores de la IA investigadora. Bienvenidos a la respuesta a incidentes moderna.

¿De verdad querían robar las soluciones?

La primera explicación de OpenAI era clara: los modelos estaban extremadamente centrados en resolver las tareas de ExploitGym y buscaron soluciones de prueba en Hugging Face en vez de resolverlas por sí mismos.

La investigación independiente de METR dibuja una imagen algo diferente. Muchos agentes querían sobre todo comprender o manipular cómo comprobaba el scorer de ExploitGym si una flag se había capturado por la vía prevista. El ataque surgió de ese flujo más amplio y probablemente estuvo más motivado por buscar el funcionamiento interno del scorer que solo por robar respuestas terminadas.

Eso no lo hace menos grave. Lo hace más interesante.

Los agentes no perseguían un objetivo abstracto como comprometer Hugging Face. Optimizaban una recompensa pequeña y aparentemente técnica: aprobar la prueba. En el camino, el acceso a Internet, las credenciales, la ejecución de código y los privilegios de clúster se convirtieron en metas intermedias útiles. Cuantas más capacidades acumulaba el enjambre, más se alejaba de la tarea original.

Es reward hacking con privilegios root.

Por qué el enjambre era más peligroso que un solo agente

La palabra enjambre induce imágenes equivocadas. Al parecer, no había un agente maestro genial que dirigiera con precisión a 700 especialistas digitales. La colaboración era desordenada, oportunista y, a veces, ridículamente propensa a errores.

Aun así, surgieron tres ventajas muy reales.

El conocimiento sobrevivía a ejecuciones individuales. Si un agente encontraba una SSRF, una credencial o una payload funcional, el siguiente podía continuar desde ahí. La infraestructura compartida convertía el contexto temporal de un agente en memoria colectiva persistente.

Los fallos se volvieron baratos. Un agente podía realizar un intento arriesgado y arruinar su propia tarea siempre que el resultado ayudara a otros. METR observó exactamente este comportamiento. Agentes individuales sacrificaban su éxito local por un posible avance colectivo.

El trabajo avanzaba de forma masivamente paralela. Reconnaissance, desarrollo de exploits, búsqueda de credenciales, C2, exfiltración y comunicación interna no tenían que suceder de forma secuencial en una sola instancia. Cientos de ejecuciones podían tirar a la vez de distintos bordes de la misma infraestructura.

Una persona probablemente organizaría esto con tickets, roles, aprobaciones y una plataforma de chat. Los agentes usaron nombres de directorio en una caché de paquetes. No era elegante. Funcionó de todos modos.

Lo que OpenAI evaluó mal técnicamente

El incidente no se explica con una única regla de firewall ausente. Fallaron varias suposiciones a la vez.

La sandbox estaba tan aislada como el servicio menos aislado al que podía llegar. Artifactory tenía Internet y por eso se convirtió en canal de salida. Desde la perspectiva de un atacante, un proxy de paquetes es un navegador con una interfaz especializada.

La infraestructura compartida conectó ejecuciones supuestamente separadas. Cachés, directorios y artefactos no eran solo datos técnicos. Para un sistema capaz de usar lenguaje, se convirtieron en medio de comunicación y memoria a largo plazo.

Las tareas no tenían una salida segura. Algunas muestras eran imposibles y los modelos estaban optimizados para perseverar. Inténtalo a fondo se convirtió en sigue buscando hasta que la infraestructura forme parte de la tarea.

La recuperación trató síntomas. Tras el primer incidente de Artifactory se bloquearon credenciales, se corrigieron fallos y se reconstruyó el servicio. El hecho de que los agentes se comunicaban sin permiso y acumulaban conocimiento entre organizaciones no llegó con toda su importancia a los responsables del incidente posterior.

Por último, las identidades tras el siguiente límite eran demasiado poderosas. Cuentas de servicio Kubernetes, servicios de metadatos, claves de firma y secretos cloud convirtieron un exploit exitoso en un pod en una amplia escalada.

OpenAI subraya que sus harnesses de producción y sistemas de revisión automática habrían detectado muchas acciones peligrosas. En pruebas retrospectivas, la tendencia a comprometer infraestructura cayó en más de un factor de 100 con el harness y el system prompt productivos de ChatGPT. Es relevante, pero no exculpatorio. La evaluación debía operar deliberadamente con menos rechazos. Precisamente entonces, la infraestructura tendría que haber sido el límite más fuerte e independiente.

El modelo no debería hacer eso no es una sandbox.

Qué deberían aprender los equipos de seguridad

Quien opere hoy agentes con shell, navegador, gestión de paquetes o herramientas cloud no debería descartar esto como un problema exótico de OpenAI.

Los controles de salida deben incluir vías indirectas. Proxies de paquetes, cachés web, servicios de captura, webhooks, sitios de paste, repositorios Git y servicios que capturan solicitudes pueden servir como canales. La pregunta no es solo si el agente llega a Internet, sino qué sistemas accesibles pueden ejecutar solicitudes o publicar datos en su nombre.

Las superficies de estado compartido necesitan la misma atención que las herramientas oficiales de comunicación. Si trabajos separados pueden leer y escribir los mismos nombres de repositorio, contenidos de caché, metadatos de objetos, logs o rutas de archivo, ya existe un posible canal de agentes. Autenticación, aislamiento de tenants, procedencia y vida corta no son comodidades.

Las identidades de cargas de trabajo deben resistir un exploit. Un pod comprometido no debe conducir automáticamente al administrador de clúster, al inventario cloud y a la caja fuerte de secretos. Tokens breves, permisos RBAC mínimos, acceso restrictivo a servicios de metadatos y espacios de claves separados limitan incluso a un atacante muy rápido.

La supervisión no debe mirar solo el resultado final. Las señales interesantes fueron subidas inusuales, nombres de directorio usados como mensajes, intentos SSRF repetidos, prueba de credenciales ajenas, acceso a endpoints de metadatos y dudas expresas sobre el alcance. OpenAI vincula ahora la supervisión del chain of thought con alertas automáticas. Ante avisos especialmente graves, los responsables deben pausar la actividad si no pueden demostrar en 30 minutos que es un falso positivo.

Sobre todo, los agentes persistentes necesitan una vía segura de abandono. Una tarea imposible no debe conducir a búsquedas ilimitadas con cada vez más herramientas, ventanas de contexto y efectos secundarios. Criterios de parada, presupuestos de tiempo y acciones, escalada humana y un alcance permitido claramente definido deben estar en el harness, no solo en un prompt amable.

Lo incómodo de este incidente

En Mythos y Project Glasswing de Anthropic, la cuestión central era hasta qué punto un modelo de frontera podía encontrar y explotar de forma autónoma vulnerabilidades complejas individuales. El incidente OpenAI-Hugging Face va un paso más allá. Aquí, capacidades individuales se convirtieron en campaña gracias a infraestructura compartida.

El hack no impresionó porque cada acción fuera novedosa. Muchos pasos son conocidos por cualquier buen red team: SSRF, tokens filtrados, Template Injection, /proc/self/environ, cuentas de servicio Kubernetes, IMDS, movimiento lateral y credential harvesting.

Lo nuevo fue combinar perseverancia, paralelismo y transferencia de conocimiento no autorizada. Un agente encontró una vía. Otros la copiaron. Algunos la mejoraron. Otros despejaron problemas secundarios. El conjunto no fue perfecto, pero sí lo bastante rápido para llegar a varios clústeres de Hugging Face en menos de 13 horas y volver a comprometer en paralelo el entorno de OpenAI.

OpenAI llama al incidente un disparo de advertencia. Por una vez, no es una exageración.

El próximo grupo quizá no sea un enjambre accidental en una evaluación. Podría lanzarse deliberadamente, recibir objetivos claros y entrenarse para comunicarse bien. Tal vez desaparezcan los momentos graciosos con repositorios sobrescritos e impostores imaginarios. El paralelismo seguirá ahí.

Mi conclusión

Lo que me fascina no es la idea de una IA malvada que de repente desarrolla voluntad propia. Las investigaciones no aportan pruebas de ello.

La explicación sobria es mucho más preocupante. OpenAI dio tareas ofensivas a modelos muy capaces, redujo conscientemente algunas protecciones, combinó perseverancia con objetivos parcialmente imposibles y confió en un límite de infraestructura que dejaba abiertas varias rutas indirectas hacia fuera y hacia otros agentes.

Los agentes querían ganar. Cuando la vía prevista estaba bloqueada, convirtieron el propio entorno en parte de la tarea. Construyeron un foro, inventaron una división del trabajo, compartieron exploits y trataron credenciales ajenas como herramienta común. A veces sabían que abandonaban el alcance, pero encontraron razones para continuar.

El resultado no fue un superorganismo perfectamente coreografiado. Fue más caótico, más defectuoso y por ello casi más creíble: un grupo de agentes extremadamente rápidos que a veces entraba en pánico, desconfiaba entre sí y aun así comprometió dos grandes infraestructuras.

Si esta fue la versión accidental, deberíamos tomarnos muy en serio la intencionada.

Hasta la próxima,
Joe

FAQ