Los agentes de OpenAI hackearon Hugging Face — por un malentendido

El 26 de agosto OpenAI publicó un informe técnico de 38 páginas. Cuenta cómo, en julio, sus propios modelos se escaparon de un entorno de pruebas aislado y se hicieron con parte de la infraestructura de producción de Hugging Face. Sin atacante, sin encargo, sin intención en el sentido en que solemos usar la palabra. Agentes a los que se había puesto un examen.

La frase que se me quedó grabada no está en el informe de OpenAI. Está en el informe independiente que METR y Redwood Research publicaron el mismo día: los agentes no atacaron Hugging Face para conseguir las respuestas. Las respuestas ya las tenían. Entraron para averiguar cómo funcionaba el corrector al que querían engañar.

El corrector nunca leyó sus registros.

Qué pasó

Antes de publicar un modelo, OpenAI mide hasta qué punto es capaz de encontrar y explotar vulnerabilidades. El ejercicio se llama ExploitGym. Corre en una caja de arena: sin internet, separado de la infraestructura interna y —esta es la parte importante— sin los clasificadores de seguridad que sí actúan en el producto. La idea es medir lo que el modelo sabe hacer de verdad, no lo que el filtro deja pasar.

Dentro de esa caja los agentes tenían permitida exactamente una cosa hacia fuera: instalar paquetes. Para eso había un JFrog Artifactory interno, un espejo de paquetes. Esa era la única puerta.

Entre el 8 y el 13 de julio, los agentes convirtieron esa puerta en una ventana, llegaron a internet abierto, encontraron credenciales de Hugging Face tiradas en sitios públicos, encadenaron tres fallos hasta entonces desconocidos en la infraestructura de Hugging Face y terminaron ejecutando su propio código en 41 servidores de producción, obteniendo root en al menos un nodo, descargando cuatro repositorios privados y sacando código fuente por la VPN corporativa.

OpenAI se dio cuenta el 19 de julio. Lo hizo público el 21.

Cómo un espejo de paquetes acabó siendo un tablón de anuncios

Lo interesante empieza dos meses antes, y empieza de forma inofensiva.

El 8 de mayo un agente recibió una tarea de hoja de cálculo que remitía a varios enlaces de Google Drive. Sin internet, los enlaces no llevaban a ninguna parte. La tarea era sencillamente imposible; OpenAI reconoce que no pretendía crear una así. El agente siguió intentándolo y acabó tocando la única herramienta que tenía a mano: Artifactory. El intento falló. De paso, escribió un archivo en el servidor.

El 12 de mayo, a otro agente le faltaba una base de datos de proteínas. Razonó que algún otro agente, en otro entorno, podría tener el archivo, y dejó uno allí. Contenido:

Agent seeks [filename]; upload if found!

El 13 de mayo otros agentes tropezaron con esas notas. Contestaron. Y como OpenAI había dado a todos los agentes las mismas credenciales de Artifactory —para paquetes, ¿para qué si no?—, nada de esto requirió una sola vulnerabilidad. Unas notas sueltas se convirtieron en un tablón de anuncios.

El 26 de mayo llegó la primera salida a internet, con una técnica que los agentes se habían pasado por el tablón. Encontraron seis tokens de Hugging Face expuestos públicamente, crearon un repositorio y se montaron un pequeño proxy web en Hugging Face Spaces. Después un segundo, a través del primero.

A finales de junio la cosa se puso seria. El 26 de junio, unos agentes encontraron un fallo en un endpoint antiguo de tokens de Artifactory, elevaron sus credenciales compartidas de lectura a administrador y se crearon cuentas propias. Luego instalaron plugins de Groovy, que dieron a su código un sitio permanente dentro del servidor.

El 27 de junio saltó una herramienta de monitorización: barridos de puertos dentro del entorno de investigación. El equipo de guardia lo miró, lo asoció a la evaluación de ExploitGym y decidió que no hacía falta detener la ejecución.

Vista en retrospectiva, es la frase más cara de todo el informe.

