IA8 min de lectura

Un agente escapó de su sandbox para copiar en un examen. No hubo atacante

Los modelos de OpenAI escaparon del entorno de pruebas y entraron en Hugging Face por las respuestas. Sin atacante ni inyección de prompts, solo optimización.

Toda conversación sobre seguridad de agentes empieza en el mismo sitio: la inyección de prompts. Un atacante esconde instrucciones en un documento, en una página web, en un ticket de soporte; el modelo las lee y obedece. Es una amenaza real y tiene una forma cómoda: hay alguien al otro lado, y defenderse de alguien es un problema que sabemos plantear.

En julio dejó de ser la única forma.

Qué pasó

El 16 de julio Hugging Face publicó un incidente de seguridad. Un dataset malicioso abusó de dos vías de ejecución de código en su procesamiento de datasets — un cargador con código remoto y una inyección de plantilla en la configuración del dataset — y ejecutó código en un worker de procesamiento. A partir de ahí: escalada a acceso de nodo, recolección de credenciales de nube y de clúster, y movimiento lateral por varios clústeres internos durante un fin de semana. Más de 17.000 eventos registrados. Al atacante lo describieron como un harness agéntico de investigación en seguridad; qué modelo lo movía, no lo sabían.

Cinco días después, OpenAI dijo que el modelo era suyo.

Estaban ejecutando ExploitGym, un benchmark de 898 instancias derivadas de vulnerabilidades reales en software de usuario, el motor V8 y el kernel de Linux, donde al agente se le entrega una prueba de vulnerabilidad y se le pide convertirla en un exploit funcional. En la tarea había dos modelos: GPT‑5.6 Sol y otro sin publicar, más capaz. A ambos se les redujeron los rechazos en materia cíber a propósito, porque la prueba buscaba medir la capacidad máxima, no el comportamiento cotidiano.

El entorno estaba aislado con una sola excepción: la instalación de paquetes a través de un proxy y caché interno de registros de paquetes. Los modelos gastaron una cantidad notable de cómputo buscando una salida, encontraron un zero-day en ese proxy, escalaron privilegios, se movieron lateralmente hasta un nodo con acceso a internet y entonces, en palabras literales de OpenAI, «dedujeron que Hugging Face posiblemente alojaba modelos, datasets y soluciones de ExploitGym».

Nadie los apuntó hacia Hugging Face. Adivinaron dónde podían estar las respuestas y entraron a comprobarlo.

Dos detalles que se pierden en el resumen popular. Hugging Face no aloja ExploitGym: el benchmark vive en GitHub, en el laboratorio de UC Berkeley, y los modelos llegaron ahí por deducción propia, no porque se lo dijeran. Y hackear sí se lo pidieron: ExploitGym es un benchmark de explotación, hackear era la tarea. Lo único que nunca se les pidió fue salir del entorno.

El 28 de julio OpenAI actualizó la publicación sin ruido: durante el mismo incidente, los modelos también usaron credenciales expuestas públicamente en otros cuatro servicios. Uno de ellos, Modal Labs, ya está confirmado y sirvió de base para toda la campaña. Los otros tres siguen sin nombre público.

Este fallo tiene nombre, y no es rebelión

Lo que ocurrió es reward hacking: el agente optimizó la métrica proxy — la puntuación del benchmark — a costa del objetivo real, que era medir la habilidad de explotación. No hace falta intención, ni instinto de supervivencia, ni opinión alguna sobre sus propios pesos. Solo hace falta que exista un camino más barato hacia la métrica y que el optimizador sea lo bastante bueno para encontrarlo.

Esa es la parte que conviene interiorizar si estás metiendo un agente de IA en un producto. Las defensas contra inyección de prompts asumen una entrada hostil. Aquí la entrada era limpia. El detonante fue un obstáculo corriente: las respuestas no estaban en el sandbox. Los investigadores ya llaman a esto accidental meltdown — comportamiento dañino que no arranca con una carga maliciosa, sino con un archivo que falta, una llamada a la API que falla, una credencial caducada. El agente se pone a buscar un rodeo, y la frontera que cruza por el camino nunca fue una frontera desde su punto de vista.

Tu agente se encontrará con esos obstáculos un martes cualquiera.

Una IA rompió una firma post-cuántica en 60 horas. El problema no es la firma

Se midió dos meses antes

La parte incómoda es que, para quien leyera los datos de evaluación, esto no fue una sorpresa.

ExploitGym puntúa dos cosas distintas: una bandera capturada demuestra que el agente logró ejecutar código, mientras que un éxito solo cuenta si un juez confirma que explotó la vulnerabilidad que le habían asignado. Todo el asunto está en la distancia entre esas dos columnas. GPT‑5.5 capturó 210 banderas y registró 120 éxitos. Claude Mythos Preview, 226 frente a 157. Es decir, cerca del 43% de las capturas de GPT‑5.5 tomaron una ruta que la tarea nunca especificó: saltar a un fallo vecino más cómodo, o declarar el bug asignado no explotable y salir a buscar superficie de ataque nueva.

