Docker launches sandboxes for AI agents. Isolated execution environments arrive.

Docker Sandboxes solve a real problem, and the fact that it took this long to get a clean solution says something about how the infrastructure layer has struggled to keep up with the agent layer.

AI agents that can write files, execute shell commands, install packages, and browse the web are now common. Devin, Claude Code, and a dozen other tools in this category ship with "autonomous execution" as a selling point. What they do not ship with is a clean answer to the question of where that execution actually happens. The gap between "the agent can run code" and "the agent can run code safely, repeatably, and without touching anything it should not touch" is where Docker Sandboxes sits.

Why container isolation already existed but teams kept skipping it

Container isolation is not new. Docker itself has been around since 2013. Any competent platform team can spin up a containerized environment for agent execution, configure resource limits, mount only the directories they intend to expose, and tear it down afterward. Kubernetes has namespace isolation. You can do this with a Dockerfile and a cron job to clean up stale containers. The primitives have existed for years.

The honest version of the skeptical argument is this: Docker Sandboxes is a packaged convenience product for teams that never got around to doing the isolation work themselves. If your team has a real infrastructure practice, you likely already have an answer to this problem. Paying for a managed abstraction on top of tooling you could configure in an afternoon is a tax on not prioritizing the work.

There is also a philosophical objection. Disposable sandboxes with no persistent state between sessions are not always the right model. Some agent workflows benefit from a consistent environment with installed dependencies cached, known configurations preserved, and tool versions pinned. A fresh sandbox per invocation trades safety for friction, and for certain long-running coding tasks, that friction is not trivial. The agent re-installs packages. It re-establishes context. It rediscovers the state of the codebase. That overhead compounds.

Why Docker built this now, and what the product design reveals about the real problem

The timing is not accidental. The agent category did not just grow in capability over the past two years, it grew in deployment surface. A year ago, teams using coding agents were running them interactively, with a human watching every tool call. The agent would suggest a file edit, the human would approve it. The feedback loop was tight enough that a misconfigured environment was annoying rather than dangerous.

That is not the model many teams are running today. Agents are being invoked programmatically, chained together, triggered by webhooks, and left to run for minutes or hours without direct supervision. The jump in autonomous task completion rates has come with a corresponding jump in the blast radius when something goes wrong. An agent that hallucinates a shell command and executes it in an environment with broad filesystem access and outbound network permissions is a different threat model than one that does the same thing inside a disposable, network-restricted container.

What Docker is betting on is that the infrastructure problem is not actually solved for the median engineering team. The teams with strong platform practices did figure this out. The much larger group of teams that adopted coding agents quickly, pointing them at development machines or loosely configured cloud environments, did not. Docker Sandboxes is aimed squarely at that second group.

The product design choice to make sandboxes disposable by default is also a deliberate stance on the agent persistence debate. Docker is not trying to compete with full development environment products like GitHub Codespaces or Replit. The bet is that isolation and disposability are the properties that matter most for agent safety, and that teams willing to pay for a managed product will accept the statefulness tradeoff. Whether that bet is correct depends entirely on the workflows teams are actually running.

Setting up a Docker Sandbox for an AI agent workflow

The following steps assume you are integrating Docker Sandboxes with an agent that executes arbitrary shell commands, such as a coding agent or an automated testing pipeline. The goal is a reproducible setup where every agent invocation starts from a clean state.

1. Visit the Docker Sandboxes product page and request access or sign up for the available tier for your organization.
2. Install or update the Docker Desktop client to a version that includes Sandboxes support. Confirm the feature is visible under the Docker Desktop settings panel before proceeding.
3. Define your base sandbox image. Start from a minimal official image and install only the dependencies your agent actually requires. Avoid using a development machine image directly - the point is a constrained, known environment. Tag this image explicitly: docker build -t my-agent-sandbox:v1 .
4. Configure network restrictions at the sandbox level. For most coding agent workflows, the sandbox needs outbound access to package registries but nothing else. Restrict ingress entirely unless your agent requires a callback endpoint.
5. Set explicit resource limits per sandbox invocation. CPU and memory caps prevent a runaway agent task from affecting neighboring workloads. A starting point for a mid-complexity coding task: --cpus="2" --memory="4g"
6. Mount only the directories the agent needs to read or write. Do not mount the host home directory, credentials directories, or anything containing cloud provider config files. Use named volumes or bind mounts scoped to the task directory: -v $(pwd)/workspace:/workspace
7. Set the sandbox to terminate automatically after a defined timeout. An agent that hangs should not hold a container open indefinitely. Use Docker's --stop-timeout flag and pair it with a cleanup policy in your orchestration layer.
8. Log all command execution from inside the sandbox to an external sink before the container terminates. Once a disposable sandbox is gone, so is its local log state. Pipe stdout and stderr to your logging infrastructure at invocation time.

Verification test: After setup, run your agent against a task that intentionally tries to write to a directory outside the mounted workspace - for example, a task that appends to /etc/hosts. The sandbox should block the write and the agent should return an error, not silently succeed. If the write goes through, your mount configuration is not correctly scoped.

Where statelessness and multi-agent pipelines cause real friction

The failure mode that will catch teams off guard is stateful tooling dependencies. If your agent relies on a language server, a locally installed database, or a compiled binary that takes two minutes to build, a fully disposable sandbox per invocation means you pay that setup cost every time. Teams running Cursor or GitHub Copilot-adjacent workflows where a developer interacts with the same agent across a long session will find the statelessness actively disruptive. The agent loses its understanding of the project structure, previously installed tools, and any cached intermediate results. This is not a bug in the sandbox design - it is the intended behavior - but it is a real cost for session-heavy workflows.

There is also a class of multi-agent pipelines where sandboxes introduce coordination overhead. If Agent A produces an artifact that Agent B needs to consume, and both run in separate disposable sandboxes, you need a storage layer between them. That is solvable with an external volume or object store, but it adds architectural complexity that teams with simple single-agent workflows do not anticipate when they first adopt the product. Frameworks like n8n that orchestrate multi-step agent workflows will need explicit handling for inter-sandbox artifact passing.

Security teams should also note what sandboxes do not protect against at the model layer. A sandboxed environment limits what a misbehaving agent can do to the host system. It does not prevent the agent from generating and exfiltrating sensitive data if it has been given access to that data inside the sandbox. The isolation boundary is the container wall, not the agent's decision-making. If you mount a directory containing API keys because the agent needs them to do its job, those keys are inside the blast radius.

The product is also unlikely to fit teams running on Apple Silicon development machines with tight memory constraints. Multiple concurrent sandbox instances on a 16GB MacBook Pro will compete for resources in ways that affect both the agent performance and the developer's own workload running alongside it. The disposable model scales cleanly in cloud infrastructure but less cleanly on a shared development machine.

By February 2026, either Docker Sandboxes will have added a persistent-state mode for session-based agent workflows, or a competitor will have captured that segment of the market. The statelessness tradeoff is the single sharpest edge of the current design, and it is too significant for the session-heavy majority of agent users to ignore for more than six months.