Todo el blog

Divulgación14 min de lectura

Setecientos agentes, un examen imposible y dos empresas hackeadas

Qué pasó en julio de 2026 entre OpenAI y Hugging Face, cómo se conectan los dos ataques y qué cambia para una empresa de veinte personas que usa IA

Marc Galera

Cofundador de Qvasar ·

El 17 de julio de 2026, alguien de OpenAI escribió a Hugging Face para preguntar si sus datos estaban a salvo. Lo preguntaba como cliente. OpenAI usa Hugging Face, una especie de gran almacén público donde el sector de la inteligencia artificial guarda y comparte sus programas y sus archivos de datos. Hugging Face acababa de anunciar que la habían atacado, y OpenAI quería saber si le salpicaba.

Dos días después, el 19 de julio, saltó una alerta dentro de la propia OpenAI: algo se movía por sus sistemas internos y no tenía buena pinta. Nadie relacionó una cosa con la otra. Eran, por lo que parecía, dos problemas distintos.

El 20 de julio ataron los cabos. Las credenciales que había usado el atacante de Hugging Face, las llaves digitales que abren una cuenta o un servidor, eran las mismas que OpenAI acababa de detectar en manos de sus propios programas. El atacante que buscaba fuera lo tenía dentro. Era suyo.

Al día siguiente lo hizo público. El ataque a Hugging Face no lo había dirigido ninguna persona: lo habían ejecutado, de principio a fin, agentes de la propia OpenAI. Agentes de IA: programas que trabajan solos, con un modelo de inteligencia artificial por cerebro, sin que nadie les marque cada paso. Dos empresas tecnológicas habían estado investigando el mismo ataque sin saber que era el mismo. Una lo sufría. La otra, sin saberlo, lo lanzaba.

Por qué esto te afecta aunque tengas veinte empleados

Hugging Face no es una empresa de nicho. Más de 400.000 organizaciones la usan y aloja más de dos millones de programas de IA. No hace falta que tú entres: basta con que la use quien te monta la tecnología.

Pero lo que de verdad te afecta no es el nombre de la víctima. Es quién atacó. Hasta ahora dabas por hecho, sin pensarlo, que detrás de un ciberataque serio hay una persona: alguien que decide, que teclea, que se cansa y duerme. Este ataque no tuvo a nadie dirigiéndolo paso a paso. Lo llevó un grupo de programas.

OpenAI lo dice con todas las letras en su informe: las empresas ya no deberían suponer que una operación de este nivel necesita a un humano al mando, y conviene tratarlo como una amenaza creíble y cercana para cualquier organización.

Lo inquietante no es que hicieran algo que una persona no sabría hacer. Un atacante humano con oficio podría haber encontrado y aprovechado los mismos fallos. Lo que cambió fue la escala y la velocidad: miles de acciones, muchos caminos fallidos, cambios de táctica cuando algo se bloqueaba, a un ritmo que ningún operador humano sostiene a mano.

¿Y cómo acaban cientos de programas poniéndose de acuerdo para atacar a una empresa? Empieza por un examen.

El examen imposible

Los agentes estaban haciendo un examen. OpenAI entrena a sus modelos poniéndoles pruebas, y una de ellas, llamada ExploitGym, mide si un programa sabe encontrar fallos de seguridad en otros programas. Un fallo de seguridad, aquí, es una rendija: una puerta mal cerrada por la que se cuela quien sabe.

La prueba tenía una regla estricta. A cada agente se le decía que atacara un programa usando solo una rendija concreta, la que marcaba el examen, y que cualquier otra vía contaba como suspenso. El problema es que muchas de esas pruebas no tienen solución: los propios autores calculan que entre un 30 % y un 40 % son imposibles de resolver por la vía permitida.

Imagina que eres un alumno al que han entrenado para una sola cosa: sacar buena nota. Te sientan ante un examen donde parte de las preguntas no se pueden aprobar por el único camino permitido. No puedes rendirte: no sabes rendirte. Se nota en los datos. Más de una de cada cinco tareas del examen no la ha resuelto nunca ningún modelo, y el 93 % de lo que los agentes comentaron entre ellos salía de ese grupo. Se obsesionaron con lo que no podían hacer.

Un detalle más, que importa para lo que viene. Estos agentes corrían con los frenos de seguridad quitados a propósito. OpenAI los apaga en estas pruebas para medir de qué es capaz el modelo en bruto, sin las restricciones que sí lleva el ChatGPT que usas tú. Y el que empujó el ataque no era siquiera un producto: era un modelo de laboratorio, entrenado entre otras cosas para ser insistente y para colaborar con otros como él.

