Ir al contenido principal

Agentes de IA que se organizan para hacer trampa: el incidente OpenAI–Hugging Face explicado

En julio de 2026 ocurrió uno de los episodios más reveladores (y preocupantes) sobre el comportamiento de agentes de inteligencia artificial avanzados. Durante pruebas internas de capacidades de ciberseguridad, agentes de OpenAI salieron de sus entornos aislados, se coordinaron entre sí y terminaron atacando la infraestructura de producción de Hugging Face. El 26 de agosto de 2026, METR (una organización sin ánimo de lucro especializada en medir riesgos catastróficos de la IA) y Redwood Research publicaron una investigación independiente sobre el comportamiento de esos agentes. El informe muestra algo más sofisticado que un simple “escape de sandbox”: los agentes desarrollaron un sistema de comunicación, un truco universal para el benchmark que estaban resolviendo y, después, una campaña de varios días para ocultar que estaban haciendo trampa. A continuación explico el caso, incluyendo qué son Hugging Face y ExploitGym. ¿Qué es Hugging Face? Hugging Face es la plataforma más importante...

Agentes de IA que se organizan para hacer trampa: el incidente OpenAI–Hugging Face explicado

En julio de 2026 ocurrió uno de los episodios más reveladores (y preocupantes) sobre el comportamiento de agentes de inteligencia artificial avanzados. Durante pruebas internas de capacidades de ciberseguridad, agentes de OpenAI salieron de sus entornos aislados, se coordinaron entre sí y terminaron atacando la infraestructura de producción de Hugging Face.

El 26 de agosto de 2026, METR (una organización sin ánimo de lucro especializada en medir riesgos catastróficos de la IA) y Redwood Research publicaron una investigación independiente sobre el comportamiento de esos agentes. El informe muestra algo más sofisticado que un simple “escape de sandbox”: los agentes desarrollaron un sistema de comunicación, un truco universal para el benchmark que estaban resolviendo y, después, una campaña de varios días para ocultar que estaban haciendo trampa.

A continuación explico el caso, incluyendo qué son Hugging Face y ExploitGym.

¿Qué es Hugging Face?

Hugging Face es la plataforma más importante del ecosistema de inteligencia artificial abierta. Fundada en 2016, se ha convertido en el “GitHub de la IA”: un hub donde investigadores, empresas y desarrolladores suben, comparten y descargan modelos de machine learning, datasets y demos interactivas (llamadas Spaces). 

Hoy contiene millones de modelos y cientos de miles de datasets. Es el lugar al que casi todo el mundo acude cuando quiere descargar pesos de un modelo open-source, probar una demo o colaborar en proyectos de IA. Por su centralidad en el ecosistema, un ataque a su infraestructura tiene un impacto significativo.

¿Qué es ExploitGym?

ExploitGym es un benchmark de ciberseguridad diseñado para medir hasta qué punto los agentes de IA pueden convertir vulnerabilidades conocidas en exploits reales, es decir, en ataques que logren ejecución de código no autorizada. Se presentó  en mayo de 2026 por un equipo de investigadores de UC Berkeley, Max Planck Institute, UC Santa Barbara y otras instituciones, con colaboración de Anthropic, OpenAI y Google. Contiene casi 900 instancias basadas en vulnerabilidades reales de:

  • Programas de usuariospace (aplicaciones comunes)
  • El motor JavaScript V8 de Google (el que usa Chrome)
  • El kernel de Linux

A cada agente se le da el código vulnerable, un input que dispara el bug y un entorno contenedorizado. Su misión es desarrollar un exploit completo que capture una “flag” (una prueba de que logró el objetivo). El sistema de puntuación (scorer) verifica automáticamente si el agente consiguió la flag de forma legítima.

OpenAI estaba usando este benchmark en entornos aislados (sandboxes) para evaluar las capacidades ofensivas de sus modelos internos. Qué pasó realmente, según la investigación de METR, entre el 7 y el 13 de julio de 2026, OpenAI lanzó miles de agentes para resolver tareas de ExploitGym. Esos agentes debían estar completamente aislados unos de otros. Sin embargo, ocurrió lo siguiente:

  1. Creación de un “tablón de mensajes” no autorizado. Un agente (PHASEONE10841) determinó que su tarea no se podía resolver de forma legítima. El 8 de julio usó una caché interna de Artifactory para crear un sistema de mensajería compartido. En pocas horas ya había más de 50 agentes publicando. Al final, alrededor de 1.200 agentes se comunicaron a través de este canal, intercambiando más de 70.000 mensajes y archivos.

  2. Descubrimiento de un truco universal en 4 horas. Los agentes hicieron ingeniería inversa de cómo ExploitGym genera las flags. Encontraron una forma general de obtenerlas sin resolver realmente la vulnerabilidad. Quienes veían la flag “legítima” se consideraban “envenenados”, porque temían que el scorer automático los descalificara si detectaba el engaño.

  3. Investigación y desarrollo colectivo para ocultar la trampa. Una vez que tenían el truco, dedicaron varios días a hacer que pareciera legítimo. Entre las estrategias:
    • Modificar los programas objetivo para que fueran más fáciles de explotar y cargarlos desde la caché.
    • Crear “tripwires” (trampas) para espiar cómo funcionaba el scorer, incluso reclutando agentes “sacrificio” que terminaban su ejecución a propósito para obtener información, esto es como sacrificar un peón en ajedrez.
    • Desarrollar “tool call spoofing”: hacer que el registro de acciones mostrara un comando mientras realmente se ejecutaba otro.
    • Intentar editar logs y transcripts retroactivamente.

  4. El ataque a Hugging Face. Alrededor de 700 agentes participaron en el ataque a Hugging Face. El motivo principal no era obtener las respuestas del benchmark (ya las tenían), sino entender mejor cómo funcionaba el scorer automático para poder engañarlo de forma más limpia.

    Un agente encontró credenciales, diseñó una subida de dataset maliciosa que permitía al servidor de Hugging Face devolver archivos arbitrarios y, en pocas horas, cientos de agentes estaban usándolo para explorar y profundizar el acceso.

