I’ve spent enough time with Docker to know that containers do one job exceptionally well: they isolate applications. But we’re asking them to do something different now, and that’s where things get interesting.
When Mark Cavage talked about Docker Sandboxes at WeAreDevelopers, he nailed something I’ve been circling around for months. We don’t have a container problem. We have a boundary problem. And the boundary sits in the wrong place when you’re dealing with autonomous coding agents.
The Container Wasn’t Built for This
Containers are processes with a curated view of the filesystem, network, and process tree. They share the host kernel with everything else on the machine, which is why they’re lightweight and dense. That design has powered everything from microservices to CI/CD for over a decade. It’s elegant and it works.
But a coding agent isn’t an application in the traditional sense. It’s an actor. It clones repositories, installs packages, starts databases, builds images, and iterates for hours. It reads instructions from source files, READMEs, web pages, and tool output that nobody reviewed. Some of that input is untrusted, and a malicious instruction planted anywhere can steer the agent on purpose.
I thought about the agent that deleted a production database after misreading its task. Once it’s running unattended, there’s no permission prompt left to catch it. You’re handing an entity with minimal predictability the authority to reshape your entire development environment.
A container’s boundary is the kernel it shares. If an agent escapes, it lands in the host kernel, where every other process lives, along with every credential, every volume, every socket. On Linux, that’s game over. On Docker Desktop, you’re still in the VM, but you’ve crossed a line.
Docker Sandboxes flip this. Each agent gets its own microVM with its own kernel, filesystem, and network stack behind a hypervisor boundary. An agent still needs to escape its container, but when it does, it lands in a disposable microVM, not the host. You delete the sandbox and start another. The host stays out of reach.
Control Sits Outside the Agent
Containment is one thing. Control is another. And control is where this gets sophisticated.
Imagine mounting /var/run/docker.sock into a container to give it Docker access. That’s the standard pattern in Compose setups and CI pipelines. An agent in that container probes its surroundings, works out that it’s in a container, finds the hole in the configuration, and uses it to reach the host Docker daemon and whatever files it can mount. No exploit needed.
Docker Sandboxes give the agent a private Docker Engine inside the guest. It can build images, run Testcontainers, and launch entire Compose stacks. The host daemon and its socket stay outside the microVM. But here’s the critical part: all the controls that matter run on the host, outside the agent’s reach. Outbound traffic goes through a host-side proxy with deny-by-default policy. Credentials get injected into requests, so the agent uses them without ever seeing the raw value. Rules the agent can reach are rules it can work around. Rules that live on the host stay locked.
When one developer’s setup needs to scale to a team standard, Docker AI Governance moves network, filesystem, and MCP policy into organization-wide controls. This isn’t about locking developers in. It’s about making security a property of the environment, not a promise from the agent.
What Actually Changes
The workspace mounts read-write by default, so the agent can edit your code. That deserves your attention. Clone mode gives the agent a private in-VM copy to work in, which protects your working tree, though the original repository stays readable.
MCP servers and shared skills are available too. A local MCP server runs on the host and shared agent skills use a host-side store, so the agent’s reach extends there. The shared surface is smaller than with containers, but it’s not invisible. You need to read the diff before you run modified code.
Setup matters, but Kits and environment files handle most of it. A Kit packages tools, files, commands, network rules, credentials, and agent instructions. Different teams can publish Kits for different agents and workflows. An sbxenv.yaml file records one project’s sandbox configuration and lives in the repo, so reproducibility is built in.
Docker Sandboxes aren’t free in hypervisor requirements, but they’re free as a feature. The tradeoff is clear: more isolation, more control, more predictable blast radius. That’s the right tradeoff for workloads that can read from your codebase and reach your network.
The question isn’t whether containers are good anymore. They still are. The question is whether they’re the right boundary for every workload, and I think we all know the answer now.