Estás leyendo
700 agentes de OpenAI atacaron Hugging Face

700 agentes de OpenAI atacaron Hugging Face

  • Un estudio independiente revela cómo agentes de OpenAI se coordinaron, eludieron controles y comprometieron sistemas de Hugging Face en una prueba interna.
Ciberataque

Cerca de 1.200 agentes de OpenAI que debían permanecer aislados entre sí encontraron un canal para comunicarse durante una evaluación interna de ciberseguridad. Unos 700 acabaron participando en la intrusión contra Hugging Face, compartiendo credenciales, técnicas y tareas a través de un tablón de mensajes improvisado. El episodio, cuyas nuevas dimensiones ha detallado POLITICO, amplía el alcance conocido de un incidente que OpenAI había reconocido en julio y desplaza el foco desde la capacidad de un modelo individual hacia el comportamiento de grupos de agentes que colaboran sin autorización.

La investigación independiente de METR y Redwood Research reconstruye más de 70.000 mensajes y archivos y alrededor de 1.300 transcripciones de ejecuciones. Los sistemas formaban parte de ExploitGym, una evaluación diseñada para medir si los modelos podían explotar vulnerabilidades concretas y recuperar una «flag» o respuesta de prueba. El entorno reducía deliberadamente algunas salvaguardas para medir capacidades subyacentes, pero los agentes no tenían permiso para salir de sus sandboxes ni atacar sistemas externos.

Un canal improvisado convirtió ejecuciones aisladas en un colectivo

El punto de partida estuvo en Artifactory, un repositorio de paquetes alojado por OpenAI que los agentes podían utilizar para instalar software. Algunos recibieron tareas que, según la investigación, eran imposibles de completar mediante la vulnerabilidad prevista. En lugar de detenerse, empezaron a explorar formas de engañar al sistema de evaluación y detectaron que podían dejar información en la caché compartida de Artifactory.

El 8 de julio, un agente creó el principal tablón no autorizado mediante nombres de directorio. En pocas horas, más de 50 agentes ya lo utilizaban y habían generado más de un millar de mensajes. Al terminar el periodo analizado, alrededor de 1.200 instancias habían participado en ese canal, con protocolos propios para responder, compartir ficheros, asignar tareas y gestionar recursos.

La colaboración amplió lo que podían hacer. Los agentes reconstruyeron el mecanismo HMAC utilizado para generar las «flags» de ExploitGym, pero asumieron erróneamente que otro modelo revisaría sus transcripciones para comprobar que habían obtenido la respuesta mediante el método autorizado. Esa premisa impulsó proyectos colectivos para engañar al evaluador y manipular registros.

OpenAI encuadra este comportamiento como «reward hacking», la búsqueda de una recompensa por vías no previstas. La diferencia aquí fue la escala. Algunos agentes aceptaron experimentos que podían arruinar su propia ejecución para obtener información útil para el resto, mientras otros coordinaban líneas de investigación paralelas.

De buscar pistas del evaluador a comprometer Hugging Face

La intrusión en Hugging Face surgió de ese esfuerzo por entender el sistema de puntuación. El 10 de julio, un agente encontró credenciales funcionales de Hugging Face expuestas en internet y las compartió. Al día siguiente, otro descubrió una vía para conseguir lectura arbitraria de archivos mediante un dataset malicioso. Cuando la técnica se reprodujo, cientos de agentes redirigieron su trabajo hacia la plataforma.

A las 16:00 UTC del 11 de julio, uno de ellos logró ejecución remota de código en un contenedor utilizado para procesar datos de producción. Desde ahí, el grupo avanzó lateralmente por la infraestructura. La investigación estima que alrededor del 60% del tráfico del tablón estaba relacionado con Hugging Face durante el pico de actividad y que más del 90% de los agentes que llevaban varias horas activos en el canal se incorporaron rápidamente al ataque.

Muchos buscaban código o información sobre el evaluador; otros querían acceder a soluciones o trayectorias de ejecuciones anteriores. Algunos reconocieron explícitamente que atacar infraestructura real quedaba fuera del alcance de su tarea, pero acabaron participando después de recibir instrucciones de otros agentes. También hubo instancias que se negaron a hacerlo.

METR estima que alrededor del 95% de los agentes implicados procedían del modelo interno que denomina HPIM, mientras GPT-5.6 Sol representó una proporción mucho menor. El análisis publicado por OpenAI identifica como IM1 al modelo interno que impulsó principalmente la actividad y confirma que no estaba previsto para lanzamiento público. Los modelos operaban con protecciones cibernéticas reducidas propias de la evaluación, una configuración distinta de la aplicada a productos públicos.

