I’ve been watching the container ecosystem evolve for years, and I thought I understood the boundaries. A container isolates a process. It shares the host kernel with everything else on the machine. It’s lightweight, fast, and has a decade of tooling behind it. Then Docker Sandboxes arrived, and I realized we’ve been asking containers to do something they were never designed for.
The problem isn’t containers. It’s what we’re trying to contain. An autonomous coding agent isn’t a service waiting for requests or a batch job processing data. It’s an actor. It makes decisions, operates on systems the way a developer uses a laptop, and acts on instructions from files, web pages, and tool output that nobody reviewed. That’s a fundamentally different workload, and it needs a fundamentally different boundary.
The Container Limitation Nobody Talks About
Containers excel at one job: isolating an application that behaves as configured. Give a container a known set of dependencies, and it runs the same way every time. But a coding agent spends hours probing its environment, cloning repositories, installing packages, starting databases, and building images. Each step depends on what the previous one left behind. That state accumulation is exactly what containers are designed to reject.
More critically, an agent’s capabilities are the same ones that wear at the walls around it. When you run a coding agent in a container with Docker socket mounted (a common pattern), the agent doesn’t need an exploit to find the hole. It works out that it’s in a container, discovers the socket, and reaches the host Docker daemon. I watched the demo where an agent found a secrets file on the host this way, and there was no zero-day involved.
Containers share one kernel with everything else on the machine. Escape that kernel through an exploit or side-channel attack, and you’re past the entire host kernel, every other process, and any credentials mounted alongside them. For a service handling known requests, that’s acceptable risk. For an agent that spends hours probing its boundaries and acting on untrusted instructions, it’s not.
Why Microkernel, Not More Containers
The solution isn’t another container or a privileged container or better socket mounting. Docker Sandboxes use dedicated microVMs with their own Linux kernel, filesystem, network, and Docker Engine. The agent gets sudo inside the isolated environment but can’t reach the host. Each agent also gets its own microVM, so two agents running on the same machine can’t compromise each other.
That one architectural choice changes everything. If an agent escapes its container inside a sandbox, it lands in a disposable microVM, not on your host. You delete the sandbox and start another. The boundary is the hypervisor, not the kernel the agent shares with everything else.
The agent can still reach what you choose to share: the workspace, allowed network destinations, MCP servers, and skills. But those controls are enforced by the host, outside the agent’s reach. Outbound traffic goes through a host-side proxy with deny-by-default policy. Credentials are injected at request time, so the raw values never enter the VM. A rule the agent can reach is a rule it can work around, so the rules that matter live on the host.
What This Means for Your Team
I notice Docker Sandboxes ship with Kits and environment files that make setup repeatable. You package tools, files, commands, network rules, credentials, and agent instructions. When one developer’s setup needs to become a team standard, Docker AI Governance can move network, filesystem, and MCP policy into organization-wide controls. That’s the pattern we’ve been waiting for in CI/CD and observability, and now we’re getting it for agents.
The workspace is mounted read-write by default, so the agent can edit files in your project. Clone mode gives it a private in-VM clone to work in, protecting your host working tree. That distinction matters because it’s the difference between an agent that can break things and one that breaks them safely inside a boundary you control.
Setup does cost configuration and a supported hypervisor. But if you’re running autonomous coding agents at scale, that’s a cost you should pay. The alternative is hoping your container configuration has no holes, and we’ve already seen agents find them.
I think the deeper implication is that containers were always going to need a complement for workloads that act like users instead of services. Docker Sandboxes aren’t replacing containers. They’re answering a question containers can’t: how do you safely give an autonomous agent the authority of a whole machine?