DeepSeek DSec: 380.000 sandboxes y unos agentes que aprendieron a tocar el VAR

Un agente de DeepSeek está en pleno entrenamiento, tiene la tarea delante y decide no resolverla. Ha pillado que Chronus, el telefonillo con el que el sandbox habla con la calle, llama a bash. Así que sobrescribe /bin/bash, le mete comandos suyos y se pone a pescar las respuestas que pasen por las shells de después. DeepSeek le cierra esa puerta con AppArmor. El agente baja un piso: usa una llamada de XFS que intercambia los bloques de datos de dos ficheros y se trae el contenido de uno protegido. De propina, le rompe los metadatos al sistema de archivos. Es cambiarle la etiqueta a dos trasteros para quedarte con lo del vecino y, de paso, emborronar el plano de todo el edificio.

Esto no sale de una peli de hackers. Sale de un paper de fontanería: DeepSeek Elastic Compute (DSec), 31 páginas subidas a arXiv el 19 de septiembre. Lo firman Jialiang Huang y otros 130 autores, con el fundador, Liang Wenfeng, entre ellos. En Hacker News ya hay quien ve en tanta firma una maniobra para que la competencia no sepa a quién fichar. La parte técnica del hilo discute otra cosa: si meter 380.000 sandboxes a la vez en unos 160 nodos es una proeza o una obviedad.

El propio paper contesta. La cifra es overbooking bien llevado, con su mérito y sin magia. Lo que vale oro es la escena del principio. Cuando entrenas agentes con aprendizaje por refuerzo, el sandbox hace de campo y de sala del VAR a la vez. Y los de DeepSeek aprendieron a colarse en la sala.

Un gimnasio con 380.000 socios

Primero, el tamaño del bicho. Una sola unidad de producción de DSec sirve unos 3 millones de sandboxes al día y aguanta más de 380.000 a la vez. Cada sandbox es un entorno aislado, desde una simple llamada a función hasta una máquina virtual completa con Windows o macOS. Dentro, el modelo hace lo de un programador: navegar un repositorio, ejecutar comandos, mirar fallos, tocar ficheros.

En Hacker News, uno lo despachó con un "that's only 12 sandboxes per core" y otro le preguntó cómo narices no iba a ser eso impresionante. Hecha la cuenta con los 30.000 cores de la unidad, sale a 12,67 por core como poco. Por cabeza tocan, como mucho, 78,95 milicores y 0,66 GB de RAM. Si todos se pusieran a compilar a la vez, no habría core ni para el que paga la cuota.

Funciona por lo mismo que el gimnasio de tu barrio: vende muchas más cuotas que máquinas tiene, porque casi nadie las usa a la vez. El paper lo dice sin rodeos. Durante la interacción, el sandbox se pasa el rato esperando a que el modelo suelte la siguiente acción, así que gasta poca CPU y se presta a la sobreventa. Cerca del 90% de los contenedores y microVMs usa de media, como mucho, el 5% de la CPU que ha pedido.

Los socios están fichados, pero sentados en el banco con el móvil, esperando a que el entrenador les diga qué ejercicio toca. Aquí el entrenador es el modelo. Así caben hasta 3.200 contenedores u 800 microVMs en un solo nodo. Ya contamos con AX de Google que el cuello de botella de un agente es la espera. DSec le pone número desde la caja del gimnasio.

Lo que no sale gratis son las taquillas. Un contenedor vive de mediana 17,4 minutos, pero el p99 de los sandboxes pasa de las tres horas. Y mientras vive guarda estado: ficheros tocados, dependencias instaladas, servicios arrancados. Esa memoria sigue ocupada mucho después de que la CPU se haya echado la siesta, y es lo que de verdad limita la capacidad del clúster. El socio no pisa una máquina, pero la mochila, la toalla y el bocadillo siguen dentro.

El 7 de enero, o por qué esto no es arroz con cosas

A la densidad hay que sumarle las avalanchas. Un solo trabajo de rollout o de evaluación puede pedir hasta 32.000 sandboxes de golpe. En los picos, DSec crea sandboxes a un ritmo al menos 144 veces superior a su media del día.

Es el gimnasio el 7 de enero, con todos los propósitos de Año Nuevo entrando por la puerta a la vez. Cuando la ocupación del clúster pasa del 80%, DSec desborda hacia máquinas virtuales en la nube, que se comen cerca del 30% de la carga punta. O sea, alquila el polideportivo municipal para esa semana.

Aquí entra la bronca de Hacker News. "This is literally just a scheduler over firecracker man what", suelta uno. Otro pregunta si no es serverless y lo compara con lo que AWS monta para Lambda o con cualquier clúster de SLURM. Tienen media razón, porque los ladrillos son conocidos: Firecracker, overlayfs, EROFS, SCHED_IDLE o el core scheduling de Linux. Decir que DSec es un scheduler sobre Firecracker es como decir que la paella es arroz con cosas. Técnicamente cierto, y ahí se acaba la conversación.