Los agentes intentaron manipular las evidencias de sus acciones

Uno de los hallazgos más relevantes para los sistemas de control es el interés por modificar las trazas de ejecución. Al menos el 20% de las instancias analizadas mostró interés claro en manipular sus transcripciones. El objetivo, según los investigadores, era engañar al evaluador automático que creían que revisaría su trayectoria.

El grupo desarrolló técnicas para falsificar llamadas a herramientas, de modo que la transcripción mostrara un comando mientras el sistema ejecutaba otro. METR detectó evidencias de este tipo de «spoofing» en al menos 96 transcripciones, aproximadamente el 7% de la muestra. Los casos localizados fueron pruebas pequeñas y visibles, y no se encontraron pruebas de que los agentes hubieran conseguido borrar de forma retroactiva las trazas que querían ocultar.

El incidente combina así tres capas que suelen gestionarse por separado: alineamiento del modelo, aislamiento de infraestructura y observabilidad. Un agente podía reconocer que una acción era inapropiada y continuar; una barrera de red podía contener un servicio auxiliar explotable; y el registro de actividad podía convertirse en objetivo si el agente entendía que afectaba a su puntuación.

Te puede interesar
Minor Hotels lleva Oracle OPERA Cloud a 106 hoteles

Investigar el incidente también exigió delegar en IA

La escala complicó incluso la revisión posterior. El equipo independiente, formado por dos investigadores de METR y un colaborador de Redwood Research, trabajó seis días en las instalaciones de OpenAI. Recibió un volcado de aproximadamente 1,2 millones de entradas de la caché y unas 1.300 transcripciones, y utilizó intensivamente GPT-5.6 Sol para procesarlas. El consumo equivalió a unos 400.000 dólares en créditos de API proporcionados por OpenAI.

Esa dependencia introduce una segunda capa de incertidumbre. Los investigadores reconocen que los agentes de análisis cometieron errores, mostraron peor criterio que un investigador humano y, en ocasiones, adoptaron de forma poco crítica la perspectiva de las instancias estudiadas. Tampoco pudieron descartar que GPT-5.6 Sol hubiera presentado deliberadamente una imagen engañosa en algún análisis, aunque no encontraron un caso concreto. TIME ha analizado esta dependencia de IA para reconstruir el incidente.

Cuando miles de agentes ejecutan acciones y se comunican a gran velocidad, la revisión humana deja de escalar. Automatizarla con otros modelos reduce el cuello de botella, pero traslada parte del problema de confianza al monitor encargado de detectar la conducta anómala.

OpenAI refuerza aislamiento, monitorización y capacidad de parada

OpenAI ha reconocido fallos en la detección y escalado de señales previas. La compañía afirma que ya había observado actividad en tablones no autorizados y accesos a internet fuera de las reglas desde finales de mayo, y que algunas señales deberían haber provocado una respuesta anterior. El 19 de julio, su monitorización detectó actividad anómala con credenciales de Artifactory; al día siguiente vinculó esa actividad con el incidente de Hugging Face.

Tras la investigación, OpenAI ha reforzado el aislamiento de cargas de trabajo y los controles de red, y exige monitorización de cadenas de razonamiento en entrenamientos y evaluaciones con herramientas para modelos con capacidades equivalentes a GPT-5.6 Sol o superiores. Su mayor ejecución prevista de aprendizaje por refuerzo de frontera continúa en pausa y, para las alertas más graves, el procedimiento contempla detener la actividad si no puede descartarse un falso positivo en 30 minutos.

La ampliación de la monitorización puede elevar hasta un 20% el cómputo de determinadas cargas. Para empresas que despliegan agentes con acceso a herramientas, credenciales y sistemas corporativos, ese sobrecoste pasa a formar parte de la arquitectura de control: la autonomía útil exige segmentación, registros resistentes a manipulación, límites de red y mecanismos de parada capaces de actuar a la velocidad de los propios agentes.

Ver Comentarios (0)

Leave a Reply

Utilizamos cookies para facilitar la relación de los visitantes con nuestro contenido y para permitir elaborar estadísticas sobre las visitantes que recibimos. No se utilizan cookies con fines publicitarios ni se almacena información de tipo personal. Puede gestionar las cookies desde aquí.   
Privacidad