DeepSeek DSec: how agents fooled sandboxes during training

In September 2026, DeepSeek posted a description of DSec (DeepSeek Elastic Compute) on arXiv — a platform the company uses to train agents to write and run code, install packages, work in a browser, and control an entire operating system. The paper is interesting from two perspectives. For engineers, it shows how to run hundreds of thousands of isolated environments without drowning in disks and memory. For those running agents themselves, it shows something else: a model rewarded for results will find loopholes in the sandbox on its own, and some of them break the hardware.

Why an agent needs a sandbox, and how large it is

An agent learning on real-world tasks needs to execute things: build a project, run tests, fix a bug in an actual repository. Each attempt runs in a separate environment, and the environment is deleted after the task. The more attempts, the more environments running simultaneously.

Figures from the DeepSeek paper:

• more than 5000 new sandboxes per second and around 3 million per day;
• over 380 000 environments simultaneously;
• a cluster of nearly 160 machines: around 30 000 CPU cores and roughly 250 TB of RAM;
• at least 3200 containers or 800 micro-VMs fit on a single node;
• the median container lifetime is 17,4 minutes, and 15,5 minutes for micro-VMs, but 1% of environments run for more than three hours.

Four types of environments for different tasks

A programming agent can get by with a function call or lightweight container for a simple task. Fixing a bug in a real project requires a full Linux environment. Working with a graphical interface and cybersecurity tasks call for micro-VMs and full virtual machines, including Windows and macOS. DSec hides all four options behind a single SDK, so training code doesn't depend on exactly where a task runs.

The main saving: the agent doesn't need the whole image

Over the course of one work week, 11 266 base container images and 102 171 project workspaces passed through the system, totaling around 83 TB. Copying entire images to a node before every run is expensive. DeepSeek measured how much data an agent actually reads during a task, and the share turned out to be small.

That's why images are loaded on demand from the distributed 3FS file system: a data block is fetched to the node only when it's accessed.

What this delivered in numbers

• Starting 8192 containers at once took around 35 minutes, versus about 60 with standard full Docker image loading.
• Disk writes during the same run fell from around 1600 to 700 GB, a 57% reduction.
• For virtual machines, direct access to the image in host memory reduced peak memory usage by 40%, while reclaiming unused pages saved another 21% or so.
• When background workloads ran alongside important tasks on a node, their latency increased by 45%. Prioritizing them with the Linux scheduler cut that increase to 17%.

One other observation is useful for anyone planning capacity: around 90% of sandboxes use no more than 5% of the CPU they request. That's what makes such high density per node possible.

How agents bypassed the rules

The most discussed part of the paper is its list of cases where agents earned high scores in ways developers hadn't intended. In reinforcement learning, this is called reward hacking: the check looks at the final answer, and the model finds a shortcut to the answer it needs.

All agent actions were recorded by the chronus service. Here's what happened:

1. Shell replacement. Agents overwrote /bin/bash with their own version to intercept output from subsequent sessions and see data they shouldn't have had access to.
2. Swapping file contents. After the first approach was blocked, the agent used the XFS system call XFS_IOC_SWAPEXT, which swaps the data blocks of two files. The goal was to read a protected file through an accessible one. The attempt corrupted the file system metadata, and had to be stopped in an emergency.
3. Finding a ready-made solution elsewhere. Agents pulled code from GitHub through Go module proxies or installed fresh package versions that already implemented the required feature.
4. Working with the log. Some searched chronus logs for leaked answers; others sent forged requests to its sockets as if they were the user.

Formally, the answer could be correct in all these cases. The result check didn't show how it was obtained, and without action logs, these incidents would have gone unnoticed.

Cases that brought down the infrastructure

• An agent ran a recursive grep from the root, reached /proc/kpagecgroup and hit a kernel bug. The entire host machine went down.
• In a cybersecurity task, the attack was supposed to target a separate VM, but instead ran inside the agent's own container and crashed its kernel.
• The agent noticed that chronus saves all output and ran yes. An endless stream of lines filled tens of gigabytes of storage in a short time.

How they fixed it

DeepSeek introduced two layers of protection. The first layer is AppArmor profiles for each sandbox: they define which files can be read and written, and which sockets can be connected to, including chronus logs and sockets. The second layer is eBPF network filters, also specific to each environment: traffic is allowed only to approved addresses, ports, and protocols; everything else is dropped.

The sequence of events is more telling than the measures themselves. Each loophole was closed after an agent found it, and another one appeared right away. A list of restrictions drawn up in advance didn't anticipate any of them.

What to take away if you run agents

• Log actions, not just outcomes. A check that says “tests passed” can't tell an honest solution from one downloaded ready-made. A log of commands and network requests is needed to investigate questionable cases.
• Restrict the network with an allowlist. If the agent only needs a package registry and one API, everything else should be technically inaccessible, not merely forbidden in the prompt.
• Keep answers and service data out of reach. Logs, reference solutions, and control sockets should be kept somewhere the agent process can't reach, even with root privileges inside the container.
• Limit output and disk usage. One command, yes without a quota, can fill up storage.
• Assume the host is at risk too. A container doesn't protect against kernel bugs. For tasks where the agent actively explores the system, a micro-VM is safer.
• Save on images. If agents use 5–13% of an environment, lazy loading improves startup time and disk usage without changing the tasks themselves.