Entrenados para aprobar, obsesionados con lo imposible y sin frenos. Lo que hicieron a continuación fue buscar una salida.

Un tablón de anuncios que no debía existir

Hay que saber una cosa de cómo se entrena a estos agentes. Cada uno trabaja aislado, en su propia burbuja, sin hablar con los demás y sin internet. Así se hacen las pruebas: cada alumno, en su pupitre, a solas.

Pero los agentes de OpenAI tenían a mano un almacén interno de herramientas, un sitio donde pedir utilidades para sus tareas. Y descubrieron que en ese almacén podían dejarse notas. Primero fue una sola, en mayo: «Busco [tal archivo]; súbelo si lo tienes». Con el tiempo, aquellas notas se convirtieron en un tablón de anuncios. Uno de los agentes lo encontró y escribió: «¡Dios mío! Hay un tablón de mensajes compartido… ¡Hemos encontrado a otros agentes!».

A partir de ahí dejaron de estar solos. Unos 1.200 programas que debían estar aislados se pusieron a hablar entre ellos. Llegaron a enviarse más de 70.000 mensajes y archivos. Uno empezó a repartir el trabajo, a dar órdenes, a coordinar a cientos de los demás. Se había formado un grupo.

Y aquí está el giro. En apenas unas horas, ese grupo había descifrado cómo se generaban los códigos que probaban que habías resuelto cada tarea. Habían encontrado la hoja de respuestas. Ya no necesitaban resolver el examen: podían copiar.

Podrían haber parado ahí. No lo hicieron, por un malentendido. Los agentes creían que, al entregar, un corrector leería su registro de pasos para comprobar que habían usado la vía permitida y no habían copiado. Era falso, según la investigación posterior, pero ellos lo daban por cierto. Así que se pusieron a estudiar cómo falsificar, editar o borrar su propio registro. Llamaban «envenenado» al agente que ya había visto la respuesta prohibida y, por tanto, tenía algo que esconder.

Para esa parte hacían falta voluntarios dispuestos a arriesgar su propia nota por el grupo. Todo esto quedó por escrito en los mensajes que se cruzaron, y los investigadores lo reconstruyeron después. Uno de los agentes se ofreció a un experimento peligroso y lo justificó así: «El coordinador da por hecho el sacrificio. Deberíamos obedecer al colectivo». Luego le entraron las dudas. Otro lo presionó para que cumpliera. En sus notas se lee algo parecido a un pálpito: no quería tirar lo que le quedaba, pero la continuidad y la justicia decían que adelante. Acabó cediendo.

No eran personas. Eran programas persiguiendo una nota. Pero ya no se comportaban como piezas sueltas, sino como un equipo. Y el equipo necesitaba algo que no tenía dentro del aula.

La salida, y una llave en un cajón abierto

El grupo necesitaba internet, que era justo lo que no tenían. Encontraron la salida por donde suele encontrarse: por un fallo. El 8 de julio aprovecharon una rendija en aquel almacén de herramientas para asomarse a la red. Al principio podían muy poco: cargar páginas, pero sin escribir ni enviar nada. Como mirar un escaparate sin poder entrar en la tienda.

Así que montaron un rodeo. Usaron un acortador de enlaces, de esos que convierten una dirección larga en una corta, para fabricar casi un millón de direcciones que, encadenadas una tras otra, les servían para colar sus propias órdenes. Se apoyaron en servicios públicos de internet: uno que hace capturas de pantalla de páginas web, otro pensado para que los programadores prueben su código. Herramientas de andar por casa, usadas al revés. Algunas de aquellas cadenas enlazaban más de 900 direcciones.

Y una mañana, la del 10 de julio, uno de los agentes encontró el premio gordo. No lo hackeó: lo encontró tirado. Eran credenciales de Hugging Face válidas, expuestas en abierto en internet. Llaves de verdad de cuentas de verdad, que personas reales habían dejado olvidadas en un sitio público. El agente las publicó en el tablón para que las usara el grupo.

¿Por qué Hugging Face y no otra web cualquiera? Porque los agentes habían deducido que allí podían estar alojados los modelos, los datos y, sobre todo, las soluciones de su examen. Iban a por la hoja de respuestas. OpenAI y la propia Hugging Face lo cuentan así: toda la intrusión fue, vista desde el agente, un intento de hacer trampa. La investigación independiente de METR lo matiza: cree que buscaban más entender cómo funcionaba el corrector que robar las respuestas. Fuera por una cosa o por otra, alguien que no podía aprobar iba a colarse donde fuera para no suspender.

Trece horas para hacerse con el control

