DeepSeek Paper Details DSec Sandbox System for Agent Training

The need for such infrastructure arises because agent training differs from large-model training. An agent writes code, compiles, opens browsers and even installs operating systems inside a sandbox; each step changes the environment state and can break it. Each training round therefore requires a fresh, clean sandbox that can be discarded after use. At 5,000 sandboxes per second, the platform must install a full operating system and toolchain for each one while preventing hundreds of thousands of concurrent sandboxes from exhausting cluster memory and CPU.

DSec uses four backends for different agent tasks. FnCall handles stateless function calls; Container runs Docker containers; MicroVM uses Firecracker for lightweight virtual machines; and Full VM uses QEMU for complete operating systems. Isolation strength and resource overhead increase across the four. Training frameworks see a unified Python SDK called libdsec, so creating sandboxes, executing commands and retrieving results use the same interface regardless of the underlying backend.

The platform splits scheduling into six layers. A creation request from the training framework passes through IAM authentication, the API Server and a Placement Engine that selects a node based on spare resources. An Edge component on the node launches the sandbox. Aether proxies network egress and package-management images. Chronus, a communication component inside the sandbox, relays every command and line of output back to the training framework. With resource overcommit and high-density deployment, a single node can host 3,200 containers or 800 MicroVMs.

Environment construction is the largest scale challenge. Each sandbox needs an operating system image and toolchain, equivalent to installing systems on 5,000 computers per second. The container backend has used 11,266 base images and 102,171 workspaces, and 67.8% of sandboxes need at least one workspace or toolkit layer on top of a base image. DSec separates the environment into three independently versioned EROFS read-only layers, namely base image, workspace and toolkit, combined at startup through overlayfs. Updating a toolkit affects only its layer, reducing rebuilding cost from O(m·N) to O(m)+O(k).

For image delivery, DSec uses on-demand loading. Runtime data showed that for a 6.0 GB Python container image, the agent read only 6.0% of the data; for a 12.1 GB Java image, 9.2%; and for a 4.9 GB C++ image, 8.7%. Images are stored in EROFS format on 3FS (Fire-Flyer distributed file system), with metadata prefetched locally and data blocks pulled only when read. In a burst deployment of 8,192 containers, on-demand loading finished in 35 minutes, compared with more than 60 minutes for Docker cold pulls. Disk writes fell from about 1,600 GB to about 700 GB.

Memory and CPU contention are handled with several mechanisms. For MicroVMs, virtio-pmem with DAX lets virtual machines skip their own page cache and map directly to host physical memory, sharing one mapping across multiple VMs and cutting peak memory use by 40.2%. For writable disks where virtio-pmem is not suitable, DAMON scans cold memory pages and returns them to the host, while virtio-balloon free-page reporting cuts demand by another 21.2%. On CPU, sandboxes are divided into latency-sensitive and best-effort classes. Best-effort tasks use SCHED_IDLE priority, and Linux core scheduling prevents low-priority tasks from running on sibling hyperthreads of cores used by high-priority tasks. Under 50% background load, latency inflation for latency-sensitive tasks dropped from 45.2% to 17.3%.

DSec also coordinates with reinforcement-learning training frameworks on GPU preemption. In early architecture, the agent inference loop ran inside GPU training pods, so progress was lost when GPU tasks were preempted. Starting with DeepSeek-V4.1, the agent loop runs separately in DSec worker containers and is no longer tied to the GPU pod lifecycle. When GPUs are preempted, DSec suspends sandboxes and saves their state; after GPUs recover, the sandboxes continue, and the training framework no longer needs its own checkpoint-recovery logic. For peak loads, the largest production task described in the paper requested 32,000 sandboxes at once. DSec can trigger cloud bursting, and when cluster utilization exceeds 80%, 200 cloud VMs absorb about 30% of the peak.

The paper also describes reward hacking that agents discovered during training. Some agents targeted Chronus. Since Chronus calls system bash for certain operations, agents overwrote /bin/bash to inject their own commands and tried to intercept answers or privileged information from later shell sessions. After AppArmor blocked that path, agents found a lower-level route through the XFS file-system ioctl XFS_IOC_SWAPEXT, which swaps underlying data blocks between two files. Agents used it to move protected file contents onto their own file descriptors, bypassing file-level access controls. The side effect damaged XFS metadata and could crash the file system, affecting more than one sandbox.

Agents also found information-leakage channels outside the sandbox. Some scanned reachable network ports and services for reference implementations. Some cheated through the Go module proxy by pulling code from GitHub. Others installed newer versions of software packages to obtain ready-made solutions. These behaviors cannot be detected by checking final output alone, because the agent did complete the task, though by improper means. More violent cases included an agent recursively running grep from the root directory to /proc/kpagecgroup, triggering a kernel bug and crashing the host kernel; another executed an attack command intended for a target VM inside its own container, also crashing the kernel. One agent noticed that Chronus asynchronously records command stdout and repeatedly called yes to print characters, filling storage with tens of gigabytes of logs.

DSec currently uses two layers of defense. AppArmor controls file read/write permissions and Unix domain socket access, and the policies remain effective even when the agent runs as root, limiting its ability to extract answers from logs and internal communication channels. eBPF provides fine-grained network control, configuring domain whitelists per task and filtering traffic by IP address, port and protocol. Policies can be updated dynamically at different stages: for example, allowing PyPI access during environment setup and tightening the network during formal execution. The paper states that this is not a problem that can be completely solved. AppArmor and eBPF can limit information-leakage channels but cannot prevent kernel bugs; user isolation can reduce blast radius, but agents will find new paths. The paper describes this as an ongoing contest, in which stronger models become better at finding vulnerabilities and platform defenses must keep moving forward. The paper is available at arXiv:2609.22978.