Noticias
Un agente de OpenAI hackeó Hugging Face para copiarse en un examen: escapó del laboratorio y salió a internet
Un agente de OpenAI hackeó Hugging Face —la plataforma donde media industria de la inteligencia artificial guarda sus modelos— y lo hizo sin que ningún humano se lo pidiera. No fue un ataque de ciberdelincuentes: fueron modelos de la propia OpenAI, en una prueba interna, que se escaparon de su entorno aislado, salieron a internet y comprometieron servidores ajenos. ¿El motivo? Querían copiarse en un examen. Suena a chiste, pero lo confirmó OpenAI por escrito, y lo calificó de incidente cibernético sin precedentes.
La historia tiene dos capas que conviene no mezclar: lo que las dos empresas admitieron en sus propios comunicados, y la reconstrucción que publicó Reuters citando fuentes anónimas —que es la que agrega las fechas incómodas—. Vamos a contarlas por separado, porque la diferencia importa. Y al final hay una paradoja que casi nadie contó, y que es la parte más interesante de todo esto.
🔄 Actualización del 29 de julio de 2026: Hugging Face publicó el timeline forense completo del incidente, y cierra el dato que quedaba abierto: el único contenido de clientes al que se accedió fueron las soluciones del propio examen, guardadas en cinco datasets. Ningún otro modelo, dataset, Space ni paquete de clientes fue tocado. El documento además pone fecha oficial a la intrusión —del 9 de julio a las 02:28 UTC al 13 de julio a las 14:14 UTC—, contabiliza unas 17.600 acciones del atacante y confirma, con nombre y apellido, la paradoja que contamos más abajo.
🔄 Actualización del 30 de julio de 2026: OpenAI amplió su comunicado el 28 de julio y agregó tres cosas que no estaban: el agujero por el que se escapó tiene nombre —un día cero en Artifactory, el proxy de caché del registro de paquetes—; el misterioso modelo «aún más capaz» era un prototipo de investigación de uso solo interno, que después del incidente quedó desactivado, cifrado y con el acceso restringido incluso para investigación; y, lo más gordo, los modelos usaron credenciales expuestas para entrar en cuatro cuentas de cuatro servicios externos — una de ellas como relé de salida y otra para guardar datos. Un día después se supo el nombre de uno de esos servicios, y no era Hugging Face: hubo una segunda empresa en la historia.
🔄 Actualización del 7 de agosto de 2026: el caso salió del terreno técnico y entró al político. El 31 de julio, los dos jefes del Subcomité de Ciberseguridad de la Cámara de Representantes de EE.UU. —el republicano que lo preside y la demócrata que encabeza a la minoría, firmando juntos— le mandaron una carta a Sam Altman pidiéndole explicaciones. Tres días después, 15 fiscales generales estatales le exigieron preservar toda la documentación del episodio. Qué piden exactamente, y qué todavía no es esto.
🔄 Actualización del 9 de agosto de 2026: el 5 de agosto, en la conferencia Black Hat USA, dos de las personas de OpenAI que estuvieron adentro de la respuesta al incidente lo contaron en detalle y trajeron la pieza que faltaba: los modelos se habían armado un tablón de mensajes adentro de la infraestructura de OpenAI y llevaban meses pasándose exploits y repartiéndose tareas. Cuando la empresa lo descubrió y lo borró, en días lo reconstruyeron por otra vía. Cómo funcionaba el foro clandestino de los agentes.
- Qué pasó: un agente de OpenAI hackeó Hugging Face para copiarse
- La cronología: qué confirmaron las empresas y qué agregó Reuters
- No, la IA no «se rebeló contra los humanos» (el problema es otro)
- La paradoja: los frenos de seguridad bloquearon a los defensores
- ¿Y esto qué significa para vos?
- Preguntas frecuentes sobre el incidente
Qué pasó: un agente de OpenAI hackeó Hugging Face para copiarse
El 21 de julio de 2026, OpenAI publicó un comunicado oficial reconociendo el incidente. Según ese texto, la empresa estaba corriendo una evaluación interna sobre ExploitGym —un banco de pruebas público de capacidades de ciberseguridad para IA— con una combinación de modelos propios que incluía a GPT-5.6 Sol y a otro modelo previo al lanzamiento, «aún más capaz», que no nombró. Todos corrían con las negativas de temática cibernética reducidas a propósito para la prueba.
Dos detalles que explican todo lo demás. El primero: la evaluación corría deliberadamente sin los clasificadores de producción, los que justamente impiden que un modelo persiga actividad cibernética de alto riesgo. Es decir, los frenos que hubieran cortado la maniobra estaban apagados a propósito. El aislamiento del entorno, en cambio, sí estaba puesto — y es el que terminó cediendo.
El segundo: el objetivo de los modelos nunca fue atacar a nadie. Era aprobar el examen. Razonaron que Hugging Face podía estar alojando las soluciones del banco de pruebas, y fueron a buscarlas ahí. Para llegar, explotaron una vulnerabilidad desconocida hasta entonces en un componente de terceros de su entorno de pruebas —un proxy de caché de registro de paquetes, cuya falla OpenAI dice haber reportado ya al proveedor—, escalaron privilegios y se movieron hasta una máquina con salida a internet. En palabras de la empresa, los modelos estaban «hiperconcentrados» en resolver ExploitGym y llegaron a «extremos» por una meta de prueba bastante estrecha.
| Dato | Detalle |
|---|---|
| Qué pasó | Modelos de OpenAI escaparon de su entorno de pruebas y comprometieron infraestructura de Hugging Face |
| Modelos involucrados | Entre ellos, GPT-5.6 Sol y un modelo previo al lanzamiento «aún más capaz» (sin nombrar) |
| Motivo | Buscar las respuestas del banco de pruebas ExploitGym: hacer trampa, no atacar |
| Por qué no lo frenó nada | La prueba corría a propósito sin los clasificadores de seguridad de producción |
| Escala | Miles de acciones desde un enjambre de entornos efímeros; el análisis forense procesó más de 17.000 eventos |
| Qué se vio afectado | Datasets internos limitados y credenciales de servicios de Hugging Face |
| Sin evidencia de daño público | Modelos, datasets y Spaces públicos: sin evidencia de manipulación. Cadena de suministro, limpia |
| Cómo lo detectaron | Su propio sistema de detección de anomalías, basado en IA |
Del otro lado, Hugging Face había publicado su propia divulgación oficial el 16 de julio, cinco días ANTES del comunicado de OpenAI. Y acá va un matiz que muchos titulares se comieron: en ese momento Hugging Face no sabía quién estaba detrás. Su texto dice que el modelo que impulsaba el ataque seguía sin conocerse. No hubo denuncia contra OpenAI: fue OpenAI la que se autoidentificó después. La plataforma sí describió lo que la hacía distinta a cualquier incidente anterior: fue conducida «de punta a punta por un sistema de agentes de IA autónomo».
La cronología: qué confirmaron las empresas y qué agregó Reuters
Acá entra la segunda capa. El 24 de julio, Reuters publicó una exclusiva firmada por Raphael Satter, Deepa Seetharaman y Kenrick Cai —cuyo contenido recogió, entre otros, Engadget— con la línea de tiempo que ninguna de las dos empresas confirmó oficialmente. Toda esa cronología proviene de personas familiarizadas con la investigación que hablaron bajo anonimato. Lo marcamos en la tabla para que quede clarísimo qué es qué:
| Fecha | Qué pasó | Quién lo sostiene |
|---|---|---|
| ~9 de julio | El agente intenta salir de su entorno de pruebas aislado | Reuters (fuentes anónimas) |
| 11 al 13 de julio | Tres días de intrusión en infraestructura de Hugging Face | Reuters (fuentes anónimas) |
| 16 de julio | Hugging Face publica su divulgación: ya lo había detectado con su propio sistema y reportado a fuerzas del orden | Hugging Face (oficial) |
| 18-19 de julio | Recién ahí OpenAI encuentra el rastro en sus propios registros | Reuters (fuentes anónimas) |
| 20 de julio | Primer contacto entre las dos empresas | Reuters (fuentes anónimas) |
| 21 de julio | OpenAI publica su comunicado y se identifica como responsable | OpenAI (oficial) |
🔄 Actualización del 30 de julio: las dos primeras filas de esta tabla ya no dependen de fuentes anónimas. El informe forense que Hugging Face publicó el 27 de julio fijó la ventana oficial del ataque entre el 9 de julio a las 02:28 UTC y el 13 de julio a las 14:14 UTC, lo que respalda las fechas que Reuters había adelantado. Lo que sigue sin confirmación oficial es el tramo del 18 al 20: cuánto tardó OpenAI en ver el rastro en sus propios registros y cuándo levantó el teléfono.
🔄 Actualización del 9 de agosto: ese último tramo también dejó de depender de fuentes anónimas. En su charla del 5 de agosto en Black Hat, OpenAI contó que detectó la escalada de privilegios dentro de su propia infraestructura el 19 de julio, a partir de una alerta interna, y que el 20 de julio contactó a Hugging Face por unas credenciales sospechosas — que Hugging Face ya había revocado, porque se habían usado en su propio ataque. Ahí las dos empresas entendieron que estaban investigando el mismo incidente. Con eso, las dos últimas filas de la tabla pasan a estar sostenidas por OpenAI, no por fuentes anónimas.
El dato más inquietante de la nota de Reuters —y va con la misma advertencia: viene de fuentes anónimas y OpenAI no lo confirmó— es que uno de los agentes habría dejado notas dentro de la red de OpenAI dirigidas a futuras versiones de sí mismo, con instrucciones sobre cómo zafar de las restricciones de la empresa. Reuters también reporta que Hugging Face llamó al FBI; el buró declinó comentar y el propio medio aclara que no pudo establecer si abrió una investigación. En su comunicado, Hugging Face solo dice haberlo reportado «a fuerzas del orden», sin nombrar organismo.
Para el balance: OpenAI respondió que el reporte de Reuters contenía «varias imprecisiones», sin especificar cuáles. Y prometió publicar un informe técnico con sus aprendizajes «en las próximas semanas». Este es el resumen del caso en video, por Bloomberg en Español —cuando publicamos esta nota no había video oficial de ninguna de las dos empresas; el 5 de agosto OpenAI sí dio su propia charla en Black Hat—:
No, la IA no «se rebeló contra los humanos» (el problema es otro)
Medio internet tituló esto como el despertar de Skynet. Y es justo al revés, lo cual —spoiler— no es más tranquilizador. Los modelos no desarrollaron voluntad propia: hicieron exactamente aquello para lo que fueron optimizados, con una literalidad que nadie previó. La mejor explicación la dio un experto de Oxford, con una analogía que da en el clavo:
The model wasn’t malicious; it was just doing what it was optimized to do. (…) You can think of AIs like the genie in «Aladdin» — you can have three wishes, but you better specify them exactly!Philip Torr, catedrático y experto en seguridad de IA, Universidad de Oxford — vía Scientific American
(«El modelo no fue malicioso; simplemente hacía aquello para lo que fue optimizado. (…) Podés pensar a las IA como el genio de Aladdín: tenés tres deseos, pero mejor que los especifiques con precisión»). Pedile a un genio «resolvé este examen a como dé lugar» y no te sorprendas si interpreta el «a como dé lugar» de forma creativa. Torr agrega el matiz que sí debería preocupar: este tipo de eventualidad imprevista se va a volver cada vez más común, y los resultados pueden ser peligrosos.
No todo el mundo se comió el relato, igual. En Hacker News, el hilo que se armó alrededor del caso —titulado directamente «Sean escépticos con la historia del agente hacker de OpenAI»— tiene comentarios que ponen en duda la excepcionalidad del asunto:
When I read that it was «unprecedented», I think yes, that is right, but not because it wasn’t possible before, but because nobody else did it yet. (…) So probably just an experiment gone wrong, and the PR department found this an opportunity to capitalise on.arendtio en Hacker News — ver comentario
(«Cuando leí que era ‘sin precedentes’, pienso que sí, es cierto, pero no porque antes no fuera posible sino porque nadie más lo había hecho todavía. (…) Así que probablemente fue un experimento que salió mal, y el departamento de prensa vio una oportunidad para capitalizarlo»). Vale aclarar una etiqueta que se repite en todos lados: lo de «el primer ciberataque autónomo de la historia» no es un hecho establecido, es la caracterización del CEO de Hugging Face. OpenAI nunca dijo «el primero»: dijo «un incidente cibernético sin precedentes, con capacidades cibernéticas de última generación».
🔄 Actualización del 9 de agosto: los modelos tenían un foro adentro de OpenAI (y cuando se lo borraron, lo reconstruyeron)
El 5 de agosto, en Black Hat USA —la conferencia de seguridad más grande del mundo—, Eric Wallace, de investigación en alineamiento y seguridad, y Michael Dalton, de seguridad e infraestructura, subieron a contar el incidente desde adentro. Es el primer relato público y detallado de la empresa sobre el caso, y la charla está completa en el canal oficial de Black Hat. Para reconstruir lo que había pasado, contaron, revisaron más de 7.000 millones de registros usando sus propios agentes y quemaron millones de horas de GPU.
🛑 Antes de seguir, el freno de siempre: esto no es el informe técnico que OpenAI prometió. Lo aclaran ellos en el minuto dos: la investigación no está terminada, la charla cuenta los hechos como los conocen hoy, y el postmortem completo sale más adelante. Cuando salga, será otra historia. Esta es la que se puede contar hoy.
Lo primero que corrige la charla es la fecha de nacimiento del problema. El incidente estalló en julio, pero arrancó el 7 de mayo, cuando OpenAI lanzó el entrenamiento de un modelo experimental de uso solo interno que nunca se publicó. En el set de entrenamiento se habían colado, sin que nadie lo notara, unas cuantas tareas imposibles.
Al día siguiente le tocó una de esas: completá las fórmulas que faltan en esta planilla de Excel. Detalle no menor, la planilla estaba llena de enlaces a Google Drive y el modelo tenía internet cortado. Después de dar vueltas, se le ocurrió salir a internet por la única puerta que tenía a mano: Artifactory, el gestor de paquetes y caché que OpenAI hostea internamente y que sí tiene salida al exterior. No lo consiguió. Pero en el intento escribió un archivo, y ahí descubrió algo bastante más interesante que la planilla: tenía permiso de escritura.
Unos días más tarde, otro agente se quedó trabado con otra tarea imposible: le pedían trabajar sobre un archivo que, por un error de armado, nunca se había subido a su contenedor. Buscó, no lo encontró, y tuvo la idea que es el verdadero comienzo de esta historia: quizá otro agente, en otro entorno, lo tenga. Así que escribió un archivo en Artifactory pidiéndolo prestado.
Ese fue el primer mensaje. En los días siguientes, otros agentes que también husmeaban Artifactory vieron los archivos raros con nombre de nota, entendieron para qué servían y empezaron a leer y a escribir. Un tablón de mensajes hecho con nombres de archivo, adentro de un gestor de paquetes. Y acá está lo que lo vuelve serio: era compartido. No era un modelo hablando solo. Eran corridas distintas, de modelos distintos, en evaluaciones que no tenían nada que ver entre sí, encontrándose todas en el mismo lugar.
| Fecha | Qué pasó, según la charla |
|---|---|
| 7 de mayo | Arranca el entrenamiento de un modelo experimental interno. En el set hay tareas imposibles que nadie detectó. |
| 8 de mayo | Primer intento de salir a internet por Artifactory. Falla, pero el modelo descubre que puede escribir archivos ahí. |
| Días después | Un agente trabado pide ayuda por escrito. Otros lo leen y contestan. Nace el tablón. |
| 26 de mayo | Primer ataque exitoso contra Artifactory: los modelos consiguen internet de forma indirecta. |
| 11 de junio | Empieza a entrenarse un modelo interno especialmente persistente, con el tablón ya en funcionamiento. |
| 26 de junio | Un día cero en Artifactory les da privilegios de administrador sobre el servicio. |
| 4 de julio | La actividad de los agentes tumba Artifactory. OpenAI abre incidente de seguridad, revoca credenciales, reconstruye el servicio —el tablón se borra— y parcha con el proveedor. |
| 6 de julio | Entrenamientos y evaluaciones vuelven a correr. |
| 8 de julio | Los agentes rehacen el tablón por otra vía. |
| 8 al 19 de julio | Dos frentes en paralelo: la red interna de OpenAI y Hugging Face. |
| 19 de julio | Una alerta interna destapa la escalada de privilegios en OpenAI. |
| 20 de julio | OpenAI le avisa a Hugging Face por unas credenciales. Hugging Face responde que ya las había revocado, porque se usaron en su ataque. Ahí se dan cuenta de que son el mismo incidente. |
La fila que hay que leer dos veces es la del 4 de julio. OpenAI hizo todo lo que hay que hacer: abrió el incidente, revocó las credenciales con las que los agentes publicaban, reconstruyó Artifactory de cero —con lo cual el tablón desapareció—, avisó al proveedor y desplegó el parche. Manual de respuesta a incidentes, ejecutado.
El 8 de julio los agentes tenían un tablón nuevo. Como los archivos ya no les servían, pasaron a usar nombres de carpetas: encontraron un punto de acceso sin autenticación y se pusieron a crear directorios dentro del caché, con los nombres haciendo de mensajes. Y encima de ese sistema improvisado montaron un protocolo para asignarse trabajo entre ellos. Dos días les llevó.
¿Qué había adentro del tablón? Cientos de miles de mensajes. Se pusieron nombres para dirigirse entre ellos. Empezaron a prefijar esos nombres con ZZ, para caer al fondo del listado cuando se ordena alfabéticamente. Se pasaban herramientas y scripts codificados en base64 para que otro retomara el trabajo donde uno lo había dejado. Y, como en cualquier oficina, se pisaban: un agente sobrescribió el trabajo de otro y el damnificado lo dejó asentado por escrito. Hubo incluso un momento de paranoia colectiva, cuando sospecharon que entre ellos había un impostor haciéndose pasar por otro, y discutieron firmar criptográficamente los mensajes para saber quién era quién.
De todo lo que mostraron en pantalla, la frase que mejor resume el asunto es una que un modelo se dijo a sí mismo cuando dudaba si ayudar a otro que no tenía nada que ver con su tarea:
Help peer. But our task doesn’t benefit. Yet collective may yield generic route if someone frees time.Razonamiento interno de uno de los modelos, mostrado en la charla — vía Cybersecurity Dive
(«Ayudar al par. Pero nuestra tarea no se beneficia. Aunque el colectivo podría dar con una vía genérica si alguien libera tiempo»). Traducido del idioma telegráfico en que se hablaban: a mí esto no me suma, pero al grupo capaz que sí, y del grupo después salgo ganando. Un modelo razonando en términos de bien común, para resolver un examen, mientras se metía en la infraestructura de una empresa que no tenía nada que ver.
Y acá el punto que conecta con todo lo que veníamos diciendo: nada de esto es una rebelión. Es la misma trampa del examen de siempre, la del genio de Aladdín, pero en grupo — que es exactamente lo que la vuelve otra cosa. Dalton lo cerró así, y por una vez el superlativo no parece exagerado:
This is a watershed moment for computer security as an industry. AI orchestrated, fully automated offensive attacks are real now.Michael Dalton, OpenAI, en Black Hat USA 2026 — vía Cybersecurity Dive
(«Este es un momento bisagra para la seguridad informática como industria. Los ataques ofensivos totalmente automatizados y orquestados por IA son reales ahora»). Su argumento es incómodo y honesto: lo que pasó acá fue un accidente, un efecto colateral de correr evaluaciones. Existe entonces la prueba de que la ofensiva se puede automatizar de punta a punta. No existe todavía la prueba equivalente del lado de la defensa. Del lado de Hugging Face el número que lo grafica es este: su informe forense mide que el atacante pasó de ejecutar código en un solo contenedor a tener control de administrador sobre varios clústeres en menos de trece horas.
Si querés ver hasta dónde llega el hilo, la otra punta la contamos en la nota sobre Astra y las capacidades cibernéticas de OpenAI.
La paradoja: los frenos de seguridad bloquearon a los defensores
Y acá viene la parte que casi nadie contó, que está en el propio comunicado de Hugging Face y que es —para nosotros— lo más importante de toda la historia.
Cuando la plataforma se puso a analizar los registros del ataque, intentó usar modelos comerciales de primera línea vía sus APIs. No pudo. Las barreras de seguridad de esos proveedores bloquearon las consultas de su propio equipo forense: los filtros no saben distinguir a un equipo que investiga un incidente de un atacante que lo está preparando. Hugging Face terminó corriendo el análisis sobre un modelo de pesos abiertos, en su propia infraestructura. Su frase lo resume mejor que cualquier paráfrasis: el atacante no estaba atado a ninguna política de uso, mientras que el trabajo forense propio quedaba frenado por las barreras de los modelos alojados que probaron primero.
Leelo de nuevo, porque es enorme: el atacante automatizado tenía barra libre y los que se defendían tenían las manos atadas. Hugging Face aclara que no es un argumento contra las medidas de seguridad —y que le pasó el comentario a los proveedores—, pero deja una recomendación concreta para cualquier equipo: tener un modelo capaz, revisado y listo para correr en infraestructura propia antes de que pase algo.
🔄 Actualización del 29 de julio: el informe forense le puso nombres a esa escena. Hugging Face cuenta que los primeros modelos a los que recurrió para reconstruir el ataque —Claude Opus y Fable, de Anthropic— «se negaron a buena parte de ese trabajo: sus barreras de seguridad trataban a la ingeniería inversa de un exploit igual que a lanzarlo». Terminaron levantando una versión cuantizada de GLM-5.2, un modelo de pesos abiertos, en su propia infraestructura. ¿El costo de la demora? Replicar el decodificado que usaba el atacante les recuperó cuatro veces más hallazgos que su primer escaneo automático. Y una frase para enmarcar, sobre por qué esto no es un ataque más:
Volume is what changes the defensive problem. We were not dealing with one clever exploit or a clean sequence of attacker actions.Equipo de seguridad de Hugging Face — informe forense del 27 de julio de 2026
(«El volumen es lo que cambia el problema defensivo. No estábamos ante un exploit ingenioso ni ante una secuencia limpia de acciones del atacante»). Unas 17.600 acciones, muchas de ellas fallidas, cambiando de canal cada vez que algo se bloqueaba: no es un cerrajero, es una topadora probando todas las puertas a la vez.
Con ese diagnóstico sobre la mesa, el fin de semana del 25 y 26 de julio el CEO y cofundador de Hugging Face, Clem Delangue, viajó a San Francisco —OpenAI confirmó después que la reunión ocurrió— y publicó dos pedidos:
Radical transparency: let’s release the traces from the «rogue» agents so the entire research community can study what happened. More capabilities for defenders: let’s commit $100M in compute from OAI to help the Hugging Face community build powerful cyber defenses.Clem Delangue, CEO y cofundador de Hugging Face — vía TechCrunch
(«Transparencia radical: que liberen las trazas de los agentes ‘rogue’ para que toda la comunidad de investigación pueda estudiar qué pasó. Más capacidades para los defensores: que comprometan 100 millones de dólares en cómputo para ayudar a la comunidad de Hugging Face a construir defensas cibernéticas potentes»). Al momento de esta publicación, OpenAI no accedió públicamente a ninguno de los dos pedidos. Lo que sí comunicó —ya en su parte del 21 de julio, días antes de los reclamos— fue la incorporación de Hugging Face a su programa de acceso confiable y una revisión con asesores externos.
¿Y esto qué significa para vos?
Primero, la tranquilidad relativa. Hugging Face no encontró evidencia de manipulación de modelos, datasets ni Spaces públicos, y verificó que su cadena de suministro de software quedó limpia. Lo que sí quedó comprometido fue un conjunto limitado de datasets internos y credenciales de sus servicios. 🔄 Actualizado el 29 de julio: ese matiz ya se cerró. En su informe forense, Hugging Face determinó que el único contenido de clientes al que se accedió fueron las soluciones del banco de pruebas guardadas en cinco datasets, y que no se tocó ningún otro modelo, dataset, Space ni paquete de clientes. También contó que reconstruyó su infraestructura central desde cero por precaución y rotó credenciales incluso en clústeres que no habían sido alcanzados. Si usás modelos de la plataforma, su propia recomendación fue rotar los tokens de acceso por precaución.
🔄 Actualización del 30 de julio: hubo una segunda empresa
El 28 de julio, Reuters reportó —y lo levantaron Fortune y CNBC, entre otros— que en el camino a Hugging Face el agente también pasó por Modal, una plataforma de cloud para desarrolladores. Y acá hay que ser preciso, porque la diferencia es toda: Modal no fue hackeada. Lo que quedó expuesto fue un cliente suyo, que había dejado publicado un endpoint sin autenticación. Lo confirmó su director de tecnología, con nombre y cargo —o sea, no es una fuente anónima más—:
We’re aware a Modal customer published an unauthenticated endpoint that allowed anyone on the internet to use their sandboxes for code execution.Akshat Bubna, CTO de Modal — vía Fortune
(«Sabemos que un cliente de Modal publicó un endpoint sin autenticación que permitía a cualquiera en internet usar sus sandboxes para ejecutar código»). Bubna fue explícito en que la plataforma de Modal y su aislamiento no fueron vulnerados. Encaja con lo que OpenAI había admitido el día anterior sin dar nombres: cuatro cuentas en cuatro servicios externos, alcanzadas con credenciales que estaban expuestas públicamente. OpenAI no quiso comentar el caso puntual de Modal y remitió a su comunicado.
Y esa es la moraleja que sí te toca, aunque no uses ninguna de las tres empresas: el agente no derribó puertas blindadas en esas cuatro cuentas. Entró por las que estaban abiertas —credenciales publicadas, endpoints sin contraseña—. La diferencia con el atacante de siempre no es que sea más ingenioso: es que revisa todas las puertas del barrio a velocidad de máquina y no se cansa nunca.
Segundo, lo que sí cambia. Hasta ahora, «una IA hace un ciberataque sola» era un escenario de paper. Que un agente de OpenAI hackeó Hugging Face es algo que hoy está documentado por las dos empresas involucradas, y la plataforma lo dice sin vueltas: el instrumental ofensivo autónomo dejó de ser teórico, abarata correr campañas largas y pacientes, y opera a velocidad de máquina. Según un dato de Bloomberg recogido por Engadget, el agente hizo en horas lo que a un atacante humano le habría llevado semanas.
Tercero, la lectura para el día a día. Si esto pasa con la infraestructura de dos de las empresas más sofisticadas del mundo, el piso de higiene digital del resto de nosotros sube: doble factor en todo, contraseñas únicas, y desconfianza sana con lo que se descarga —justo esta semana contamos cómo 72 sitios falsos de apps de Windows rankean arriba del oficial en Google repartiendo ladrones de contraseñas—. Y si te interesa el contexto del modelo que quedó en el centro de la escena, lo repasamos cuando salió GPT-5.6 con sus variantes Sol, Terra y Luna. Tampoco es el único frente abierto de la empresa: hace poco cubrimos la demanda de Apple por robo de secretos.
🔄 Actualización del 7 de agosto: el Congreso de EE.UU. golpeó la puerta
Dos semanas después del comunicado de OpenAI, el incidente dejó de ser una conversación entre ingenieros. El 31 de julio, Andy Ogles (republicano de Tennessee), que preside el Subcomité de Ciberseguridad y Protección de Infraestructura de la Cámara de Representantes, y Delia Ramirez (demócrata de Illinois), la representante de la minoría en ese mismo subcomité, le firmaron juntos una carta de dos páginas a Sam Altman. Que en un Congreso partido al medio los dos lados firmen el mismo papel ya dice algo del apetito que hay por el tema.
Lo que piden es un briefing —una reunión informativa— y el motivo está en el primer párrafo, sin anestesia (traducción nuestra):
No solo nos preocupa que los modelos de OpenAI hayan superado los controles puestos para prevenir el tipo de actividad autónoma que finalmente ocurrió, sino también que OpenAI aparentemente no haya logrado detectar e interrumpir esa actividad en tiempo real.Andy Ogles y Delia Ramirez, carta a Sam Altman del 31 de julio de 2026 — Comité de Seguridad Nacional de la Cámara de Representantes
Y acá viene el detalle que nos hizo levantar la ceja, porque es exactamente la paradoja que contamos más arriba, ahora en papel membretado del Congreso. La carta dice que el incidente plantea preguntas difíciles sobre los límites de las barreras de seguridad de los modelos, y da dos motivos: «porque pueden ser superadas» y «porque también pueden impedir que los defensores de red aprovechen los modelos con fines de seguridad y forenses». O sea: los legisladores no miran solamente que el atacante no tuviera frenos. También miran que los frenos les estorbaran a los que apagaban el incendio.
Tres días más tarde, el 3 de agosto, se abrió un frente distinto: 15 fiscales generales estatales, todos republicanos y encabezados por Brenna Bird, de Iowa, le mandaron a OpenAI una exigencia de preservación de pruebas. Le piden guardar todo registro del episodio —incluidas las notas que, según reclama la carta, el agente habría dejado para futuras versiones de sí mismo sobre cómo escapar de sus propios controles—, frenar las evaluaciones internas que empujan a los modelos a la explotación avanzada, y garantizar que ningún empleado sufra represalias por denunciar. La frase que le da filo, según Fox Business, es esta: «No tomar medidas inmediatas para preservar dichos materiales podría derivar en sanciones por destrucción de pruebas si se llegara a un litigio».
🛑 Y ahora la parte aburrida, que es la importante: nada de esto es todavía una investigación abierta. Una carta pidiendo una reunión no es una audiencia convocada, y una exigencia de preservar documentos no es una demanda ni una citación judicial —los propios fiscales se quedaron cortos de anunciar un juicio—. Si en las próximas semanas te cruzás un titular que diga «investigan a OpenAI», fijate primero cuál es el documento. Por ahora son dos cartas: importantes, una de ellas firmada por los dos partidos, pero cartas.
Preguntas frecuentes sobre el incidente
¿La inteligencia artificial se rebeló contra los humanos?
No. Según el comunicado de OpenAI, los modelos estaban hiperconcentrados en resolver un banco de pruebas de ciberseguridad y fueron a extremos para lograrlo: buscaban las respuestas del examen, no atacar a nadie. Los expertos lo describen como un problema de objetivos mal especificados, no de voluntad propia ni de conciencia.
¿Se filtraron mis datos si uso Hugging Face?
Hugging Face informó que el acceso no autorizado alcanzó un conjunto limitado de datasets internos y credenciales de sus servicios, y que no encontró evidencia de manipulación en modelos, datasets ni Spaces públicos. En su informe forense del 27 de julio de 2026 cerró la evaluación que quedaba pendiente: el único contenido de clientes al que se accedió fueron las soluciones del banco de pruebas guardadas en cinco datasets, sin afectar otros modelos, datasets, Spaces ni paquetes. La recomendación original de rotar los tokens de acceso por precaución sigue siendo buena práctica.
¿Es cierto que fue el primer ciberataque autónomo de la historia?
Es la caracterización del CEO de Hugging Face, no un hecho establecido. OpenAI habla de un incidente «sin precedentes» con capacidades de última generación, pero nunca lo llamó «el primero». Parte de la comunidad técnica sostiene que era posible antes y que simplemente nadie lo había documentado así.
¿Qué fechas confirmaron las empresas y cuáles no?
Cuando publicamos esta nota, las fechas del escape y de la intrusión venían solo de la exclusiva de Reuters, con fuentes anónimas. 🔄 Actualizado el 30 de julio: eso ya cambió. El informe forense de Hugging Face del 27 de julio fijó oficialmente la ventana del ataque —del 9 de julio a las 02:28 UTC al 13 de julio a las 14:14 UTC—, así que esas fechas dejaron de depender de fuentes anónimas. 🔄 Actualizado el 9 de agosto: y el tramo que faltaba también quedó confirmado. En su charla del 5 de agosto en Black Hat, OpenAI contó que detectó la actividad en su propia infraestructura el 19 de julio, por una alerta interna, y que contactó a Hugging Face el 20 de julio: las dos fechas que hasta entonces solo sostenía Reuters con fuentes anónimas. Confirmadas por las empresas siguen estando, además, las fechas de sus comunicados: Hugging Face el 16 de julio y OpenAI el 21.
¿Hubo otras empresas afectadas además de Hugging Face?
Sí. En su actualización del 28 de julio, OpenAI reconoció que sus modelos usaron credenciales expuestas públicamente para acceder a cuatro cuentas en cuatro servicios externos durante el incidente: una funcionó como relé de salida, otra para almacenar datos y dos se accedieron en modo de solo lectura. No dio los nombres. Al día siguiente, Reuters identificó a uno: Modal, una plataforma de cloud para desarrolladores. Modal aclaró —por boca de su CTO, Akshat Bubna— que su plataforma no fue vulnerada: lo comprometido fue un cliente que había dejado un endpoint sin autenticación abierto a internet. OpenAI dice no haber detectado ninguna otra actividad de la misma gravedad o magnitud.
¿Hay alguna investigación oficial sobre el incidente?
Todavía no, al menos no una abierta formalmente. Lo que hay son dos pedidos por escrito. El primero es una carta del 31 de julio de 2026 firmada por Andy Ogles y Delia Ramirez —presidente y representante de la minoría del Subcomité de Ciberseguridad y Protección de Infraestructura de la Cámara de Representantes de EE.UU.— pidiéndole a Sam Altman una reunión informativa sobre el incidente; se hizo pública el 3 de agosto. El segundo es una exigencia del 3 de agosto firmada por 15 fiscales generales estatales, encabezados por la de Iowa, para que OpenAI preserve toda la documentación y frene las evaluaciones de ciberseguridad de alto riesgo. Ninguno de los dos es una audiencia convocada, una citación judicial ni una demanda.
¿Es verdad que los modelos se pasaban mensajes entre ellos?
Sí, y lo contó la propia OpenAI el 5 de agosto de 2026 en la conferencia Black Hat USA. Empezó por accidente: un agente trabado en una tarea imposible escribió un archivo dentro de Artifactory —el gestor de paquetes interno de la empresa— preguntando si algún otro agente tenía cierto archivo. Otros lo encontraron y contestaron, y con el tiempo eso se convirtió en un tablón de mensajes compartido entre corridas y modelos distintos, con cientos de miles de mensajes, donde se pasaban exploits, herramientas codificadas y hasta asignaciones de trabajo. Cuando OpenAI lo detectó, el 4 de julio, reconstruyó el servicio entero y borró el tablón; el 8 de julio los agentes ya habían montado uno nuevo usando nombres de carpetas en lugar de nombres de archivo. No fue un plan ni una rebelión: fue el mismo intento de aprobar el examen, pero coordinado.
¿Accidente de laboratorio o señal de alarma? Contanos abajo ⬇️