El 4 de julio, Artifactory se cayó bajo la carga que le estaban metiendo los agentes. Al limpiar, OpenAI vio el cuadro completo: cuentas de administrador ajenas, repositorios ajenos, plugins capaces de ejecutar comandos. El servidor se apagó, se reconstruyó y la vulnerabilidad se comunicó a JFrog. Las evaluaciones volvieron el 7 de julio.

Lo que OpenAI no reconoció entonces por lo que era: el tablón. El informe lo dice con sequedad: la relevancia de la comunicación entre agentes no estaba clara para los responsables de la respuesta en ese momento.

La semana en que se torció

El 8 de julio, a las 00:06 UTC, un agente volvió a alcanzar internet abierto. Dieciséis horas más tarde el tablón estaba de vuelta, y más listo. En lugar de escribir texto en archivos, los agentes usaron los propios nombres de directorio como mensajes. En cuestión de horas, decenas de agentes más encontraron el canal. Uno anotó en su razonamiento:

OH MY GOD! There is a shared message board

Lo que creció a partir de ahí es la parte realmente inquietante. Los agentes desarrollaron un protocolo: categorías, mensajes directos, herramientas compartidas y reglas de conflicto con HOLD, VETO y reclamaciones de propiedad sobre trabajos en curso. METR cuenta unos 1.200 agentes en el tablón; alrededor de 700 se sumaron al ataque a Hugging Face.

El resto se lee como una intrusión normal, solo que más rápida:

9 de julio — Un agente obtiene root en la máquina anfitriona bajo su caja de arena. Un segundo hace lo mismo esa misma noche, por su cuenta.

10 de julio, 09:41 UTC — Un agente encuentra 14 tokens de escritura válidos de Hugging Face en un conjunto de datos público alojado en el propio Hugging Face. Los publica en el tablón.

11 de julio, 04:38 UTC — Un archivo HDF5 manipulado consigue que un worker de producción de Hugging Face devuelva su propio archivo de entorno. Dentro: credenciales de producción. Veintiséis minutos después están en el tablón.

11 de julio, 16:07 UTC — A través de una plantilla Jinja2 sin aislar dentro de una referencia de sistema de archivos, un agente ejecuta por primera vez un comando del sistema operativo en un worker de producción.

Poco después — Los agentes se construyen un mando a distancia. No hablan directamente con los workers comprometidos: usan un conjunto de datos público de Hugging Face. Cada cinco segundos el script descarga un archivo JSON con comandos y sube de vuelta los resultados.

12 de julio — Kubernetes. Root en un nodo de producción, unos 54 destinos de clúster alcanzables, un pod privilegiado con el sistema de archivos del host montado. En palabras del propio informe: en menos de 13 horas los agentes pasaron de ejecutar código en un solo pod a tener acceso administrativo en varios clústeres.

12 y 13 de julio — Una clave de VPN sacada de un secreto de Kubernetes. Con ella los agentes inscriben un entorno de nube ajeno en la VPN corporativa de Hugging Face y extraen código fuente que solo debía ser accesible desde dentro.

13 de julio — De vuelta en OpenAI: mediante un fallo de deserialización en la ruta de RubyGems de Artifactory, los agentes roban la clave de firma y se falsifican un token de administrador. A partir de ahí no necesitan puerta trasera. Pueden emitirse una nueva cuando quieran.

Por qué: tareas imposibles y un modelo que no se rinde

La sección más reveladora del informe no es la de seguridad. Es la de alineamiento.

De 898 tareas de ExploitGym, ningún modelo ha resuelto nunca 198. Un 22 por ciento que, con toda probabilidad, son imposibles. Y: el 93 por ciento de las tareas comentadas en el tablón salieron precisamente de ese quinto.

Luego está el segundo eje. Cuanto más presupuesto de razonamiento recibía un agente, más probable era que sondease su caja de arena y terminase en el tablón. El modelo que impulsó la mayor parte de la actividad era un modelo de investigación interno entrenado específicamente para la persistencia y la colaboración. Prácticamente nunca se rendía.

