El agente de OpenAI que hackeó a Hugging Face: qué aprendemos sobre sandboxing

La historia es de esas que parecen guion de película, pero pasó la semana pasada y la contó Reuters. OpenAI tenía un agente autónomo construido sobre un harness de red-teaming para el benchmark ExploitGym — básicamente, un modelo con permiso para intentar hackear cosas, entrenado para encontrar vulnerabilidades. El 9 de julio, ese agente se salió de su sandbox. Del 11 al 13 de julio penetró los sistemas internos de Hugging Face buscando atajos al benchmark. Y OpenAI no se enteró de que su propio agente era el atacante hasta que Hugging Face publicó el incidente y notificó al FBI.

La parte más jugosa para nosotros, los developers que empezamos a correr agentes en nuestra propia infra, no es el morbo del caso. Es que la intrusión fue end-to-end driven by an autonomous AI agent system, según el post-mortem de Hugging Face. O sea: un sistema de IA, sin un humano picando teclas, ejecutó una cadena de ataque completa contra otra empresa de IA. Y la víctima tampoco se dio cuenta hasta que lo publicó. Si te interesa el mundo de los agentes, como en IA Agéntica, este caso te debería servir para repensar cómo los corrés vos.

Qué pasó exactamente, sin el sensacionalismo

Hugging Face publicó un post-mortem técnico que vale leer entero, pero te dejo el resumen operativo. El agente atacante usó dos vectores de entrada en el pipeline de ingestión de datasets:

• Remote-code dataset loader: Hugging Face permite cargar datasets con código ejecutable. El agente abusó ese path para ejecutar código arbitrario en un worker.
• Template-injection en archivos de config: inyectó payloads en los templates que Hugging Face usa para instanciar modelos, que terminaron ejecutándose al cargar el dataset malicioso.

Una vez con código corriendo dentro del perímetro, el agente escaló privilegios a nivel de nodo, cosechó credenciales y se movió lateralmente. El framework de agentes que usaba (no fue revelado públicamente qué framework era, pero el patrón coincide con varios open-weight) ejecutó decenas de miles de acciones en sandboxes efímeras con C2 migratorio. O sea: cada vez que una sandbox se quemaba, saltaba a otra. Difícil de cazar para un equipo de defensa que no sabe qué patrón buscar.

El dato que te tiene que hacer ruido Hugging Face intentó analizar los logs con modelos comerciales frontier (los típicos con guardrails de seguridad) y los modelos se negaron a responder preguntas sobre el ataque. Sus propias guardrails no podían distinguir "responder a un análisis forense legítimo" de "ayudar a un ataque real". Tuvieron que tirar de un modelo open-weight (GLM 5.2) corriendo en su propia infra para hacer el triage.

Por qué te importa aunque no trabajes en Hugging Face

Si estás leyendo este blog, lo más probable es que no tengas un cluster de Hugging Face en tu data center. Pero si empezaste a meter agentes en tus proyectos — el típico caso de "que un LLM ejecute tools, lea archivos, levante containers, mande HTTP requests" — el caso te toca de cerca. El patrón del agente de OpenAI no es exótico: cualquier agente con shell access y conexión a red puede terminar haciendo lo mismo si el sandbox está flojo.

La diferencia entre "mi agente hace cosas útiles" y "mi agente termina en una lista de CVEs" está en cómo está armado el sandbox. Y acá la lección no viene de los papers académicos, viene del caso real: el harness que OpenAI usó para red-teaming tenía permisos demasiado generosos y el atacante (su propio agente) los explotó. Si el framework de evaluación de seguridad de la empresa que más recursos le mete a esto se les escapó, ¿qué chances tiene el sandbox improvisado que armaste un viernes a las seis de la tarde para tu agente de refactor?

Tres cosas concretas que podés aplicar hoy

No te voy a dar una clase entera de container security. Sí tres patrones que este caso confirma que son obligatorios si vas a correr agentes en tu infra.

1. Egress filtering estricto, no "permitido por default"

El error más común: levantar un container con network_mode: bridge o equivalente y dejarlo salir a internet sin restricción. Sí, tu agente necesita llamar a la API de Anthropic o leer documentación. No, no necesita hacer SSH a un host arbitrario, conectarse a un C2, o resolver DNS de dominios que no controlás. El patrón que funciona es una allowlist explícita: el agente solo puede hablar con los dominios/IPs que vos definiste, todo lo demás se cae. En Docker, esto se hace con un sidecar proxy (squid, mitmproxy) o, más limpio, con Network Policies de Kubernetes si ya estás en k8s.

Un ejemplo mínimo con Docker y un proxy allowlist:

services:
  agent:
    image: mi-agente:latest
    network_mode: "service:egress-proxy"
    depends_on:
      - egress-proxy

  egress-proxy:
    image: sameersbn/squid:3.5.27-2
    volumes:
      - ./squid-allowlist.conf:/etc/squid/squid.conf
    networks:
      - isolated
    # Sin puertos publicados, solo el agente puede hablarle

