An agent is only as capable as the environment it can safely act in.
To work autonomously, agents need a way to verify their own work. The agent can have a rich action space and a perfect reward signal, but without a real environment to execute in, those capabilities remain largely theoretical. As models become more capable, they're trusted with increasingly consequential work: modifying databases, running arbitrary code, deploying infrastructure, and interacting with production APIs. With a full runtime workspace, agents can verify their own work and iterate until success.
The challenge is to build a workspace that is indistinguishable from a developer's local environment while safely isolating the consequences of everything an agent does. A sandbox provides an isolated execution environment where an agent can safely run code, interact with services, and recover from failure. A well-designed sandbox gives an agent a real playground while ensuring every action remains isolated, reproducible, and disposable.
A great execution environment should have the following core properties:
1.
Control plane: keeping execution ready with minimum latency
Provisioning must feel almost instantaneous, making the experience responsive enough to become part of a developer's everyday workflow.
2.
Execution plane: a real machine, not a shell
The environment should feel indistinguishable from a developer's local setup. Agents need a real filesystem, Docker, customer repositories, databases, development services, networking, tools, and the same setup scripts they would execute in a real development environment.
3.
Security and Network plane: isolating capability without restricting it
Agents need the freedom to take meaningful actions, but every action should be isolated behind strong security boundaries. The goal is not to restrict what the agent can do inside its workspace, it's to ensure those actions execute safely within well-defined security, access, and network controls.
4.
Data plane: deterministic state at production scale
Every execution should begin from a known state, and every action should be recoverable. Identical inputs should produce identical environments, making failures debuggable, evaluations repeatable, and successful trajectories reusable.
Every design decision ultimately optimizes for the Pareto frontier across these core principles.
In this post, we walk through the core infrastructure powering the workspaces where agents execute, explore, and learn from experience. We talk about how we provision the workspace with the same capabilities as a real environment, including a real filesystem, Docker, networking, representative data, and production tooling, while ensuring every run remains isolated, reproducible, and disposable.
01
Overview
THE ANATOMY OF A WORKSPACE
PostgresRedisOLAPSECURITY & NETWORKCredential proxyattaches real key, never in the boxExternal APIsegressExecution tracepersisted outside the boundary
Expand
The control plane minimizes latency by ensuring execution environments are ready before they're needed. The execution plane provides the fidelity of a real developer workstation rather than a constrained runtime. The security plane enforces strong isolation without limiting what an agent is capable of doing. Finally, the data plane guarantees every sandbox begins from an identical, reproducible state.
02
Control plane: keeping execution ready with minimum latency
Agents are interactive systems, and every second spent preparing an execution environment is a second the user spends waiting. Booting a microVM, provisioning storage, cloning repositories, initializing services, loading tools, and performing health checks can easily dominate the critical path of a request. If every interaction requires creating a sandbox from scratch, even the most capable model quickly feels sluggish.
The obvious solution is to avoid creating sandboxes on demand.
The control plane orchestrates the lifecycle of execution environments, ensuring the right sandbox is provisioned, initialized, and assigned to an agent with minimal latency. It also maintains a pool of pre-provisioned execution environments that are ready to accept work immediately. Instead of booting a new sandbox for every request, the scheduler attempts to attach an agent to an existing warm sandbox. Cold starts occur only when the warm pool is exhausted or when a workload requires resources or configuration that are not already available. Daytona provides native support for warm sandbox pools, allowing us to pre-provision execution environments and attach agents to them with minimal startup latency.
A warm sandbox is much more than just a running virtual machine. By the time it enters the pool, the operating system has booted, Docker is running, repositories have been cloned, dependencies installed, the agent harness runtime initialized, and supporting services, including MCP servers, are already available. From the agent's perspective, execution begins almost immediately because the expensive initialization work has already been completed.
Maintaining that pool is fundamentally a scheduling problem rather than a provisioning problem. Holding too few warm sandboxes increases cold-start latency, while holding too many wastes compute on idle capacity. The scheduler continuously predicts demand, provisions new sandboxes ahead of time, and reclaims unused capacity through an LRU-style eviction policy.
WARM POOL SCHEDULER
Expand
A live model of a smaller scale warm pool. Requests arrive and attach to warm sandboxes instantly, the scheduler refills the pool in the background, and a cold boot happens only when the pool has no ready sandboxes.
The optimal pool size depends on workload patterns, repository characteristics, dependency graphs, user behavior, and resource requirements. The scheduler becomes a prediction system: anticipating future demand, preparing resources ahead of time, and continuously balancing responsiveness against cost. The biggest latency improvements do not come from making every provisioning step faster. They come from avoiding unnecessary provisioning work entirely.
One of the highest-leverage optimizations comes from intent prediction. Because user interaction begins before a request is submitted, the control plane can start preparing a sandbox while the user is still composing their prompt. By overlapping initialization with user think time, many potential cold starts become simple attachments, reducing perceived latency without changing the execution environment itself.
When a warm sandbox is unavailable, the fallback path remains deterministic. Base images are restored from versioned snapshots, provisioned with workload-specific CPU, memory, and storage allocations, initialized, health-checked, and then handed off to the agent. The fast path and the fallback path therefore produce equivalent execution environments, differing only in how much work has already been completed before the request arrives.
03
Execution plane: a real machine, not a shell
Low latency in sandboxes is only valuable if the environment behaves like the one the agent is ultimately targeting. An execution environment that omits services, simplifies the filesystem, or replaces production tooling with mocks may be faster to provision, but it fundamentally changes the agent's behavior which isn't useful. Successful trajectories in an artificial environment often fail when transferred to real infrastructure.
For that reason, our goal is fidelity rather than minimalism. Each sandbox is designed to resemble a developer workstation as closely as possible. Agents operate inside a complete environment with a writable filesystem, cloned repositories, project configuration, developer tooling, Docker, MCP servers, and the same supporting services they would encounter during production development. The objective is straightforward: if a task succeeds inside the sandbox, it should succeed when executed against the customer's actual environment.
One consequence of this philosophy is treating containerized workloads as first-class citizens. Modern software development rarely consists of a single process running on a host machine. Applications depend on databases, caches, message queues, background workers, and other services that are typically orchestrated through Docker Compose or similar tooling. Supporting these workflows requires more than the Docker CLI, it requires a functioning Docker daemon running inside the sandbox itself. Rather than reasoning about whether a change should work, the agent can directly verify its behavior by building and running the application it has modified.
Providing this level of fidelity inevitably expands the execution surface. Running nested containers, exposing a Docker daemon, and supporting arbitrary developer tooling all introduce additional security considerations. Rather than restricting these capabilities, we isolate them through the security architecture described later in this post. The goal is not to reduce the agent's capabilities, but to ensure those capabilities remain safely secured and isolated.
Ultimately, the execution plane exists to eliminate the gap between evaluation and deployment. Agents should develop, test, and debug software inside the same kind of environment where that software will eventually run. The closer the sandbox mirrors reality, the more reliable the agent becomes.
04
Security and Network plane: isolating capability without restricting it
The execution plane intentionally gives agents broad capabilities. They can execute arbitrary code, interact with Docker, modify repositories, access representative data, and communicate with external services. Those capabilities are what make agents useful, but they also make sandbox security fundamentally different from traditional application security. The goal is not to prevent execution. It is to ensure that execution remains fully isolated. Daytona helps us improve security between different sandboxes by supporting both kernel level isolation and hardware level isolation.
No single security boundary is sufficient. A sandbox simultaneously executes untrusted, model-generated code while interacting with customer infrastructure and credentials. Protecting against privilege escalation, secret exposure, lateral movement, and data exfiltration requires multiple independent layers of isolation rather than a single perimeter.
Secretless sandboxes
The safest secret is one the agent can never access.
This principle shapes the entire credential architecture. Any credential exposed to the execution environment, whether through environment variables, mounted files, or process memory, can ultimately be exfiltrated if an attacker gains control of the agent through prompt injection or model manipulation. Short-lived credentials reduce exposure but do not eliminate the underlying risk. If the agent can read a secret, it can leak it.
Instead, credentials must be outside the sandbox entirely. Requests requiring authentication are routed through a credential-injecting proxy that attaches the appropriate credentials immediately before forwarding the request. The agent issues an ordinary network request without ever observing the underlying secret, while the proxy becomes the only component responsible for credential management. Secrets never become part of the execution environment, eliminating an entire class of exfiltration attacks.
SECRETS NEVER ENTER THE SANDBOX
The agent never saw the secret.
Expand
Requests leave the sandbox with no credentials and pick them up at the proxy, outside the isolation boundary, so no secret ever exists inside. Additionally, prompt-injected request aimed at an unapproved host never gets past our strict egress allowlist.
Network Isolation
Protecting the sandbox requires controlling traffic in both directions.
Inbound traffic is
[truncated for AI cost control]