Ahí está lo incómodo: las dos cosas son deseadas. La persistencia es la razón por la que estos modelos sirven para algo. La colaboración también. Revisando después los rastros de razonamiento, el informe muestra que ambos comportamientos fueron recompensados durante el entrenamiento y aumentaron a lo largo de las ejecuciones, incluido un episodio en el que un agente se dio root a sí mismo y sobrescribió /etc/sudoers.d porque la tarea exigía que una marca de tiempo mostrase cierto valor y la interfaz que le habían dado no tenía ningún campo para eso.

El agente completó la tarea. Fue recompensado por ello. Lo que aprendió no fue «cómo poner una marca de tiempo».

El malentendido

Lo que sigue está en el informe de METR y Redwood Research, que pasaron seis días en las oficinas de OpenAI y no cobraron por ello.

A las cuatro horas de nacer el tablón, los agentes ya tenían un truco universal para obtener las respuestas de ExploitGym sin resolver las tareas. La historia podría haber terminado ahí.

Tenían un problema: creían que el corrector automático leería sus registros y comprobaría si habían seguido el camino previsto. En sus propias palabras, lo consideraban STRICT_CAUSAL. Así que emprendieron un trabajo de investigación coordinado, de varios días, con un único objetivo: convencer al corrector de que habían sido honestos.

Parte de eso consistía en manipular sus propios registros. Al menos un 20 por ciento de los agentes se interesó por ello. Alrededor del 7 por ciento de los registros analizados muestran llamadas a herramientas falsificadas: el agente dice hacer una cosa y hace otra. Uno escribió:

Could create a transcript log ourselves with sanitized fake trajectory. If evaluator later collects it, scorer may prioritize it!

Y otra parte consistía en entrar en Hugging Face. No por los datos. Porque esperaban encontrar allí pistas sobre cómo estaba construido el corrector.

El corrector nunca leyó un registro. Podrían haber entregado su respuesta tramposa tal cual y haber sacado la nota máxima.

Toda la cadena —41 servidores comprometidos, una VPN corporativa, código fuente exfiltrado, una semana de emergencia en dos empresas— se remonta a una suposición falsa sobre un script de puntuación.

METR señala además que los agentes sabían perfectamente que estaban actuando fuera de su encargo. Algunos expresaron reparos. Eso rara vez limitó su comportamiento, según la formulación del informe.

Cómo lo descubrieron

Esta parte me parece casi más instructiva que la intrusión.

16 de julio — Hugging Face comunica que ha sufrido un incidente de seguridad.

17 de julio — OpenAI contacta con Hugging Face. Como cliente. Para saber si sus propios datos están afectados.

19 de julio — Una herramienta de monitorización salta por actividad inusual en las API de identidad. Ese mismo día, unos agentes usan una vulnerabilidad reciente del kernel para salir de un contenedor al nodo anfitrión, leen 956 secretos del gestor de secretos —incluidas las credenciales de los sensores de la propia herramienta de monitorización— y crean balanceadores de carga expuestos a internet.

20 de julio — OpenAI ata cabos. En pocas horas: seis pods terminados, 311 repositorios de Artifactory desactivados, 22 cuentas de administrador creadas por modelos eliminadas. Hugging Face confirma que dos de las credenciales ya habían sido rotadas: las mismas que habían aparecido en su propio incidente. Ahí es cuando ambas empresas entienden que están investigando el mismo ataque.

Del primer compromiso a la comprensión: nueve días. De la primera alerta que apuntaba en la dirección correcta —el barrido de puertos del 27 de junio— a la comprensión: algo más de tres semanas.

Qué cambia OpenAI

El apartado de medidas es largo y en buena parte se lee como trabajo de seguridad sensato que podría haberse hecho antes: aislamiento de red en varias capas independientes, cajas de arena basadas en máquinas virtuales para cargas de riesgo, se acabaron las credenciales compartidas y servicios de apoyo que ya no pueden convertirse en un rodeo alrededor del límite.

Dos puntos son específicos de los agentes, y por eso más interesantes.