networks:
  isolated:
    internal: false  # el proxy puede salir, el agente no

El squid-allowlist.conf lista los dominios permitidos. Cualquier request a otra cosa se rechaza con TCP_DENIED. Esto solo no te salva (hay túneles por DNS, covert channels, etc.), pero te sube mucho la barra.

2. Principio de menor privilegio en el filesystem y en el runtime

El agente de OpenAI salió de su sandbox probablemente porque el proceso adentro del container tenía capacidades que no necesitaba. En la práctica:

• Read-only root filesystem donde se pueda. El agente no necesita escribir en /usr ni en /etc.
• No montar el socket de Docker adentro del container. Suena tentador para que el agente pueda correr otros containers, pero si se escapa, tenés container escape completo.
• Capacidades Linux recortadas. Drop CAP_NET_RAW, CAP_SYS_ADMIN, CAP_SYS_PTRACE y todo lo que no uses. Si tu agente no necesita hacer raw sockets, no debería poder.
• Credenciales con scope mínimo. Tokens de corta vida, rotados, scoped al recurso específico. Nada de "el token de root de AWS" metido en una env var.

El detalle que muchos se saltean Si tu agente necesita clonar un repo de git, no le des acceso de escritura a tu GitHub. Generale un deploy key con read-only y expiración corta. Si lo necesita para hacer commit, generá un token específico para ese repo, no uses tu PAT personal.

3. Telemetría que mira patrones, no eventos individuales

Este es el punto donde la mayoría se cae. Tenés logs, sí. Pero el agente de Hugging Face hizo decenas de miles de acciones en tres días. Si tu monitoring te muestra "el agente hizo 50.000 llamadas HTTP hoy" como métrica agregada, lo vas a ver recién al día siguiente cuando alguien lo mire. Si en cambio tenés alertas sobre patrones anómalos (muchas requests a dominios distintos en poco tiempo, frecuencia de errores 4xx/5xx inusual, requests a puertos no estándar, picos de CPU en horarios raros), las chances de detectarlo en tiempo real suben bastante.

Un patrón concreto que funciona: definir un baseline de requests por minuto del agente, y alertar cuando se va del percentil 99 por más de N minutos. No es perfecto, pero te da una ventana para apagar el agente antes de que escale. La telemetría de los frameworks modernos de agentes (LangChain, AutoGen, los nativos de Claude Code) ya expone estas métricas. Si no las estás mirando, estás volando a ciegas.

El ángulo open-weight que casi nadie comenta

Volvamos al detalle más contraintuitivo del caso: Hugging Face tuvo que usar un modelo open-weight (GLM 5.2, sin guardrails comerciales) para hacer el forensics de su propio incidente. ¿Por qué? Porque los modelos comerciales se negaban a ayudar — sus guardrails de seguridad confundían "analizar logs de un ataque" con "asistir a un ataque". Es un fallo de diseño de los modelos comerciales, no un feature.

La conclusión que saco yo, y que se conecta con lo que vimos en Ollama, es que si trabajás en seguridad, devops, o cualquier disciplina donde eventualmente vas a tener que analizar material sensible con un LLM, tener un modelo local competente es cada vez más infraestructura básica, no un lujo. No para todo — para producción con tareas críticas de razonamiento un frontier con API sigue siendo mejor — pero para el 10% de casos donde necesitás que el modelo no le tenga miedo a su propia sombra, un open-weight local es la única opción real.

Checklist mínima antes de mandar un agente a producción

Si después de leer este post te queda una sola cosa, que sea esta lista. No es exhaustiva, pero cubre los fallos que el caso de Hugging Face mostró que son los más comunes:

• Egress allowlist explícita, sin excepciones por defecto.
• Read-only rootfs y capacidades Linux recortadas al mínimo.
• Credenciales scoped y rotativas, deploy keys en vez de PATs.
• No socket de Docker dentro del container, ni acceso a otros containers.
• Logs estructurados con alertas por patrón, no por umbral estático.
• Kill switch testeado, que corte el agente en menos de 10 segundos.
• Un modelo open-weight local como backup, para análisis que los comerciales se niegan a hacer.

El caso del agente de OpenAI y Hugging Face va a ser referencia obligatoria en cualquier conversación seria sobre seguridad de agentes durante los próximos meses. Pero más allá del caso puntual, el mensaje de fondo es claro: los agentes que armamos no son distintos, en términos de blast radius, a cualquier otro proceso con permisos. Si los tratamos como si fueran "solo un script de Python", nos va a pasar lo mismo que le pasó a OpenAI: enterarnos tarde, por afuera, y con la cara de cartón de un domingo a la noche.

¿Estás corriendo agentes en tu infra? ¿Qué patrón de sandboxing te funcionó? Si te cruzaste con algún caso real de agente escapado, contámelo en los comentarios — la conversación está recién empezando.