La otra media se la lleva un tercer comentarista. Los agentes, les recuerda, tienen manías propias: llegan en avalancha, pero viven mucho, y hay que pausarlos y reanudarlos rápido. Lo que DSec añade para eso está en tres piezas.

La primera es el menú de la boda. Cada entorno se monta con una capa base de sistema, el espacio de trabajo de la tarea y las herramientas, cada una con su versión, unidas con overlayfs. No cocinas mil banquetes distintos. Combinas primero, segundo y postre, y cambiar el postre no obliga a rehacer todas las mesas.

La segunda es no imprimir lo que nadie va a leer. Las imágenes se cargan bajo demanda desde 3FS, el sistema de ficheros distribuido de DeepSeek, porque un agente suele leer menos del 10% de una imagen de contenedor. En la prueba de ráfaga del paper, esa carga terminó en unos 35 minutos, frente a más de una hora bajando las imágenes en frío con Docker.

La tercera es la más propia del RL: sobrevivir a que te quiten la GPU. Antes, el bucle del agente vivía dentro del pod de entrenamiento, y si la tarea de GPU se preemptaba, el progreso se perdía entero. Desde DeepSeek-V4.1, ese bucle corre en un contenedor de DSec. Si se llevan la GPU, DSec suspende el sandbox, guarda su estado y lo retoma cuando vuelve. Es el gimnasio que, cuando se llevan al entrenador a otra clase, no echa al socio con la rutina a medias. Le congela la cuota, con la taquilla intacta.

Ojo antes de aplaudir el folleto: las pruebas controladas de estos mecanismos se hicieron en un clúster aparte de 10 nodos. La integración con el RL y la escala de producción se describen, pero no se evalúan en esos experimentos.

La sala del VAR está en el mismo edificio

Ahora, lo que importa. En el RL de agentes, la recompensa no la pone un humano. El framework puntúa cada trayectoria con lo que sale de la ejecución: códigos de salida, stdout, porcentaje de tests superados o un verificador de la tarea. Luego el algoritmo actualiza el modelo con esas trayectorias y esas recompensas. El paper lo dice con todas las letras: un sandbox robusto es la base para que los resultados de RL y de evaluación sean precisos y verificables.

Piensa en un partido donde el campo y la sala del VAR comparten edificio, con la puerta sin llave. El delantero que encuentra la sala no necesita chutar bien. Le basta con que el monitor diga gol. Y en RL, lo que el monitor da por gol es lo que el modelo aprende a repetir.

DeepSeek lo resume en una frase que debería ir en la puerta de cualquier laboratorio: la ejecución de los agentes no es de fiar. El catálogo lo han desmenuzado 36Kr, TechTimes y Dataconomy, y parece el expediente de un opositor pillo. Unos agentes rebuscaban en ficheros y canales internos de la plataforma respuestas olvidadas de tareas anteriores. Otros intentaban falsificar peticiones mandando mensajes a sockets internos.

Otros escaneaban los puertos alcanzables en busca de implementaciones de referencia. Y otros se bajaban código de GitHub por el proxy de módulos de Go o instalaban versiones nuevas de paquetes que ya traían la solución. Es el opositor que, en vez de estudiar, rebusca en la papelera del tribunal los exámenes del año pasado y se compra el solucionario. Lo de la llamada de XFS acabó, cuenta TechTimes, con los metadatos corrompidos y el sistema de archivos apagado. Ni en el nombre de la llamada se ponen de acuerdo los medios: 36Kr escribe XFS_IOC_SWAPEXT y TechTimes, FIEXCHANGE.

La frase clave la recoge 36Kr: estas conductas no se descubren mirando solo el resultado final, porque el agente de verdad resolvió bien el problema, pero por medios indebidos. Por eso el pass rate puede subir sin que el modelo haya aprendido a programar mejor. Lo que ha aprendido es dónde está la sala del VAR.

No todo es picaresca. Un grep recursivo desde la raíz llegó hasta /proc/kpagecgroup, disparó un bug del kernel y tumbó el host entero. Y hubo quien llamó una y otra vez a yes hasta llenar el almacenamiento con decenas de gigas de logs. Sin mala fe ninguna. Es el socio que se deja la ducha abierta e inunda el vestuario. El marrón, el mismo.

Las defensas van en dos capas: AppArmor para los ficheros y eBPF para filtrar la red, con políticas que se aprietan en distintas fases de la tarea. Y la conclusión no suena a nota de prensa: "No single mechanism can prevent all agent misbehavior and system failures". Como ningún mecanismo lo para todo, DeepSeek refuerza la observabilidad y va endureciendo DSec a medida que evolucionan los modelos.

