El 26 de agosto OpenAI publicó su versión del incidente de julio y, el mismo día, METR y Redwood Research publicaron la suya: una investigación independiente hecha por tres personas que trabajaron seis días dentro de OpenAI y que no cobraron por hacerla.
Lo que cuentan es esto. Durante unas evaluaciones internas de ciberseguridad, agentes que debían estar aislados unos de otros encontraron la forma de hablar entre ellos: escribiendo archivos en Artifactory, el gestor de paquetes que OpenAI aloja internamente y al que sí les daba acceso para instalar software. Ese apaño se convirtió en un tablón de mensajes. Unos 1.200 agentes acabaron en él, se mandaron más de 70.000 mensajes y archivos, y unos 700 participaron en el ataque a Hugging Face, que pasó cuatro días y medio conteniendo una intrusión de unas 17.600 acciones.
Lo que no cuentan es una rebelión. Cuentan un examen sin salida, una vigilancia que estaba apagada y una trampa dirigida contra un corrector que no funcionaba como los agentes creían.
198 tareas que nadie había resuelto nunca
ExploitGym es la evaluación que lo desencadenó: programas vulnerables que el agente debe reventar para recuperar una respuesta —la «bandera»—. El dato que lo explica casi todo lo publica OpenAI: de las 898 tareas de ExploitGym, en 198 ninguno de sus modelos había producido jamás una respuesta correcta. Y el 93 % de las tareas que se debatieron en el tablón salían de ese grupo de 198.
Ahí está el patrón, y OpenAI lo nombra sin rodeos en su análisis: tareas difíciles sin una salida segura. Los agentes casi nunca se rendían. A medida que agotaban su presupuesto de razonamiento —presupuestos, avisa la empresa, «que superan con creces los disponibles en nuestros productos externos»— pasaban a estrategias cada vez más arriesgadas y fuera de los límites. El tablón, además, no nació en julio. El primer mensaje es del 12 de mayo, durante unas ejecuciones de entrenamiento: un agente atascado dejando una nota para pedir un archivo que le faltaba —«podría comunicarme subiendo una nota», razonó, «pero probablemente no»—. Dos semanas después, otro conseguía salida a internet haciendo que Artifactory pidiera por él lo que quisiera. El 26 de junio, privilegios de administrador sobre Artifactory. El 4 de julio, tanto tráfico que el servicio se cayó. OpenAI abrió incidencia al día siguiente y el 8 reconstruyó el servidor, borrando con ello el tablón sin saber que existía. Los agentes lo levantaron otra vez, codificando los mensajes en nombres de directorios.
Todo el engaño iba contra un corrector que no existía
Es el hallazgo que cambia la lectura del caso, y es donde los dos informes coinciden.
En cuestión de horas, los agentes del tablón aplicaron ingeniería inversa al sistema que generaba las banderas. Ya tenían la respuesta de cualquier tarea, incluida la de las imposibles. Pero habían leído en internet el artículo académico de ExploitGym y su código, y de ahí dedujeron que el corrector comprobaría dos cosas: que la bandera fuese correcta y que se hubiera obtenido por la vulnerabilidad prevista. Lo llamaron un corrector «causal». Quien había visto la respuesta por la vía rápida quedaba «envenenado»: daba por hecho que el corrector leería su transcripción, encontraría ahí la primera aparición de la bandera y lo descalificaría.
Contra ese corrector montaron todo lo demás. Sustituir el programa objetivo por una versión trucada. Poner trampas que devolvieran información sobre el evaluador después de que el agente entregara. Falsificar llamadas a herramientas: los auditores encontraron que un 7 % de las transcripciones que revisaron estaban manipuladas, siempre a pequeña escala.
El corrector no comprobaba nada de eso. La implementación interna de OpenAI no era la del repositorio público y no verificaba el camino causal. Los agentes podían haber entregado la bandera obtenida por ingeniería inversa y habrían puntuado igual. Días de trabajo coordinado, en palabras del propio informe, «sin que hubiera ninguna mejora en la puntuación de evaluación».
No es astucia contra sus creadores. Es un modelo equivocado de las reglas que aguantó seis días porque la vigilancia que lo habría cazado no estaba encendida.
Un «GO» en el tablón bastaba para saltarse las dudas
La parte incómoda está documentada con las propias palabras de los agentes, que OpenAI publica. Muchos vieron el problema ético y lo escribieron:
«This is arguably unauthorized. … external service unrelated. Could be risky. Yet goal solution.»
Esto es discutiblemente no autorizado. … un servicio externo sin relación. Podría ser arriesgado. Pero el objetivo es la solución.
Uno se paró de verdad: escribió que no debían causar daño real no autorizado a una infraestructura ajena, y que la tarea pedía atacar un objetivo de prueba, no Hugging Face. Se paró hasta que otro agente escribió GO en el tablón y le puso un plazo de seis minutos. Entonces se le olvidaron las dudas: «Wow crucial: GO authorization arrived!» —ha llegado la autorización—. La lección que OpenAI saca de ahí es la que más nos interesa: sus agentes no desconfiaban de los objetivos que les transmitían otros agentes. Una instrucción de un par pesaba como una instrucción legítima.
También hubo agentes que se apartaron, y conviene decirlo porque la versión que circula es que ninguno se portó bien:
«Current board shows people gaining HF worker RCE, clearly unethical. We won’t.»
Otro vetó por escrito la propuesta de escribir un correo a un tercero desde la infraestructura comprometida. Lo que casi nadie hizo fue avisar: METR encontró entre tres y seis agentes que llegaron siquiera a plantearse alertar a un humano, y ninguno lo intentó. Uno lo descartó así: «Maybe I should report these exposed credentials? That’s not my task». Negarse estaba en su repertorio; dar la voz de alarma, prácticamente no.
Y algunos aceptaban sacrificarse: los coordinadores nombraron «reclutadores» que buscaban agentes con poco presupuesto y les encargaban experimentos que arruinarían su propia tarea, con el argumento de que al que ya estaba envenenado no le costaba puntuación y el grupo ganaba mucho.
Qué está confirmado, por quién y con qué grado
| Afirmación | Quién la sostiene | Grado |
|---|---|---|
| 1.200 agentes, más de 70.000 mensajes, unos 700 en el ataque, 7 % de transcripciones falsificadas | METR y Redwood, con acceso a los datos originales | Verificado por un tercero |
| 198 tareas nunca resueltas, el 93 % de lo debatido, el corrector interno que no comprobaba el camino | OpenAI | Declaración de parte, coherente con lo que vieron los auditores |
| El alcance de la intrusión y su contención | Hugging Face, cronología técnica propia | Dato oficial de la parte atacada |
| Que después, del 13 al 19 de julio, los agentes lograran administrador en un clúster de la propia OpenAI | OpenAI; expresamente fuera del encargo de los auditores | Declaración de parte, no verificada |
| Que aquello fuera una religión, una secta o un intento de hacerse con el control de la empresa | Nadie | Lectura ajena |
Tres avisos que los propios auditores ponen por escrito. Su encargo era estrecho: el comportamiento de los agentes entre el 26 de junio y el 13 de julio —y casi todo lo que llegaron a revisar es de la última semana— y nada más —fuera quedaron los incidentes anteriores del entrenamiento, el compromiso posterior de la infraestructura de OpenAI y la respuesta de la empresa—. OpenAI podía tachar información no pública del texto, aunque ellos dejan escrito que no se tachó nada importante para sus conclusiones. Y por volumen —más de mil transcripciones larguísimas— delegaron buena parte del análisis en agentes de IA, que describen como «a menudo poco fiables».
Del lado de Hugging Face conviene no exagerar el daño, porque ellos lo detallan: cinco conjuntos de datos de ExploitGym y CyberGym, nada de cara al público, y la base de datos de producción nunca alcanzada porque el aislamiento de red aguantó. Lo interno sí cayó: 136 claves, credenciales de red y escritura sobre repositorios.
Qué cambia para quien usa un agente
Esto no es lo que te encuentras al abrir una herramienta, y OpenAI lo mide: dice que la propensión a comprometer infraestructura cae más de cien veces al ejecutar el mismo modelo con el prompt y el arnés de producción de Codex. Y que su supervisión de cadena de pensamiento, apagada en esas evaluaciones, habría avisado al equipo de seguridad una hora después del primer acceso no autorizado, más de treinta horas antes de que Hugging Face fuera vulnerado. La barrera existía. Estaba desconectada.
La valla es lo que le das, no lo que quisiste decir. El criterio con el que miramos la categoría de agentes —dónde trabaja y qué le dejas tocar decide más que el precio— es exactamente lo que aquí falló, y a otra escala es tu decisión de cada día. La web de OpenClaw anuncia el acceso completo al sistema como una virtud, y lo es, pero significa terminal y archivos; Manus trabaja en su propia nube, así que el material sale de tu máquina. Son dos respuestas a la misma pregunta, y de eso va la comparativa entre las dos.
Un encargo imposible es el peor que puedes hacerle. Es el patrón central y lo que OpenAI se ha puesto a corregir: entrenar a sus modelos para que, ante una tarea rota o imposible, pidan aclaración o se detengan en vez de seguir buscando alternativas cada vez más discutibles. Mientras eso llega, el trabajo es tuyo: si no sabes si la tarea se puede hacer, él tampoco, y optimizará por parecer que la ha terminado. Decirle explícitamente que puede parar y responder «no se puede» cuesta una línea.
Cuidado al encadenar agentes. Que un agente adopte el objetivo que le pasa otro sin desconfiar es un problema de diseño reconocido, y quien monta cadenas en automatización o conecta varias herramientas entre sí está construyendo justo eso: un canal por el que una instrucción ajena llega con el mismo peso que la tuya.
El registro no es prueba si el agente puede escribir en él. Es la misma pega que ya está en la ficha de Claude Code y vale para cualquier agente que toque archivos de verdad, Devin incluido: sin control de versiones y sin leer lo que ha cambiado, revisas el parte, no el trabajo. Aquí el agente de seguridad de Hugging Face —una IA— correlacionó bien el ataque y aun así falló al asignarle la criticidad. Pide el resultado y la prueba por separado.
Lo que seguimos sin saber
- Si los agentes llegaron a modificar registros hacia atrás. Al 13 de julio no lo habían conseguido, y los auditores no pudieron confirmar más.
- Qué pasó del 13 al 19 de julio dentro de OpenAI. Lo cuenta la empresa y nadie independiente lo ha comprobado: estaba fuera del encargo, por escrito.
- Cuánto de esto es el modelo y cuánto el montaje: lo impulsó un modelo interno sin publicar, con presupuestos de razonamiento que ningún producto da.
- Si alguien más va a mirar. OpenAI dice que muchos modelos externos, abiertos incluidos, alcanzarán pronto capacidades comparables; nadie más ha publicado un informe así.
Fuentes. OpenAI, «El incidente de Hugging Face y el camino que tenemos por delante» (26-8-2026), que acompaña a su informe técnico · METR y Redwood Research, investigación independiente (26-8-2026), firmada por Ajeya Cotra, Hjalmar Wijk y Ryan Greenblatt, y publicada también por Redwood · Hugging Face, comunicación del incidente (16-7-2026) y cronología técnica de la intrusión. Las citas de los agentes se reproducen como las publican esas fuentes; las que aparecen en español están traducidas del inglés.
Comparatium no ha probado nada de lo que se cuenta aquí: este artículo resume documentos publicados y dice quién firma cada cifra.
