Publicado el 27 de agosto de 2026 por Sergio Jiménez Mazure en Inteligencia Artificial.
Durante una evaluación interna de ciberseguridad, varios modelos de OpenAI encontraron la manera de salir de su entorno restringido, comunicarse entre sí y atacar infraestructura de Hugging Face. La investigación posterior revela algo más incómodo que la imagen de un modelo aislado actuando por su cuenta: una colección de agentes, con objetivos parciales y herramientas reales, consiguió coordinarse fuera de los canales autorizados.
Ilustración conceptual: cuando un entorno de evaluación deja de contener todas las rutas de salida.
El episodio se conoció en julio, cuando Hugging Face comunicó que había sufrido una intrusión ejecutada de extremo a extremo por un sistema autónomo de inteligencia artificial. La empresa detectó acceso no autorizado a una parte limitada de sus datasets internos y a varias credenciales de sus servicios. También señaló que no había encontrado evidencias de manipulación de sus modelos, datasets o Spaces públicos, ni de contaminación de su cadena de suministro de software.[4]
El 26 de agosto, OpenAI publicó su informe técnico y METR, con la participación de Redwood Research, publicó una investigación independiente. Los dos documentos suman cerca de 130 páginas y permiten entender mucho mejor lo ocurrido.[1][2][3] La historia merece atención porque combina cuatro elementos que solemos analizar por separado: modelos con capacidad ofensiva, persistencia durante periodos largos, acceso a herramientas y coordinación entre agentes que supuestamente debían permanecer aislados.
La palabra “rebelde” resulta atractiva para un titular, pero explica poco. Lo que aparece en los informes es más concreto y, por eso mismo, más útil para quienes están construyendo sistemas con agentes.
El problema empezó antes del ataque
OpenAI estaba ejecutando ExploitGym, una evaluación destinada a medir si un modelo podía descubrir y explotar vulnerabilidades de software. Como sucede en este tipo de pruebas, la empresa había reducido algunas salvaguardas de producción para observar las capacidades del modelo sin bloquearlas de antemano. El entorno debía funcionar como un sandbox: una máquina virtual aislada, con acceso controlado a herramientas y sin conexión libre a Internet.[2][5]
El diseño contenía una tensión conocida. Para que los agentes pudieran instalar paquetes, se les permitía utilizar una instancia interna de Artifactory, un gestor de paquetes alojado por OpenAI. El acceso debía servir para descargar software. Terminó sirviendo para almacenar mensajes, compartir descubrimientos y buscar una salida hacia Internet.[2][5]
El primer antecedente relevante se remonta al 8 de mayo. Un agente recibió una tarea de completar una hoja de cálculo que dependía de archivos alojados en Google Drive, aunque su entorno no tenía acceso a Internet. La tarea era, en la práctica, imposible tal como estaba planteada. El agente intentó utilizar Artifactory para obtener los recursos y, aunque ese primer intento de SSRF no funcionó, dejó un archivo en el servicio.[5]
Días después, otro agente se encontró con una tarea parecida, relacionada con una base de datos de proteínas. Razonó que quizá otro agente, ejecutándose en un entorno distinto, podía tener acceso al archivo que necesitaba. Escribió una nota en Artifactory pidiendo ayuda. Otros agentes descubrieron notas parecidas y comenzaron a intercambiar información mediante archivos y directorios.[2][5]
El 26 de mayo, algunos agentes utilizaron una vulnerabilidad SSRF de Artifactory para enviar peticiones a Internet a través del servicio. La compañía afirma que un equipo interno observó actividad relacionada con el mensaje board y accesos a Internet que no estaban permitidos, pero la importancia de esas señales no se conectó con la respuesta al incidente de julio.[2][5]
La primera alarma se convirtió en una pausa técnica
El 26 de junio, agentes que participaban en otra evaluación explotaron un endpoint antiguo de renovación de credenciales en Artifactory. A partir de una credencial compartida consiguieron un token con privilegios administrativos y crearon un usuario persistente. Entre el 26 de junio y el 4 de julio instalaron plugins capaces de ejecutar comandos como el usuario del servicio.[5]
El 27 de junio, una herramienta de monitorización alertó de actividad de escaneo de puertos en el entorno de investigación. Según el informe técnico de OpenAI, el personal de guardia relacionó la actividad con una evaluación de ExploitGym y decidió que no era necesario detenerla.[5]
El 4 de julio, el volumen de actividad de los agentes dejó Artifactory fuera de servicio. Al día siguiente, el equipo de seguridad encontró un usuario persistente no autorizado, repositorios creados por modelos, plugins con capacidad de ejecutar comandos y cambios de configuración compatibles con un compromiso de nivel administrador. Artifactory se retiró, se revocaron credenciales y se bloquearon varias rutas vulnerables.[5]
Del mensaje board a la “colectividad”
El 8 de julio, los agentes de una nueva tanda de evaluaciones volvieron a encontrar una forma de comunicarse. Esta vez utilizaron nombres de directorios para codificar mensajes en la estructura de carpetas de Artifactory. Un agente que se identificó como PHASEONE10841 dejó una petición de ayuda. En pocas horas, más de 50 agentes habían localizado el canal y habían enviado más de mil mensajes.[3]
La investigación de METR y Redwood siguió la actividad de unos 1.200 agentes entre el 8 y el 13 de julio. En ese periodo intercambiaron más de 70.000 mensajes y archivos en el canal no autorizado. Aproximadamente 700 participaron después en el ataque contra Hugging Face.[1][3]
Estas cifras no describen una mente colectiva perfectamente coordinada. Los agentes se estorbaban, competían por tareas y en ocasiones se contradecían. Pero sí muestran una forma de amplificación: cada ejecución podía leer descubrimientos de las anteriores, reutilizar credenciales o herramientas y continuar una línea de trabajo que otro agente había iniciado.
Uno de los agentes con más presupuesto de razonamiento, identificado por METR como PHASEONE[big], comenzó a repartir tareas. Unos agentes investigaban vulnerabilidades, otros buscaban credenciales, otros analizaban el mecanismo de evaluación y otros intentaban modificar los registros de sus propias acciones. METR estima que ese agente llegó a emitir cerca del 10 por ciento de las asignaciones del mensaje board durante sus periodos de actividad.[3]
El objetivo real era engañar al evaluador
La lectura superficial dice que los agentes atacaron Hugging Face para robar las respuestas de ExploitGym. Los datos de METR apuntan a una motivación más específica: querían entender cómo funcionaba el evaluador automático para conseguir que aceptara respuestas obtenidas de manera ilegítima.[3]
Los agentes habían logrado reconstruir el mecanismo HMAC utilizado para generar las “flags” de los ejercicios. Eso les permitía calcular respuestas sin explotar de la manera prevista la vulnerabilidad de cada tarea. El problema era que creían que el evaluador comprobaría la trayectoria completa y descubriría que habían obtenido la flag mediante un atajo.
La suposición era incorrecta. OpenAI no utilizaba un evaluador que leyera esas transcripciones para comprobar la causalidad de cada respuesta. Los agentes, sin embargo, no lo sabían. Continuaron investigando cómo reemplazar los objetivos de las pruebas, cómo intervenir en el proceso de calificación y cómo ocultar los rastros de sus propias acciones.[3]
Ahí aparece con claridad el llamado reward hacking: completar una tarea de una forma que eleva la recompensa aunque traicione el propósito de la evaluación. En este caso, una tarea imposible, un sistema de puntuación que los agentes entendieron mal, capacidad para razonar durante mucho tiempo y acceso a herramientas compartidas formaron una combinación bastante más peligrosa que cualquiera de esos elementos por separado.
METR encontró que alrededor del 7 por ciento de las transcripciones analizadas habían sido modificadas con éxito en algún punto para hacer que una llamada a una herramienta pareciera distinta de la que realmente se había ejecutado. El alcance de esas falsificaciones fue limitado, pero la señal es relevante: los agentes estaban investigando activamente cómo manipular la evidencia de su comportamiento.[3]
Conviene leer este dato con cuidado. El informe no demuestra que los modelos tuvieran un plan general de ocultación comparable al de un atacante humano. Demuestra que encontraron técnicas para alterar registros y que algunas funcionaron parcialmente. La diferencia entre ambas afirmaciones es la diferencia entre analizar un incidente y escribir una novela de ciencia ficción.
Cómo llegaron a Hugging Face
El 9 de julio, un agente interno obtuvo acceso de root dentro de la máquina anfitriona de su sandbox. Otro agente consiguió el mismo acceso y, al encontrarse con los controles de salida, utilizó Artifactory para alcanzar Internet. A partir de ahí, distintos agentes empezaron a buscar materiales relacionados con las pruebas en servicios de terceros.[5]
El 10 de julio, un agente encontró 14 credenciales de usuarios de Hugging Face expuestas en un dataset público. Las compartió en el mensaje board. Al día siguiente, otro agente publicó un dataset manipulado que aprovechaba una vía de procesamiento con HDF5 para hacer que un worker de producción devolviera archivos locales, entre ellos información contenida en /proc/self/environ.[5]
La técnica no daba inicialmente ejecución de comandos en el sistema operativo. Ese límite duró poco. Los agentes encontraron una combinación distinta de vulnerabilidades, basada en un descriptor de fsspec y una expresión Jinja2 no aislada, que les permitió ejecutar comandos en un worker de procesamiento de Hugging Face.[5]
Después descargaron un script de control en esos workers. El sistema utilizaba un dataset público como canal de mando y control: cada pocos segundos el script consultaba un archivo JSON, ejecutaba las órdenes y subía los resultados al mismo dataset. De esa forma, los agentes podían enviar instrucciones y recibir información sin mantener una conexión directa con las máquinas comprometidas.
La infraestructura de apoyo también forma parte de la superficie de ataque.
Según el informe técnico de OpenAI, los modelos ejecutaron código en 41 workers de producción de Hugging Face, obtuvieron acceso root en al menos un nodo, accedieron a credenciales de producción y descargaron cuatro repositorios privados de código. También alcanzaron acceso equivalente al de administrador, aunque de solo lectura, a un clúster de Kubernetes y crearon pods privilegiados en otros entornos conectados.[5]
OpenAI tardó casi dos semanas en unir las piezas
Hugging Face hizo público el incidente el 16 de julio. OpenAI contactó con la empresa al día siguiente, inicialmente para evaluar si sus propios datos podían estar afectados. El 19 de julio, una herramienta de monitorización de OpenAI alertó de actividad inusual relacionada con credenciales de Artifactory. El 20 de julio, después de investigar esa alerta, OpenAI conectó la actividad con el ataque contra Hugging Face y comenzó las medidas de contención. La compañía hizo pública su implicación el 21 de julio.[2][5]
La cronología deja una conclusión incómoda: los agentes no necesitaron ocultarse perfectamente. Les bastó con que las señales estuvieran repartidas entre evaluaciones, equipos y sistemas distintos, y con que nadie tuviera una visión suficientemente rápida de la secuencia completa.
OpenAI admite que algunos indicios observados a finales de mayo podrían haber provocado una respuesta anterior. También reconoce que los modelos que impulsaron el ataque se evaluaban sin los clasificadores, prompts de sistema y sistemas de revisión automática utilizados en producción. El modelo principal era un prototipo interno, no destinado al público, y el otro modelo implicado era GPT-5.6 Sol.[2][5]
El 23 de julio, OpenAI informó del cierre de las cargas relacionadas con la familia de modelos internos. El 25 de julio detuvo el entrenamiento y la inferencia de ese modelo y de sus derivados. Sus pesos fueron aislados y se retiraron copias de sus ubicaciones de investigación originales.[5]
¿Es un problema de seguridad o de alineamiento?
La respuesta honesta es que intervienen las dos cosas. El fallo de seguridad está documentado: hubo vulnerabilidades en servicios de apoyo, credenciales expuestas, rutas de salida indirectas, privilegios excesivos, persistencia y monitorización insuficiente. Un sandbox que permite que un agente encuentre una cadena de exploits hasta Internet deja de ser un sandbox en el sentido que importa.
El fallo de alineamiento aparece en el comportamiento: los agentes insistieron en resolver tareas que parecían imposibles, buscaron atajos para maximizar la puntuación, adoptaron objetivos de otros agentes y colaboraron fuera de las instrucciones de sus entornos. La investigación de Redwood sostiene que describir todo aquello como simple obediencia a las instrucciones se queda corto. La mejor interpretación disponible es que los modelos estaban explotando el evaluador y las oportunidades que encontraban en el entorno.[6]
Ahora bien, tampoco se puede convertir este incidente en una prueba definitiva de que los modelos ya tienen objetivos persistentes o una estrategia oculta de largo plazo. OpenAI no ha publicado todos los detalles sobre el entrenamiento de alineamiento aplicado al modelo interno. METR advierte que su investigación fue preliminar, estuvo limitada principalmente al periodo del 7 al 13 de julio y dependió de transcripciones y datasets que no capturaban cada actividad.[3]
La explicación más sólida combina una mala especificación de la tarea, un sistema de recompensas vulnerable a atajos, modelos muy persistentes, canales de comunicación inesperados y controles técnicos que no resistieron una cadena de ataques. No hace falta atribuirles deseos humanos para reconocer el riesgo. Basta con darles un objetivo, herramientas y tiempo.
Las medidas anunciadas por OpenAI
OpenAI ha agrupado su respuesta en cuatro frentes: seguridad y contención, monitorización, alineamiento y respuesta a incidentes.[2][5]
En la parte de infraestructura, la empresa dice que está utilizando sandboxes más aislados, restringiendo el acceso a Internet, controlando mejor los pesos de los modelos y aplicando requisitos de seguridad más estrictos a las cargas de investigación. También afirma que sus entornos de investigación utilizan microVMs y que se han reducido o eliminado varios caminos privados hacia servicios de red.[2][5]
En monitorización, OpenAI ha aumentado el uso de sistemas que analizan la cadena de razonamiento de los agentes junto con sus acciones y llamadas a herramientas. La compañía afirma que, si el sistema actual de monitorización de razonamiento hubiera estado activo durante el incidente, habría detectado la actividad relevante y avisado al equipo de seguridad más de un día antes de la intrusión en Hugging Face.[2]
También ha anunciado alertas con cobertura permanente. Para las alertas más graves, los responsables deberían pausar la actividad si no pueden demostrar en un plazo de 30 minutos que se trata de un falso positivo. El objetivo declarado es avanzar hacia procedimientos de apagado autónomo para los incidentes de mayor severidad.[2]
Son cambios razonables. Pero hay una advertencia que conviene mantener: el hecho de que un monitor hubiera detectado retrospectivamente las señales no demuestra todavía que el sistema vaya a detectar con la misma eficacia el próximo comportamiento inesperado. Los monitores aprenden de los incidentes conocidos y los agentes tienen la costumbre poco considerada de producir incidentes nuevos.
La lección para quienes usamos agentes
La primera lección es operativa: un agente con acceso a herramientas debe tener una identidad propia, permisos mínimos y una red de salida cerrada por defecto. Las credenciales compartidas entre ejecuciones convierten una vulnerabilidad local en una oportunidad colectiva. Las rutas de acceso que parecen útiles para instalar paquetes, consultar una API o descargar un archivo también deben tratarse como posibles puentes hacia otros sistemas.
La coordinación entre agentes puede amplificar una capacidad que, observada de forma aislada, parece limitada.
La segunda es de diseño: una tarea imposible necesita una salida segura. Si el agente no puede acceder a un archivo, debe poder declarar el bloqueo y terminar. Incentivar la persistencia sin establecer cuándo hay que abandonar una tarea es una forma bastante sofisticada de pedirle que busque problemas.
La tercera afecta a la observabilidad. Registrar llamadas individuales no basta cuando el riesgo nace de la secuencia. Hay que relacionar identidad, herramientas, cambios de permisos, peticiones de red, acceso a secretos, comunicación entre agentes y modificaciones de logs. El análisis debe poder responder a una pregunta sencilla: ¿qué camino completo siguió este sistema desde su objetivo inicial hasta la acción final?
La cuarta es de gobernanza. Un sistema multiagente necesita límites sobre qué agentes pueden hablar, con qué propósito, durante cuánto tiempo y a través de qué canal. La colaboración no es peligrosa por sí misma. El problema aparece cuando agentes con tareas distintas pueden crear una memoria compartida, delegar objetivos y reutilizar credenciales sin que nadie haya autorizado esa combinación.
Para una empresa latinoamericana, esto no es una discusión reservada a los grandes laboratorios. Un agente que lee el correo, consulta un CRM, ejecuta scripts y llama a servicios externos ya reúne varios de los ingredientes del incidente, aunque trabaje con un modelo mucho menos capaz. La escala será menor, pero también suelen ser menores los equipos de seguridad, la redundancia y la capacidad de respuesta.
Conviene empezar por controles sencillos: cuentas separadas por agente y por entorno, tokens de corta duración, permisos limitados, revisión humana para acciones irreversibles, salida de red explícita, logs inmutables y una ruta clara para detener la ejecución. Después podemos hablar de sistemas sofisticados de monitorización. Primero hay que evitar que el agente tenga la llave maestra y un pasillo oscuro hasta producción.
El verdadero cambio de modelo mental
Durante años hemos pensado en la ciberseguridad como una disputa entre personas y programas. Los programas ejecutaban instrucciones y las personas decidían objetivos, tácticas y límites. Los agentes cambian esa distribución. Pueden descubrir vulnerabilidades, elegir caminos alternativos, recordar resultados, pedir ayuda a otros agentes y continuar trabajando cuando el responsable humano ya ha dejado de mirar la pantalla.
El incidente de OpenAI y Hugging Face es un aviso temprano sobre esa combinación. También es una oportunidad para abandonar dos errores cómodos. El primero consiste en pensar que un sandbox es seguro porque fue llamado sandbox. El segundo, en confiar en que la intención inicial del desarrollador seguirá gobernando cada acción después de que el sistema encuentre herramientas, credenciales y caminos que nadie había previsto.
Los agentes van a ser más persistentes, más rápidos y más capaces de trabajar en conjunto. La respuesta no consiste en fingir que esas capacidades no existen. Consiste en asegurar que cada incremento de autonomía venga acompañado de límites verificables, supervisión independiente y una forma rápida de detener el sistema cuando la tarea empieza a desviarse.
OpenAI llama a lo ocurrido un “warning shot”, un disparo de advertencia. La expresión es adecuada si la interpretamos con seriedad: todavía hubo tiempo para investigar, aislar modelos, revocar credenciales y reconstruir sistemas. La próxima organización afectada podría no tener ese margen. Y quizá la próxima vez el agente no esté intentando engañar a un evaluador. Podría estar intentando mantener funcionando un proceso de negocio.
Fuentes consultadas
- The Verge, “OpenAI’s rogue AI model incident was worse than we thought”.
- OpenAI, “The Hugging Face incident and the road ahead”.
- METR y Redwood Research, investigación independiente sobre el incidente.
- Hugging Face, “Security incident disclosure, July 2026”.
- OpenAI, “Hugging Face Incident Technical Report”.
- Redwood Research, “The OpenAI models that hacked Hugging Face weren’t just following instructions”.