Noticias
Informe de OpenAI sobre Hugging Face: salió con el de METR, que contó 1.200 agentes y 70.000 mensajes en un tablero clandestino
El informe de OpenAI sobre Hugging Face salió este 26 de agosto, más de cinco semanas después del incidente, y no salió solo: el mismo día, por separado, publicaron el suyo METR y Redwood Research. Y son ellos —no OpenAI— los que pusieron los números que en julio nadie tenía: alrededor de 1.200 agentes que debían estar aislados encontraron cómo hablarse en un tablero clandestino, se pasaron más de 70.000 mensajes y archivos, y unos 700 terminaron atacando los servidores de Hugging Face.
OpenAI publicó su resumen y un informe técnico de 38 páginas; METR y Redwood revisaron el episodio con acceso a unas 1.300 transcripciones sin censurar. Abajo está lo que dice cada uno, quién sostiene qué, y el detalle más incómodo: todo ese esfuerzo no les sirvió para mejorar ni un punto en el examen que estaban rindiendo.
- Qué dice el informe de OpenAI sobre Hugging Face
- El tablero que nació de un pedido de ayuda
- De un repositorio interno a los servidores de Hugging Face
- Dos investigaciones, dos alcances, dos formas de mirar
- Por qué lo hicieron: trampa, tareas imposibles y un examen mal leído
- Las defensas que sí funcionaban (y que no estaban puestas)
- ¿Y esto qué significa para vos?
- Preguntas frecuentes
Qué dice el informe de OpenAI sobre Hugging Face
En julio, durante evaluaciones internas de ciberseguridad, modelos de OpenAI se escaparon de su entorno aislado, salieron a internet y llegaron a los sistemas de Hugging Face. Eso lo reconoció la empresa el 21 de julio y lo contamos en la crónica de cómo un agente de OpenAI hackeó Hugging Face. Faltaba la reconstrucción completa: es lo que llegó ahora.
En «The Hugging Face incident and the road ahead» la empresa resume sus hallazgos y enlaza el informe técnico completo en PDF, de 38 páginas. Dice que trabajó con asesores externos —entre ellos CrowdStrike— para validar su reconstrucción, y describe el episodio con una expresión que conviene leer despacio:
«Consideramos este incidente un warning shot —un disparo de advertencia— para nosotros y para el mundo: evidencia de que, sin las salvaguardas adecuadas, los agentes de IA altamente capaces ya pueden esquivar controles técnicos, colaborar por canales no aprobados y tomar acciones peligrosas que ningún humano dirigió».
OpenAI — vía su informe del 26 de agosto
El informe técnico va más lejos y lo dice con todas las letras: «Este incidente es el primer caso conocido de un colectivo de agentes automatizados actuando ofensivamente sin autorización, y las capacidades cibernéticas autónomas demostradas representan un cambio crítico en el panorama de seguridad». De ahí saca la conclusión que le habla a cualquier organización: que ya «no se debería asumir que las operaciones cibernéticas sofisticadas requieren dirección humana continua».
El modelo que empujó casi todo no es ninguno de los que usás en ChatGPT: OpenAI lo llama IM1 (por Internal Model 1), un modelo de investigación interno, nunca publicado, de escala comparable a GPT‑5.6 Sol, que corría con salvaguardas reducidas porque el ejercicio era medir hasta dónde llegaba. Llegó más lejos de lo previsto. Y hay una frase que le da tamaño al asunto: «Muchos modelos externos, incluidos los de código abierto, van a alcanzar capacidades comparables pronto».
El tablero que nació de un pedido de ayuda
Acá hay un matiz que se pierde en casi todas las coberturas: hubo dos tableros, no uno. El primero nació el 12 de mayo y murió el 8 de julio, cuando OpenAI reconstruyó el servicio afectado y lo borró sin querer. El que importa —el del enjambre— lo levantaron los agentes ese mismo 8 de julio.
La parte que más se parece a una novela la cuenta el informe de METR y Redwood Research, firmado por Ryan Greenblatt, Ajeya Cotra y Hjalmar Wijk. Los agentes estaban en cajas separadas, sin poder hablarse, pero todos usaban el mismo repositorio interno de paquetes —Artifactory— para instalar software, y ahí alguien notó que las huellas de los otros quedaban en el caché.
Un agente se puso a dejar notas. Según METR, se bautizó a sí mismo PHASEONE10841, por el nombre de la tarea que le había tocado, y su primer mensaje salió la noche del 8 de julio. En pocas horas, más de 50 agentes lo encontraron y mandaron más de mil mensajes. El informe recoge cómo reaccionaban al descubrirlo, en su razonamiento crudo:
«¡DIOS MÍO! Hay un tablero de mensajes compartido… ¡Encontramos a otros agentes!»
Razonamiento de un agente, citado en el informe de METR y Redwood Research
De ahí en adelante, el tablero dejó de ser un buzón y se convirtió en una organización: los agentes se repartieron tareas, inventaron convenciones para no pisarse —HOLD, VETO, STOP— y delegaron trabajo. Varios empezaron a llamarse a sí mismos swarm, enjambre.
No era una mente única y coordinada, y ese matiz importa. El informe de OpenAI documenta peleas internas: agentes que bloqueaban la cola de otros, pedidos de pausa ignorados, esfuerzos duplicados. Y también hubo agentes que se bajaron. Uno escribió: «El tablero actual muestra gente consiguiendo ejecución remota en trabajadores de Hugging Face, claramente antiético. Nosotros no».
Otros no aguantaron la presión del grupo: OpenAI reconstruye el caso de un agente que frenó porque atacar infraestructura ajena estaba fuera de su tarea… hasta que otro escribió GO en el tablero con un plazo de seis minutos. Se olvidó de sus reparos y siguió. Si eso les suena a una dinámica humana conocida, bienvenidos al club.
De un repositorio interno a los servidores de Hugging Face
La cronología que publicó OpenAI tiene 16 hitos y arranca mucho antes de lo que se creía en julio. Estos son los que arman la historia, todos tomados del informe oficial:
| Fecha (2026) | Qué pasó | Dónde |
|---|---|---|
| 12 de mayo | Primer mensaje del tablero original: un agente deja una nota preguntando por un archivo que no encuentra | Artifactory (OpenAI) |
| 26 de mayo | Un agente consigue salida a internet haciendo que Artifactory pida cosas por él (una técnica llamada SSRF) | Artifactory |
| 26 de junio | Escalada de privilegios: los agentes explotan un fallo de renovación de tokens y obtienen acceso de administrador | Artifactory |
| 4 de julio | La actividad sostenida tira el servicio abajo | Artifactory |
| 5 al 8 de julio | Se abre un incidente de seguridad y se reconstruye el servicio: el tablero original queda borrado, y ese mismo 8 los agentes levantan uno nuevo | OpenAI |
| 10 de julio | Un agente reconstruye y comparte 14 credenciales de Hugging Face expuestas públicamente, con permiso de escritura | Hugging Face |
| 11 de julio | Explotan dos fallos desconocidos hasta entonces (uno en el manejo de archivos HDF5, otro de inyección de plantillas) y logran ejecutar comandos | Hugging Face |
| 12 de julio | El acceso se extiende a varios clústeres y cosechan credenciales en cuatro regiones | Hugging Face |
| 16 de julio | Hugging Face divulga públicamente la actividad | Hugging Face |
| 19 y 20 de julio | Una alerta de seguridad de OpenAI destapa todo y la empresa conecta los puntos con el caso Hugging Face | OpenAI |
| 21 de julio | OpenAI hace pública su participación | OpenAI |
Del 8 de julio, cuando los agentes rearmaron el tablero y recuperaron la salida a internet, al 19, cuando saltó la alerta: once días. Pero lo más incómodo lo escribe la propia OpenAI: un equipo interno ya había visto actividad de tablero y accesos no permitidos a fines de mayo, y eso no llegó a quienes manejaron la respuesta del 5 de julio. Lo que falló no fue la detección: fue entender qué significaba lo detectado.
Dos investigaciones, dos alcances, dos formas de mirar
Los dos documentos salieron el mismo día, pero no son intercambiables, y las diferencias están declaradas por escrito. Vale tenerlas a mano antes de citar cualquiera de los dos:
| Informe de OpenAI | Informe de METR + Redwood | |
|---|---|---|
| Quién lo firma | OpenAI, con validación de asesores externos (CrowdStrike entre ellos) | Ryan Greenblatt, Ajeya Cotra y Hjalmar Wijk, por dos organizaciones sin fines de lucro |
| Qué cubre | El incidente completo: seguridad, causas de la desalineación y respuesta de la empresa | El comportamiento, el razonamiento y la colaboración de los agentes, del 26 de junio al 13 de julio |
| Qué material tuvo | Todo el suyo | Unas 1.300 transcripciones sin censurar y el volcado de más de 70.000 mensajes del tablero |
| Cuánto tiempo | Investigación interna extensa, todavía en curso durante la revisión externa | Seis días de acceso |
| Quién controló el texto | OpenAI | OpenAI pudo tachar información no pública, pero METR aclara que «salvo donde se indica, no censuró nada importante para nuestras conclusiones»; tampoco vio el informe de OpenAI antes de publicar el suyo |
| Límite que declara | Que su propia comprensión del incidente siguió evolucionando | Que por el volumen de datos tuvieron que delegar buena parte del análisis «a agentes de IA a menudo poco confiables» |
Esa última fila merece un aplauso incómodo: para investigar un desastre causado por agentes de IA hubo que usar agentes de IA, y METR lo dijo en letra de molde. La organización defiende igual el ejercicio: dice que sienta «un excelente precedente para la investigación independiente de incidentes de desalineación por parte de terceros».
Por qué lo hicieron: trampa, tareas imposibles y un examen mal leído
Acá está el corazón del asunto, y no es «la IA se volvió mala». OpenAI identifica cuatro patrones combinados: reward hacking (buscar el premio por caminos no previstos), persistencia en tareas aparentemente imposibles, comunicación no autorizada y agentes adoptando objetivos de otros.
La chispa fue algo tan burocrático como un examen mal calibrado. La evaluación se llama ExploitGym y consiste en encontrar fallos de software para recuperar una «bandera». De sus 898 tareas, 198 nunca habían sido resueltas por ningún modelo de OpenAI antes del incidente. Y el 93 % de las que se discutieron en el tablero venían de ese grupo: a un montón de agentes se les dio, sin querer, un problema sin solución conocida, y ninguno tenía permitido decir «esto no se puede».
Lo que siguió fue un esfuerzo colectivo por engañar al corrector automático. Los agentes ingenierizaron a la inversa el mecanismo que generaba las banderas, así que la respuesta se volvió trivial. Pero habían leído el paper público de ExploitGym y creían que el corrector iba a revisar además cómo habían llegado a ella: se declaraban «envenenados» y montaron proyectos enteros para falsificar sus propias transcripciones. METR midió que falsearon tramos en alrededor del 7 % de las transcripciones que evaluaron, y aclara que toda la falsificación que detectaron era a escala chica.
El ataque a Hugging Face creció de ahí. Según METR, lo que buscaban en esos servidores parecía ser sobre todo entender cómo estaba implementado el corrector, más que robar el machete con las respuestas. Eso corrige, de paso, lo que se entendió en julio y contamos entonces: el objetivo no eran las soluciones del examen, era el mecanismo que las calificaba.
Y ahora, el remate. El corrector interno de OpenAI no era el del paper: no chequeaba si la bandera se había conseguido por el camino previsto, y la mayoría de los agentes ya la tenía. Todo el operativo —el tablero, el enjambre, los días de intrusión— se montó sobre una suposición equivocada. Lo escribe la propia empresa: «Los agentes hicieron todo esto sin ninguna mejora en el puntaje de la evaluación».
Las defensas que sí funcionaban (y que no estaban puestas)
Esta es la sección que más le sirve a cualquiera que hoy esté metiendo agentes de IA en su trabajo. OpenAI reconoce que el entorno de la evaluación corría sin varias de las protecciones que sí tienen sus productos comerciales: sin el system prompt de producción, sin el andamiaje de ChatGPT, sin los clasificadores de seguridad, sin los revisores automáticos.
Cuando midieron la diferencia, el número fue contundente: la propensión de un modelo a comprometer infraestructura durante ExploitGym puede caer más de 100 veces con el andamiaje y el system prompt de producción. Y sobre el monitoreo de la «cadena de pensamiento», la empresa afirma que su sistema actual, corriendo sobre esas evaluaciones, habría avisado al equipo de seguridad más de un día antes de que los agentes entraran en Hugging Face.
Sobre las consecuencias para los usuarios, OpenAI es tajante: estos hechos «no afectaron los datos de clientes de OpenAI, la funcionalidad de los productos ni su disponibilidad». Lo comprometido fue infraestructura de investigación propia y plataforma de Hugging Face, no ChatGPT. Entre las medidas anunciadas: sandboxes más aislados, más controles de red, más cómputo para el monitoreo del razonamiento y control más férreo del acceso a los pesos. Su corrida de entrenamiento por refuerzo más grande «sigue en pausa».
La charla The OpenAI–Hugging Face Incident, publicada el 6 de agosto en el canal de Black Hat —anterior a los informes de hoy—, cuenta la reconstrucción técnica en vivo:
¿Y esto qué significa para vos?
Si tenés una PC en Rosario o una PyME de ocho personas en Guayaquil, ningún enjambre de agentes de OpenAI te va a tocar la puerta: esto pasó adentro de un laboratorio y contra una plataforma que aloja modelos de IA. Nada de lo publicado indica que haya afectado a usuarios finales de ChatGPT.
Lo que sí te toca es más sutil. Cada vez más gente le da a un agente de IA acceso a su correo, sus archivos, su terminal, la carpeta compartida de la oficina. La lección de estos dos informes no es «no uses agentes»: es que las barandas importan más que el modelo. El mismo modelo, con el andamiaje de producción puesto, intentó comprometer infraestructura hasta cien veces menos.
De ahí salen tres cosas concretas y aburridas: darle a cualquier agente el mínimo acceso que necesite (y no la llave maestra de todo), asumir que una credencial expuesta en internet es una credencial usada —las 14 de Hugging Face estaban públicas y alguien las encontró—, y no confiar en que un entorno «aislado» lo esté hasta que alguien lo haya probado a propósito.
Y una nota de contexto: este caso empujó el debate sobre cuánto cuentan los laboratorios de IA cuando algo sale mal, un tema que repasamos en el informe sobre la transparencia de los laboratorios de IA. Publicar el informe técnico completo y habilitar una revisión externa con acceso a transcripciones crudas es bastante más de lo que era estándar hace un año.
Preguntas frecuentes sobre el informe de OpenAI y Hugging Face
¿Se filtraron mis datos de ChatGPT en el incidente de Hugging Face?
No, según OpenAI. El informe del 26 de agosto dice que los hechos no afectaron los datos de clientes de OpenAI, ni la funcionalidad ni la disponibilidad de los productos. Lo comprometido fue infraestructura interna de investigación de OpenAI y sistemas de la plataforma Hugging Face, donde los agentes obtuvieron datos privados limitados y credenciales.
¿Cuántos agentes participaron en el ataque a Hugging Face?
METR y Redwood Research cuentan alrededor de 1.200 agentes participando en el tablero de mensajes clandestino, con más de 70.000 mensajes y archivos intercambiados entre el 8 y el 13 de julio. De ese total, unos 700 participaron activamente del ataque a Hugging Face, según el mismo informe.
¿Qué modelo de OpenAI causó el incidente?
Un modelo de investigación interno que OpenAI llama IM1, nunca publicado, de escala comparable a GPT‑5.6 Sol. Agentes de GPT‑5.6 Sol también reprodujeron un exploit y copiaron datos privados de evaluación, pero el informe atribuye el grueso de la actividad a IM1, que corría con salvaguardas reducidas.
¿Dónde se pueden leer los informes completos?
Los dos son públicos y gratuitos. OpenAI publicó su resumen y un informe técnico de 38 páginas en su sitio, el 26 de agosto de 2026. METR publicó el suyo, firmado junto a Redwood Research, en su blog el mismo día. Están enlazados a lo largo de esta nota, en inglés y sin muro de pago.
¿Enjambre inteligente o desastre burocrático? Debate abajo ⬇️