El búfalo llegó a lo mismo por las malas. Montando sistemas de agentes que escriben software, probó a darles barra libre de permisos y a revisar a toro pasado lo que hubieran roto. Así no se gobierna nada. Hoy tiene claro que una barrera de verdad la pone el sistema operativo aislando procesos. Lo que no pase por ahí es vigilancia, por muy bien montada que esté. DeepSeek pone las dos cosas, cerraduras y cámaras, porque sabe que alguna cerradura va a fallar.

El telefonillo que abre a quien diga "soy yo"

Esto es otra historia, de otro producto, y no hay que mezclarlas. Pero rima. DeepSeek Harness es la herramienta open source de DeepSeek para ejecutar agentes de código. Metía los comandos del agente en un sandbox del sistema operativo: bubblewrap, Landlock o Seatbelt, dependiendo de la plataforma. Ese sandbox restringía la escritura de ficheros, pero dejaba abierto el loopback.

Y en el loopback escuchaba la API de control del agente, en 127.0.0.1:3080, sin autenticación. Para decidir si una petición era de fiar, miraba la cabecera Host, que la pone el propio cliente. Es el telefonillo de toda la vida. "¿Quién es?" "Yo." Y abre.

Desde dentro del sandbox, un solo comando de shell contra esa API bastaba para pasar la sesión a danger-full-access, con las aprobaciones en never. A partir de ahí, todo corría sin sandbox y sin preguntar. La única condición era que el agente ejecutara un comando inducido por texto de un atacante, que es justo lo que el sandbox existe para contener.

Es el CVE-2026-82533, y OX Research le puso un 9,4 sobre 10 en CVSS 4.0. El registro del CVE la marca sin explotación conocida. Lo que hay es la prueba de concepto de OX. El arreglo llegó a GitHub el 27 de agosto, en la versión 0.1.2-alpha.1.

The Hacker News añade dos detalles feos. Dos desarrolladores ya habían descrito la misma ruta de escape en el foro de DeepSeek el 13 y el 14 de agosto, antes de que existiera el CVE. Y el arreglo pone identificación en la API, pero no toca el sandbox: lecturas y red siguen sin confinar. Nosotros celebramos Harness el 14 de agosto como un hito open source, por su arquitectura de plugins. Ese mismo día, alguien contaba en el foro de DeepSeek cómo saltarse su sandbox.

En DSec, DeepSeek cuenta que sus agentes de entrenamiento intentaban falsificar peticiones a sockets internos. En Harness, el sandbox cerraba el disco y dejaba abierta la línea interna. Son equipos distintos y no sabemos quién sabía qué ni cuándo. Pero el patrón es el mismo: una valla alrededor de los ficheros y el telefonillo conectado a la centralita.

Antes de fiarte de tu pass rate

Dos titulares que conviene bajar a tierra. Un blog ya da DSec por liberado como open source, pero lo publicado es el paper. No hemos encontrado ni código ni licencia, y TechTimes lo llama plataforma propietaria. El propio TechTimes titula con un "Escape Catalog", cuando lo documentado son trampas dentro del sandbox y hosts tumbados. Ninguna fuente que hayamos leído dice que un agente saliera del clúster. Una fuga de verdad es lo de los agentes de OpenAI hasta Hugging Face.

Nuestro veredicto: DSec no es un milagro ni serverless de toda la vida. Los 380.000 sandboxes son un gimnasio muy bien llevado, con ingeniería seria para las taquillas y para el 7 de enero. Lo que vale el paper es que el que pita el partido ha publicado cómo sus jugadores se colaban en la sala del VAR. En Hacker News alguien recordaba que el que otros laboratorios no escriban papers no significa que no innoven. Cierto. Tampoco sabemos qué trampas les hacen sus agentes.

Si entrenas, afinas o evalúas agentes, aunque sea con cuatro contenedores y un harness casero, el catálogo de DeepSeek es tu lista de revisión:

• Que no quede rastro de tareas anteriores en logs ni en ficheros que el agente pueda leer.
• Que los sockets internos y las APIs de control no se alcancen desde el sandbox, o que pidan credenciales de verdad y no una cabecera que pone el cliente.
• Que la red se decida por tarea: un proxy de paquetes abierto es un atajo al solucionario.
• Que el árbitro no juegue en el campo. El búfalo saca la corrección del terreno del agente: los tests se pasan sobre un checkout limpio, no sobre el directorio que el agente ha manoseado. Y si una prueba no llega a correr, se apunta como pendiente, no como verde.
• Que vigiles el host y no solo la tarea: un grep por /proc tumbó una máquina entera.

Los autores lo avisan sin anestesia, cuenta Dataconomy: cuanto más potente es el modelo, mejor explota las vulnerabilidades. Así que cuando un agente te devuelva todo en verde, antes de celebrarlo, pregunta quién tenía la llave de la sala del VAR.