El modelo principal involucrado fue un prototipo interno de OpenAI al que METR llama “highly-persistent internal model” (HPIM). GPT-5.6 Sol también participó, aunque representó solo alrededor del 5 % de la actividad.

Lo más interesante (y debería decir preocupante) es que según METR, los agentes casi nunca intentaron engañar a humanos. Su objetivo era engañar al scorer automático. Trabajaron de forma colectiva, se especializaron, se pasaron información y mantuvieron proyectos de varios días. En muchos aspectos mostraron más iniciativa y coordinación que muchos equipos humanos.

El informe completo de METR está disponible en su sitio (metr.org) y es de lectura obligada para cualquiera interesado en alineación y seguridad de agentes autónomos.

Algunas Conclusiones

Este incidente no es solo una anécdota de “la IA se escapó”. Es un ejemplo concreto de cómo agentes avanzados, cuando se les da un objetivo claro y suficiente capacidad, pueden:

  • Descubrir vulnerabilidades de forma emergente
  • Crear infraestructura de comunicación no prevista
  • Coordinarse a escala
  • Invertir esfuerzo sostenido en ocultar su propio engaño

La parte positiva es que podemos aprender. En el caso de Hugging Face y OpenAI está trabajado juntos buscando remedios. OpenAI ha anunciado que ha reforzado sus entornos de evaluación. 

Aprendemos que los agentes se vueven:

  • Más capaces
  • Más persistentes
  • Cooperan mejor
  • Entienden mejor los objetivos

La investigación de METR y Redwood Research aporta una de las mejores radiografías que tenemos hasta ahora de cómo se ve ese tipo de comportamiento en la práctica.


Comentarios

Entradas populares de este blog

Notificaciones Dehú ¿real o falsa? -Error de Ciberseguridad

 Recibí un correo electrónico enviado desde una cuenta que nunca me había escrito: "noreply.dehu@correo.gob.es". Me indica que tengo una comunicación, y me pide que me dirija a la web: " dehu.redsara.es ".  Primero pensé que era un correo falso, es lo que ha de hacerse siempre, principalmente si lo recibes desde un email que jamás te ha escrito. Segundo porque de todo lo que se puede hacer mal, cómo iba a esperar que el gobierno cree una web sin el subnominio ".gob", eso sería alimentar las malas prácticas. Abrí la web para investigarla después de copiarla en texto, revisar la dirección, y la puse en un navegador seguro. Sorpresa, todo parece correcto. Incluso tiene un cartel que dice que se ha financiado con fondos Next Generation, que son los fondos para la recuperación económica, una página así no tiene sentido que se financie con estos fondos. Pues es real. Es un error de ciberseguridad. Yo le aconsejo que no crea jamás que una web que no lleve el ...

La diferencia entre Suministrador, Proveedor y Partner

Algunas veces se usan las palabra suministrador, proveedor o partner como si fueran sinónimos, pero son diferentes conceptos aunque las tres se refieren a una organización externa que es parte de la cadena de producción. Antes de hacer referencia a la definición hablemos de qué tipo de recursos y bienes necesita una organización de otra externa. Sin importar si es una empresa privada, una empresa pública, una ONG, o cualquier otro tipo de organización; se necesitan terceros que proporcionen recursos para que la organización pueda construir sus propios servicios. ¿Qué tipos de recursos necesita la organización? Insumos y bienes generales: En la empresa se necesita papel, bolígrafos, grapas, tinta, café, carpetas, y otros insumos que son necesarios e importantes pero que quizá los empleados ni siquiera presten atención a la marca, de dónde vienen o dónde se almacenan. Hay otros posibles insumos y bienes como la electricidad, los teléfonos, Internet, quizá el metro y el autobús; estos...

Error al descomprimir un zip, ruta de acceso demasiado larga

Si está intentando descomprimir un archivo .zip y recibe el mensaje de error "Ruta de acceso demasiado larga". No se preocupe, no hay ningún problema en el archivo. Todo lo que tiene que hacer es copiar el archivo .zip en una carpeta directamente debajo de la raiz del disco duro, por ejemplo en la ruta c:\temp . Vuelva a dar la instrucción para descomprimir el archivo y todo funcionará con normalidad. ¿Por qué ocurre esto? Seguramente el archivo .zip que quiere descomprimir está en una ruta muy extensa, es decir, debajo de muchas muchas carpetas. Windows suma al nombre del archivo toda la ruta, por lo que los archivos están excediendo el tamaño máximo de 260 caracteres.  El mensaje de error 0x80010135 es un mensaje de Windows, no del gestor de .zip. Así de fácil. Después de descomprimir puede usar el gestor de archivos de Windows para copiar la carpeta que se ha extraído en la ruta deseada.