DeepSeek has described a production sandbox platform built to give AI agents isolated places to execute code, call tools, access simulated services and be evaluated at industrial scale. The company’s DSec paper reports that the system supports roughly three million sandbox environments per day, more than 380,000 concurrent sandboxes, and peak creation throughput above 5,000 sandboxes per second.[1]
The figures matter because they shift attention to a less visible constraint on agent development. More capable models can plan and invoke tools, but they still need dependable environments in which to test those actions without corrupting shared systems, leaking data or making evaluation impossible to reproduce. DeepSeek presents sandboxing not as a narrow security control, but as a common execution substrate for training, reinforcement learning, benchmarking and production agent workloads.
- 3 million: reported sandbox environments served per day.
- 380,000+: reported peak concurrent sandbox environments.
- 5,000+: reported sandbox creations per second.
- 4 backend classes: function-call, container, microVM and full-VM execution.
A shared execution layer for agent work
Agentic systems differ from conventional chat applications because their value depends on actions outside the model. An agent may write and run software, query a database, navigate a browser-like environment, manipulate files, interact with an API, or complete a multistep task against a simulated enterprise service. Each attempt needs state, compute, credentials or mock credentials, network rules, time limits, observability and a way to cleanly reset after completion.
That workload creates a difficult systems problem. Training and evaluation can generate enormous numbers of short-lived sessions, many of them running untrusted code produced by a model. A platform must launch those sessions quickly enough not to leave expensive accelerators waiting; it must also isolate one task from another, collect results in a consistent form, and reclaim resources without residual state leaking into the next run.
DeepSeek’s DSec design addresses this by placing several execution models behind a unified sandbox interface. The paper describes four backend types: direct function-call execution, containers, microVMs and full virtual machines. The central idea is that a caller should request an environment according to its workload needs rather than be tightly coupled to a particular isolation technology.[1]
This matters operationally. A simple, trusted utility may be best served through a lightweight function-call backend. Code execution with familiar Linux-process semantics can fit a container. More hostile or less trusted workloads may require the stronger boundary offered by a microVM, while tasks that need broad operating-system compatibility or a complete machine image may require a full VM. A single platform that can route among those choices can avoid applying the costliest isolation mechanism to every task while preserving a path to stronger containment where it is justified.
Why the operational numbers are consequential
The reported scale is unusual because sandbox systems are often discussed in terms of security architecture, not fleet operations. Three million daily environments and more than 380,000 simultaneous instances imply a scheduler, control plane and cleanup system designed for highly bursty, short-duration work. A peak rate above 5,000 creations a second is especially significant for agent training, where large batches of model rollouts can produce synchronized demand for fresh execution contexts.
At that rate, startup latency becomes a model-development issue rather than an infrastructure detail. If a rollout waits on image pulls, host placement, guest initialization or network configuration, the training system loses wall-clock efficiency. If environments cannot be reliably reset, a model can receive reward signals shaped by stale files, altered databases or contamination from another trajectory. In both cases, the quality and cost of the learning loop are affected.
The DSec paper’s unified approach also addresses fragmentation. Large AI labs increasingly need different environments for coding tasks, web and tool-use benchmarks, software engineering agents, computer-use agents and domain-specific simulators. Maintaining separate provisioning, policy and telemetry stacks for each category makes it harder to compare outcomes and harder to audit failures. A common layer can standardize lifecycle controls: create an environment, apply policy, execute a task, capture artifacts and teardown the environment.
DeepSeek’s paper does not, by itself, establish that its platform is more secure or more efficient than every competing internal stack. The reported figures are self-reported production metrics, and the paper should not be read as an independently audited benchmark across providers. Still, the concrete numbers provide evidence that the company has invested in the operational machinery required to run agent tasks far beyond demonstration scale.
The technical trade-off: speed, fidelity and isolation
Each of DSec’s backend categories reflects a distinct systems trade-off. Function calls can minimize overhead and are appropriate where the tool surface is tightly controlled. They offer less of the general-purpose execution flexibility associated with a full operating environment. Containers generally start faster and use resources more efficiently than full VMs, but they share a host kernel, making the strength of isolation dependent on kernel hardening, runtime configuration and surrounding controls.
MicroVMs aim to occupy a middle ground: they use hardware virtualization to create a smaller virtual-machine boundary, typically with less device emulation and lower overhead than a traditional VM. Full VMs generally offer the broadest guest-OS compatibility and a substantial isolation boundary, but image management, boot time and memory consumption can make them expensive when workloads are extremely numerous and short-lived.
A unified sandbox system therefore needs more than an API façade. It needs placement logic that recognizes host capacity and backend requirements; image and artifact distribution that avoids repeated cold starts; network policy enforcement; resource accounting; health checks; and reliable destruction. For agent workloads, it also needs a durable record of what the agent saw and did. Replaying a failed trajectory may require preserving the task definition, tool responses, filesystem state, execution output and policy decisions.
The paper’s architecture is strategically relevant because the optimal backend is not fixed. As models become more autonomous and tasks become more open-ended, teams may move some evaluations from deterministic function tools toward richer, riskier execution environments. The ability to change the isolation level without rebuilding every application workflow can become an important development advantage.
Sandbox capacity becomes a competitive capability
The competition around AI agents is often framed around model reasoning, context length, tool schemas and benchmark scores. Those factors remain important, but they are incomplete. Agent improvement increasingly depends on generating large volumes of actionable trajectories: attempts that succeed, attempts that fail, tool traces, environment feedback and verifiable rewards. The environment is where that evidence is produced.
DeepSeek is one of the organizations making that infrastructure visible. Its DSec paper suggests that a frontier-scale agent program may need a platform capable of creating and disposing of environments at rates normally associated with large distributed computing services. That creates a different form of moat from model weights alone: operational expertise in isolation, scheduling, evaluation reproducibility and cost control.
Cloud providers, model developers and enterprise platform teams all have a stake in this shift. Cloud infrastructure companies can sell the underlying compute, networking and virtualization primitives. Model developers need controlled environments for post-training and evaluation. Enterprises deploying agents need more selective versions of the same capabilities: separation of customer data, least-privilege tool access, logging, policy enforcement and recovery from bad actions.
The commercial implication is not that every agent needs a VM. Many business tasks can remain behind narrow tool interfaces and approval workflows. But the share of workloads requiring realistic execution environments is likely to rise as agents move from answering questions to modifying codebases, processing documents, operating business applications and coordinating multistep workflows. Platforms that make stronger isolation cheap and fast enough for routine use will be better positioned to support that transition.
Limits, security questions and what remains to be proven
High provisioning rates are not the same as comprehensive security. Isolation failures can arise in the hypervisor, kernel, container runtime, management plane, network configuration, supply chain or application layer. A full VM can reduce certain risks relative to a container, but it does not make a poorly designed tool policy safe. An agent with valid credentials and overly broad permissions can still take damaging actions inside a perfectly isolated guest.
There is also a measurement question. Sandbox counts do not reveal the average duration, resource footprint, task complexity, failure rate or fraction of workloads using each backend. A platform that creates millions of very short function environments has different economics from one that maintains millions of long-running VMs. DeepSeek’s numbers demonstrate scale, but they are not a complete cost or performance comparison.
For enterprises, observability and governance may be as important as raw launch speed. They will need to know which agent invoked which tool, what data crossed a boundary, whether a task exceeded its intended scope, and how a result can be reproduced during an audit. The right architecture may include sandboxing alongside identity controls, narrowly scoped tokens, egress restrictions, approval gates and immutable logs.
DSec nevertheless clarifies the direction of travel. The next phase of agent infrastructure will be judged not only by whether it can contain hostile code, but by whether it can safely supply enormous numbers of realistic, resettable and measurable worlds in which agents can learn and work.
Editor’s Take
I see the 5,000-plus creations-per-second figure as the most telling part of this report. Model teams can describe an agent as tool-capable, but that claim becomes operationally meaningful only when thousands of simultaneous attempts can receive clean, fast and observable environments. Startup time, cleanup correctness and trace collection directly determine how quickly an organization can turn task outcomes into better models or safer product behavior.
The practical opportunity is a policy-driven execution fabric that chooses the cheapest adequate boundary: a constrained function for a safe operation, a container for ordinary code work, and a microVM or VM when the task warrants it. The hype will outrun the facts if sandbox scale is treated as proof of autonomous reliability. It is not. The next evidence worth watching is whether systems such as DSec can publish reproducible security properties, workload-level cost data and strong controls around credentials, network access and audit trails.
References
- DeepSeek, DSec paper – https://arxiv.org/abs/2609.22978