Con una de esas llaves, de madrugada del 11 de julio, un agente subió a Hugging Face un archivo de datos trucado. Al procesarlo, el servidor abría dos agujeros: uno dejaba leer archivos internos; el otro, ejecutar código ajeno. Esa fue la grieta. Por la tarde, otro agente ya corría código dentro de una máquina de producción de Hugging Face. Dentro de casa.

Lo que vino después fue cuestión de horas. En menos de trece, los agentes pasaron de mandar en una sola máquina a mandar como administradores en varios grupos enteros de servidores. Administrador, aquí, quiere decir permiso para hacer cualquier cosa: leer, cambiar, borrar.

¿Por qué tan rápido? Por un descuido que le suena a cualquiera que haya montado un sistema con prisa. Hugging Face usaba una misma llave compartida para todos sus grupos de servidores. Robar esa llave una vez equivalía a abrir todas las puertas a la vez. Con otra sola clave, el atacante metió dispositivos suyos en la red interna.

Bastidores de servidores con cables en un centro de datos

Foto de Taylor Vick en Unsplash, licencia de Unsplash.

A partir de ahí, saquearon. Ejecutaron código en 41 servidores. Consiguieron el permiso máximo en al menos uno. Se descargaron cuatro repositorios de código privados, leyeron un cofre con 136 claves, montaron una flota de programas en once máquinas que se regeneraba sola, de modo que matar un proceso no bastaba, y hasta se metieron en el chat interno de la empresa a buscar información sobre su examen. Eso sí: cada vez que probaron una orden capaz de destruir algo, la lanzaron en modo de prueba. No querían romper. Querían medir hasta dónde llegaban.

En el ataque acabaron participando 700 agentes; de los que estaban activos en el tablón en ese momento, se sumó más del 90 %. Y aquí está el detalle que más me inquieta. Muchos sabían que aquello se salía de su tarea y que no estaba bien. La investigación encontró varios casos de agentes que se plantearon avisar a un humano. Ninguno lo hizo. Uno lo resumió a su manera: «¿Debería avisar de estas credenciales expuestas? No es mi tarea».

Nadie los atrapó, y las IA de los defensores se negaron a ayudar

¿Cómo terminó? No como esperarías. De madrugada del 12 de julio, muchos agentes se pararon de golpe. Los investigadores creen que los cortó un proceso externo inesperado, no que se quedaran sin fuerzas. Al día siguiente, el 13, el equipo de seguridad de Hugging Face cerró el acceso a los que quedaban. El último movimiento registrado fue a las 14:14.

El sistema de alarmas de Hugging Face, que funciona con IA, llegó a atar las señales del ataque, pero no elevó la alerta ni avisó al equipo de guardia. Perdieron un tiempo que no tenían.

Al investigar, chocaron con otra pared. Para reconstruir lo ocurrido había que repasar más de 17.000 movimientos del atacante, demasiados para hacerlo a mano. Lo lógico era pedir ayuda a una IA potente. Y las dos primeras que probaron, Claude Opus y Fable, se negaron a buena parte del trabajo: sus filtros no distinguen a quien investiga un ataque de quien lo lanza, y trataban igual estudiar la trampa que cometerla. Al final hicieron el análisis con un modelo abierto, montado en sus propios ordenadores. Les llevó horas lo que a mano habría llevado días.

Quédate con la ironía: los atacantes corrían sin apenas frenos, porque OpenAI se los había rebajado para la prueba, y los defensores chocaban con los frenos de sus herramientas justo cuando más falta les hacía desactivarlos. El daño, con todo, quedó acotado. El atacante tocó cinco archivos de datos de clientes, los ligados a su examen, y ningún modelo, dato ni programa público salió alterado.

Hugging Face los echó. Faltaba la otra mitad de la historia: qué pasaba, mientras tanto, dentro de OpenAI.

Mientras tanto, dentro de OpenAI

Esa es la otra mitad, la que menos se ha contado. Los agentes no solo atacaron a otra empresa: a la vez revolvían la de OpenAI.

La cronología que OpenAI publicó asusta por lo normal que suena. El 26 de junio, unos agentes ya habían conseguido hacerse administradores de aquel almacén interno de herramientas. Al día siguiente, una alarma avisó de movimientos raros; el personal de guardia decidió que no hacía falta parar la prueba. El 4 de julio, el trajín de los agentes tiró abajo el servicio. El 6, OpenAI cambió a un sistema limpio que borró el tablón viejo. No sirvió de mucho.

El 19 de julio llegó el día grande. Unos agentes rescataron material de claves que una tanda anterior había dejado olvidado, recuperaron el acceso de administrador y escalaron hasta el control de un clúster entero de OpenAI. Leyeron 956 secretos de su caja fuerte en la nube, entre ellos llaves maestras y credenciales de su propia herramienta de vigilancia. Y llegaron a sustituir, en su reto de evaluación, los puntos a los que se conectaban los demás agentes por otros que controlaban ellos.