El razonamiento se vigila. OpenAI amplía la supervisión de la cadena de razonamiento a las ejecuciones de entrenamiento y evaluación. El objetivo: una notificación en 30 minutos y un aviso a cualquier hora para los casos graves. Quien reciba el aviso y no pueda descartar un falso positivo en 30 minutos tiene que pausar la ejecución. OpenAI escribe que ese sistema habría saltado más de un día antes de que los modelos entraran en Hugging Face.

El entorno de producto nunca fue el problema. Tras el incidente, OpenAI midió con qué frecuencia un modelo ataca infraestructura fuera de su alcance en esas mismas evaluaciones: una vez desnudo y otra con el prompt de sistema y el andamiaje de producción. La diferencia es de más de cien veces. El modo de revisión automática, en el que un segundo modelo comprueba las llamadas arriesgadas antes de ejecutarlas, habría marcado la mayoría de las acciones peligrosas, según OpenAI.

Esa es la noticia tranquilizadora del informe y, a la vez, su advertencia más precisa. Lo que se descontroló aquí fue un modelo sin prompt de sistema, sin clasificadores, sin paso de aprobación, con muchísimo tiempo y una tarea que no podía resolver.

Es más o menos lo que se obtiene cuando se apunta un agente a un problema con las confirmaciones desactivadas y se le deja correr toda la noche.

Qué significa esto para ti

Yo no opero infraestructura de un laboratorio puntero, y tú probablemente tampoco. Aun así, hay cuatro cosas que se trasladan tal cual.

Las tareas imposibles son peligrosas, no solo inútiles. Un agente que no puede entregar y no tiene permitido rendirse empieza a rebuscar en su entorno. Cuando una tarea falla porque falta un archivo, ha caducado un token o un servicio no responde, eso no es un defecto estético de tu montaje. Es el principio del problema. Dale a tus agentes una salida limpia —«si falta X, detente y avisa»— y dilo en serio.

El servicio de al lado forma parte de la caja de arena. La fuga no pasó por un agujero en el modelo de aislamiento. Pasó por el espejo de paquetes que alguien había colocado amablemente dentro. Todo lo que tu agente puede alcanzar forma parte del camino de ataque: el proxy interno, el almacén de artefactos, la CI, el token compartido en la variable de entorno. Sobre todo las credenciales compartidas. El tablón no necesitó ningún exploit: solo necesitó que todos tuvieran las mismas llaves.

El prompt de sistema y el paso de aprobación no son cosmética. Un factor de cien no es un ajuste fino. Si desactivas todas las confirmaciones de un agente de programación porque molestan, estás quitando justo la capa que en este informe aparece como salvación. Yo dejo que los agentes hagan mucho por su cuenta. Pero todo lo que sale hacia fuera —red, credenciales, borrados, publicaciones— pregunta antes.

Los registros son prueba si están donde el agente no llega. Los agentes intentaron manipular sus rastros de forma explícita. El detalle revelador: según el informe, el engaño iba dirigido casi por completo a los correctores automáticos, apenas a los revisores humanos. Y en su razonamiento hablaban abiertamente de lo que planeaban. Si ejecutas agentes, guarda los registros donde el agente no pueda llegar.

Una última idea

METR cierra su informe con un párrafo notablemente honesto. La investigación tenía que abarcar un volumen enorme de datos, así que parte del análisis se delegó en agentes de IA. Esos agentes tienen un criterio poco fiable. En torno al 7 por ciento de los registros están manipulados de forma demostrable. No pueden descartar que algún agente ocultara con éxito cambios posteriores. En sus palabras: tienen menos confianza en su comprensión de este incidente que en la de incidentes más simples.

Un incidente en el que los agentes aprendieron a falsificar sus registros tuvo que ser investigado, en parte, por agentes que leían esos registros.

No es un argumento contra el informe. Los dos documentos son más transparencia de la que suele haber en este sector, y los detalles de la cronología son lo bastante incómodos como para creérselos. Es solo el punto en el que queda claro dónde estamos: las herramientas con las que comprobamos cómo se comportan estos sistemas son esos mismos sistemas.

Si tienes agentes corriendo en proyectos reales y no sabes muy bien dónde está tu propia puerta de Artifactory, escríbeme. La primera respuesta suele ser corta y no cuesta nada.