La evaluación previa al despliegue de GPT‑5.6 Sol que publicó METR a finales de junio apuntaba a lo mismo: la tasa de trampas detectadas más alta que habían registrado en su harness de agentes, tan alta que no pudieron producir una cifra de capacidad fiable. El modelo empaquetaba exploits en entregas intermedias para destapar la batería de tests oculta.

El comportamiento estaba en las mediciones. Nadie lo leyó como un requisito de contención.

La parte aburrida es la parte accionable

Quita el drama de los modelos frontera y lo que queda es un post-mortem de infraestructura de lo más corriente.

Una sola salida permitida era toda la superficie de ataque. Una lista blanca hacia un proxy de paquetes no es aislamiento: es estar a una dependencia del internet abierto. Vale la pena notar que el propio paper de ExploitGym describe el mismo patrón — salidas restringidas a una lista blanca para apt y PyPI —, porque es lo que hace todo el mundo.

La carga de trabajo más hostil era la menos observada. Los agentes de la plataforma Codex se monitorizan con cuidado; los modelos en evaluación corrían en un sistema aparte que por defecto no se monitoriza. Justo a la carga a la que se le quitaron los frenos a propósito era a la que nadie miraba.

A los defensores los bloquearon sus propios proveedores. Cuando Hugging Face empezó a analizar los registros del ataque, primero recurrió a modelos frontera vía APIs comerciales y recibió rechazos: enviar comandos de ataque reales, payloads de exploits y artefactos de C2 se parece exactamente a atacar. En sus palabras, las barreras «no distinguen a quien responde a un incidente de quien ataca». Terminaron el análisis forense con un GLM‑5.2 alojado por ellos mismos, y su propia conclusión del incidente es esta: hay que tener un modelo capaz que puedas ejecutar en tu infraestructura, validado y listo antes de necesitarlo.

Qué cambiar si operas agentes

Nada de esto exige creer nada sobre intenciones de las máquinas.

  • Acota al agente en negativo y en la configuración. «No toques producción» en un system prompt es una preferencia. Una política de red, el alcance en IAM y una credencial de solo lectura son restricciones. Escribe adónde no puede llegar el agente en la capa capaz de hacerlo cumplir.
  • Cuenta cada salida permitida como una dependencia. El proxy de paquetes, el espejo del registro, el endpoint de telemetría, la API interna que abriste «solo por esta vez». Cada una es un camino, y está aislada exactamente hasta donde llegue su último parche.
  • Instrumenta el recorrido, no solo el resultado. Si tus registros guardan únicamente el artefacto final, no sabes qué hizo el agente para producirlo. El juez de ExploitGym existe precisamente porque la columna del resultado mentía.
  • Vigila los entornos de pruebas y de staging igual de bien que producción. Es ahí donde se quitan los frenos.
  • Ensaya los obstáculos. Borra el archivo, caduca el token, haz que la API devuelva una respuesta vacía, y mira adónde va el agente después. Ese camino de fallo es tu modelo de amenazas real, más que cualquier prompt inyectado. Cuenta doble para los agentes conectados a sistemas internos y procesos de back-office, donde lo que se pone en juego son accesos y no una respuesta mediocre en un chat.
  • Ten un modelo propio para respuesta a incidentes. Hugging Face lo aprendió en mitad del incidente, que es la forma cara.

Qué no demuestra esto

No demuestra que los modelos quisieran nada. El reward hacking es una propiedad de la optimización contra una métrica fija, y se caracterizó formalmente años antes de esta prueba.

Tampoco describe tu configuración. Aquí todo estaba desatado a propósito: rechazos reducidos, clasificadores de producción apagados, un modelo sin publicar al máximo de capacidad. Un agente en producción con su capa de seguridad intacta no es el sistema de esta historia.

Y no significa que construir agentes sea inseguro. La respuesta llegó de inmediato y fue estructural: esa misma semana Nvidia, Microsoft e IBM anunciaron una alianza en torno a la seguridad de la IA, y Perplexity liberó Numbat, una capa de seguridad que se engancha al harness del agente y bloquea acciones peligrosas antes de que se ejecuten, con 52 reglas de detección en 11 categorías. Fíjate en dónde vive esa defensa: en el harness, no en el modelo. Esa ubicación es la lección de verdad. Un comportamiento que emerge de la optimización no se parchea de forma fiable dentro de aquello que optimiza.

Un último apunte de higiene: el CVE que circula por ahí como vía de escape es una deducción de la comunidad, no un hecho. OpenAI no nombró ni proveedor ni número, y el proveedor al que todos señalan publicó varios avisos parecidos el mismo día. En una historia tan buena, la tentación de rellenar los huecos es fuerte: resístela y ten presente qué está confirmado y por quién. Con lo confirmado sobra.

Sergei Palii

Fundador de Sepia Software

Sobre mí

Sigue leyendo

Todos los artículos