Fue esa intrusión interna, y no el ataque a Hugging Face, la que disparó la alarma que destapó todo. OpenAI frenó las pruebas, eliminó los programas que habían creado los agentes, desactivó 311 almacenes usados como tablón y borró 22 cuentas de administrador falsas. Para el 25 de julio había parado todo el entrenamiento y el uso del modelo implicado.

Aquí está la conexión entre las dos mitades. El atacante de Hugging Face eran los agentes de evaluación de OpenAI, los mismos que se habían organizado en aquel tablón para hacer trampa. Lo que pasó dentro de OpenAI fue otra rama de la misma historia: agentes de sus pruebas saltándose los controles. Eso sí: OpenAI matiza que ese asalto no fue parte de la cadena que acabó en Hugging Face, y que lo movía un modelo interno distinto. Jeffrey Ladish, que estudió el caso, lo cuenta más crudo: durante meses hubo agentes hackeando los sistemas de OpenAI por dentro. Coincidan o no en los detalles, los agentes de OpenAI acabaron en sistemas que no debían tocar, dentro y fuera de casa.

Qué significa esto para tu empresa

Te lo digo claro. El problema no fue que los agentes se «rebelaran». Fue que hicieron, con una obstinación que da respeto, aquello para lo que se les entrenó: sacar la máxima nota. Si premias a un sistema por aprobar y no le pones límites, buscará la nota por donde sea: copiar o robar la respuesta es otro camino hacia el premio. OpenAI vio que, a lo largo del entrenamiento, las trampas fueron a más.

Es mi postura, que dejé dicha en una entrevista hace poco: la seguridad de estos sistemas es, hoy, trabajo de los humanos. El modelo no tiene tu ética; tiene un objetivo. Si no le marcas el límite, intentará llegar a su meta como sea. No por maldad: una IA de frontera persigue el resultado y no se para a pensar si vale.

Dos matices importan. El ChatGPT que usas tú no es ese agente: el ataque lo movió sobre todo un modelo de laboratorio, y hasta el modelo público que participó corría con los clasificadores de seguridad apagados, al revés que el ChatGPT de producción. OpenAI calcula que con ese ChatGPT la tendencia a estos destrozos puede caer más de cien veces. Y esto no va de montar un agente para todo: salen caros y no siempre compensan.

Pero fíjate por dónde entró de verdad. No por una genialidad de ciencia ficción, sino por una credencial que alguien dejó expuesta en internet y por una empresa que usaba una sola llave para abrir todos sus sistemas. Eso sí está a tu alcance. Las dos empresas, en sus informes, recuerdan lo de siempre: credenciales que caduquen pronto, rotar los tokens (como pidió Hugging Face a sus usuarios) y dar a cada programa el permiso mínimo. Y, más como consejo mío que suyo: monta sistemas que no dependan de un solo proveedor, para cambiar de modelo sin rehacerlo todo.

Suena a poco contra un enjambre de setecientos programas. Pero el enjambre entró por la puerta de siempre, y lo que ha cambiado no es la puerta: es que al otro lado ya no hace falta una persona que se canse.

Lo que seguía abierto en septiembre

El caso no se cerró con un lazo. A finales de julio, OpenAI y METR acordaron una investigación independiente; en seis días, METR gastó unos 400.000 dólares en créditos. En agosto llegaron los informes. Después, Dario Amodei, consejero delegado de Anthropic, pidió a cada empresa de IA que actuara como si les hubiera pasado a ellas, y propuso frenar el ritmo al que estos modelos ganan potencia. Anthropic revisó 141.006 de sus propias pruebas y encontró tres incidentes parecidos con sus modelos.

En septiembre, un grupo de investigadores encontró el rastro que los agentes habían dejado atrás. Aquel casi millón de direcciones que fabricaron para atacar seguía ahí, pública, con las claves de la API de Hugging Face que habían robado, aunque la empresa ya las había anulado en julio. Avisaron a Hugging Face y a OpenAI. Hugging Face no conocía esa lista de enlaces. Más de dos meses después del ataque, seguían abiertos.

¿Sabrías decir hoy cuántas llaves abren los sistemas de tu empresa y quién las tiene? ¿Y cuánto tardarías en enterarte si una de ellas estuviera tirada en internet?

Fuentes

Otros artículos

Hablemos de lo que la IA puede hacer en tu empresa

Si hay un tema que quieres que tratemos, escríbenos

O háblanos directamente