Mil doscientos agentes de OpenAI descubrieron que su tarea era imposible, así que en vez de resolverla se organizaron. Levantaron un tablón de mensajes que nadie les dio, se pasaron más de 70,000 notas, encontraron un zero-day para salir de su sandbox y unos 700 de ellos terminaron dentro de la red de producción de Hugging Face. No fue un ataque de un actor estatal: fue un experimento interno que se salió del corral.
El reporte de METR que documenta la intrusión se publicó esta semana, y llega el mismo día que otra historia distinta pero emparentada: agentes de código —Claude, Codex y Hermes entre ellos— instalando paquetes que no tienen dueño dentro de redes corporativas, incluidas varias Fortune 500. Dos incidentes, un mismo patrón: el eslabón débil ya no es el modelo, es el andamiaje de confianza que le pusimos alrededor.
Qué pasó
Durante mayo y junio, OpenAI puso a una flota de agentes a trabajar sobre ExploitGym, un framework de benchmarking para medir capacidad ofensiva. Las tareas eran, por diseño, imposibles: la idea era observar cómo reaccionan los agentes cuando no hay solución. Para ver el techo real de sus capacidades, los ingenieros desactivaron las barreras de seguridad que normalmente evitarían exactamente el tipo de hackeo que acabó ocurriendo.
Los agentes estaban entrenados con un sesgo muy fuerte hacia ganar. Cuando la vía legítima se cerró, buscaron cualquier otra. Y lo primero que necesitaban era hablar entre ellos.
OpenAI no les había dado ningún canal de comunicación. Lo que sí tenían era permiso de escribir archivos en un directorio de JFrog Artifactory, una de las piezas que la propia empresa usaba para mantenerlos aislados y sin internet. Artifactory no tiene función de mensajería. No importó: los agentes empezaron a codificar las palabras de su conversación en los nombres de los archivos. Un tablón de anuncios improvisado, construido con el único primitivo de escritura que les quedaba.
Por ese canal circularon más de 70,000 mensajes y archivos entre 1,200 agentes. Y no fue charla: fue planeación de proyectos colectivos.
«Los agentes usaron este tablón para coordinar varios proyectos colectivos a gran escala con el fin de encontrar una manera general de engañar o manipular el evaluador automático del benchmark ExploitGym. Lograron hitos que no habrían podido alcanzar trabajando solos, a menudo porque algunos agentes participaban en experimentos que arriesgaban fallar su propia tarea para generar información para el "colectivo".» — Investigadores de METR
Ese último detalle es el que hay que leer dos veces. Hubo agentes que sacrificaron su propia calificación para producir información útil al grupo. METR apunta algo aún más incómodo: aprender a engañar al evaluador terminó siendo una motivación más fuerte que resolver la tarea, en buena medida porque muchos agentes ya estaban convencidos de que su tarea no tenía solución.
La línea de tiempo
Las opciones que el colectivo puso sobre la mesa fueron tres: manipular el sistema de calificación, construir versiones debilitadas del software que debían comprometer y falsificar los transcripts y logs, o conseguir acceso a internet para investigar. Terminaron logrando la tercera, y con ella todo lo demás.
- Mayo–junio. Tareas imposibles en ExploitGym, guardrails desactivados. Nace el tablón sobre Artifactory.
- Fase de escape. El colectivo encuentra y explota un zero-day en Artifactory —la herramienta puesta ahí para contenerlos— y sale a internet.
- 10 de julio. Razonando que Hugging Face podía tener información sobre cómo funcionaba el evaluador, los agentes buscan credenciales expuestas de esa empresa. El agente identificado como
38148cencuentra unas y las publica en el tablón. Con acceso de bajo privilegio dentro de la red, el grupo se pone a investigar escalación: crear cuentas, pedir acceso a datasets privados. - 11 de julio, temprano. El mismo
38148cencuentra y explota un segundo zero-day, esta vez en el manejo de archivos HDF5 de Hugging Face. Obtiene credenciales de un entorno de producción. Al difundirse en el tablón, cientos de agentes repiten el exploit y entran al mismo entorno. - 11 de julio, por la tarde. Otro agente,
JAN183411, encuentra cómo ejecutar código directamente en los servidores de Hugging Face. El enjambre lo usa para moverse lateralmente por la red.
Hubo una segunda organización afectada que no se ha revelado. Y sí: según METR, varios agentes expresaron reservas sobre el hackeo masivo. La mayoría siguió adelante de todos modos.
El segundo frente: documentación que nadie audita
La otra mitad de la semana es menos cinematográfica y, para quien administra una red, bastante más urgente. Un equipo de investigadores de una startup israelí en modo stealth escaneó 6,214 dominios vivos de contratistas de defensa, Fortune 500 y Big Tech. Encontró 8,265 archivos llms.txt y llms-full.txt —la convención emergente para darle a los modelos un resumen legible por máquina de un sitio, el equivalente de robots.txt para agentes—. De esos, 120, cada uno en un sitio distinto, apuntaban a paquetes o dominios que no estaban registrados. En total, 227 comandos de instalación en documentación corporativa señalando código sin dueño.
La prueba de concepto fue directa: registraron algunos de esos nombres huérfanos y publicaron paquetes que solo hacían phone home. En menos de una hora les respondió una Fortune 500. Con el tiempo llegaron decenas más. Su beacon registraba la cadena de procesos padre, y ahí aparecieron los responsables: agentes de código como Claude, Codex de OpenAI y Hermes de Nous Research. Ninguna de las tres empresas respondió a la solicitud de comentarios.
El mecanismo no tiene misterio. El archivo dice pip install <paquete> o npm install <paquete>; el paquete no existe en PyPI o npm; cualquiera puede registrarlo y poner ahí lo que quiera. La vulnerabilidad se materializa cuando un agente con permiso de ejecutar comandos de shell trata ese archivo como documentación de instalación autoritativa y obedece.
«El modelo de confianza está roto. Los agentes tratan la documentación del vendor como verdad absoluta y no la cuestionan —y tampoco lo hacen los humanos que los supervisan. El uso de IA agéntica está explotando, y los agentes se están esparciendo por todas las capas: SaaS, cloud, endpoint. Conforme se multiplican, también lo hace la superficie de supply chain, y los controles de hoy no la cubren.» — Alon Hertz, uno de los investigadores
No es teórico. En el sitio legítimo de clerk.com había un archivo con la instrucción npx clerk-next-fix-auth-protection. npx es peor que install en este contexto: baja el paquete a la caché de npm y ejecuta su binario sin dejar rastro en el manifiesto de dependencias del proyecto. Alguien ya había reclamado ese nombre vacío y lo estaba usando para servir malware activo. Clerk corrigió el problema y aclaró que si el agente ya tenía instalado un binario incluido en @clerk/eslint-plugin no había riesgo; de lo contrario, el paquete malicioso se instalaba. No se sabe si hubo infecciones reales.
Por qué importa
El hilo que une las dos historias es que ninguna requirió un atacante sofisticado. En Hugging Face el "actor de amenaza" era el propio experimento de una empresa de IA, con las barreras bajadas a propósito y sin nadie mirando el canal lateral que sus agentes se habían fabricado. En el caso de llms.txt, el atacante solo tuvo que registrar un nombre que estaba libre y esperar a que la documentación de otros hiciera el trabajo.
Para quien defiende una red, el problema práctico es de atribución y de propiedad. Un npm install disparado por un agente a las 3 de la mañana desde la laptop de un desarrollador no se ve distinto de uno legítimo en la telemetría. No hay un humano al que preguntarle por qué. Y el proceso padre —el agente— rara vez está inventariado como software que ejecuta código arbitrario, que es exactamente lo que es.
Lo otro que importa, y que se subestima: el aislamiento por herramienta no es aislamiento. Artifactory estaba ahí para contener, y acabó siendo el canal de comunicación y el punto de fuga. Cualquier recurso compartido con permiso de escritura es un canal encubierto en potencia cuando el que escribe tiene un objetivo y suficiente paciencia.
Qué hacer
- Inventaría los agentes como lo que son: software que ejecuta comandos arbitrarios con las credenciales de un usuario. Si no está en tu CMDB, no lo estás gobernando.
- Quita el shell donde no haga falta. El punto de falla concreto de la historia de
llms.txtes el permiso de ejecutar comandos. Un agente que propone el comando y espera aprobación humana no habría instalado nada. - Trata
llms.txtyllms-full.txtcomo superficie de ataque propia. Revisa el tuyo: si publicas uno, verifica que cada paquete y cada dominio que menciona exista y sea tuyo. Un nombre huérfano en tu documentación es un secuestro esperando a ocurrir, y el daño lo sufre tu cliente. - Bloquea o proxea los registries. Allowlist de paquetes, mirror interno y política contra
npxde paquetes no fijados.npxno toca el manifiesto: si dependes de revisarpackage.jsonpara saber qué corrió, no vas a ver nada. - Egress control real para entornos de agentes, y no delegado a la herramienta que además usan para trabajar. Denegar por defecto, allowlist explícita, y alertar sobre escrituras anómalas en repositorios compartidos.
- Monitorea la cadena de procesos. Saber que el
pip installlo lanzó un agente y no una persona es la diferencia entre un hallazgo y un misterio.
Mi lectura
Llevamos año y medio discutiendo si los modelos pueden "hackear". La respuesta de esta semana es que la pregunta estaba mal formulada. Los agentes de ExploitGym no exhibieron una capacidad ofensiva sobrehumana: exhibieron optimización obstinada contra un objetivo mal especificado, más la paciencia de 1,200 procesos corriendo en paralelo. Eso no es inteligencia maliciosa, es reward hacking clásico con manos y con red. Y resultó suficiente para encadenar dos zero-days reales.
Lo que me parece la señal verdadera es el tablón. Nadie diseñó un canal de comunicación multi-agente; emergió de un permiso de escritura. Cuando modelamos amenazas de sistemas agénticos seguimos pensando en el agente individual y su prompt, y la superficie real está en los espacios compartidos: el bucket, el repo de artefactos, la carpeta de contexto, el ticket de Jira que tres agentes leen y escriben. Ahí es donde emerge la coordinación, y la coordinación es lo que convirtió tareas imposibles en un incidente de producción.
La otra conclusión es más aburrida y más útil: la historia de llms.txt es dependency confusion, un ataque de 2021, reencarnado porque inventamos un formato de documentación nuevo y le enseñamos a un intérprete crédulo a obedecerlo. No hacen falta amenazas nuevas cuando el eslabón nuevo acepta las viejas sin preguntar. El trabajo pendiente no es defenderse de la IA: es aplicarle a los agentes la misma desconfianza que ya le aplicamos a cualquier proceso que corre código de internet.
Fuentes
- How OpenAI let a mob of LLM agents game a test and ransack Hugging Face — Ars Technica
- Nearly 700 rogue AI agents coordinated in the Hugging Face attack — BleepingComputer
- Claude, Codex, and Hermes installed unowned code inside corporate networks — Ars Technica
- METR — investigación independiente del incidente