I watched Mark Cavage’s WeAreDevelopers keynote, and something clicked. We’ve been thinking about container isolation all wrong when it comes to AI agents.
Containers were designed to isolate applications. They draw a line around your code and its dependencies. But agents do something different. They make decisions. They access networks, install packages, read files, and act on those decisions autonomously. A container boundary isn’t enough anymore.
The problem is immediate: give an agent enough access to be useful, and you’ve also given it enough access to be dangerous. Docker’s answer is elegant in its simplicity. You need isolation that extends beyond the application layer to the entire environment the agent touches.
Stronger Boundaries for Autonomous Work
In Cavage’s demo, he showed exactly what happens when an agent pushes beyond a container’s limits. The container itself worked as designed. But the agent needed containment around its full environment, including what it could reach on the network, what files it could access, and what credentials it could use.
Docker Sandboxes solve this by giving each agent its own isolated microVM with its own kernel, completely separate from your host environment. That’s a fundamentally different approach than traditional containerization. You’re not just isolating the application anymore. You’re isolating the entire execution context.
What matters here is that developers keep control over those boundaries. The policies that define what a sandbox can reach stay outside the agent’s control. An agent can’t escalate its own permissions or break out into the wider system. That’s the trust model we need for autonomous tools.
The fact that Docker Sandboxes are available today through a free CLI means developers can start bringing this isolation to their existing agent workflows right now, without waiting for platform-level support.
Making Authority Reproducible
But isolation alone isn’t enough. I need to know exactly what an agent can do, and I need that specification to be reproducible and reviewable.
That’s where Kits come in. They’re packaged as standard OCI images, which means they work with the same distribution and versioning mechanisms we already use for containers. Each Kit contains the agent, its tools, and the complete policy definition for what the sandbox can access. Everything is versioned and shareable.
This is genuinely important. Dockerfiles made software reproducible. Kits make authority reproducible. When I pull a Kit, I’m not just getting an agent and some tools. I’m getting a complete, auditable specification of what that agent is allowed to do. Changes to those permissions are visible and reviewable before they ship.
Docker is bringing the Kits specification to the Cloud Native Computing Foundation, which means this becomes a vendor-neutral standard built on OCI, not a Docker-specific feature. That matters for the entire ecosystem. If we’re going to have an open agent market, we need open, standard ways to define what agents can access. Read more about open standards in AI infrastructure.
Scaling Beyond the Laptop
Some agent work runs locally and completes quickly. Other work needs to stay running after you close your laptop or run in parallel with other tasks. That’s where cloud capacity becomes essential.
Cloud Sandboxes bring the same microVM-based isolation from your laptop to Docker-managed cloud infrastructure. You start locally with the same sbx workflow, then move to the cloud with one command when you need more capacity. No provisioning. No infrastructure management. Just the same sandbox model, scaled out.
Pay-as-you-go pricing means you’re not paying for idle infrastructure. And because the isolation model stays consistent whether you’re running locally or in the cloud, there’s no architectural shift. Your agent’s permissions and environment work the same way everywhere.
This matters more than it might seem. If agents are going to become part of our daily development workflows, the platform underneath them needs to be seamless. Moving from local to cloud shouldn’t require rebuilding your isolation layer or rethinking your security model.
An Open Ecosystem Built on Standards
Nous Research demonstrated this practically by showing Hermes running as a first-class Kit in Docker Sandboxes. That’s what choice looks like: a third-party agent packaged for a common environment, with Docker providing the isolation underneath.
Developers can choose the agent that fits their work best without rebuilding the trusted execution layer around it. The agent layer is competitive and open. The foundation is standard and neutral.
This is the pattern we need: specialized choice at the tool layer, shared standards at the infrastructure layer. Explore more about building developer tools.
The infrastructure around autonomous agents is becoming the competitive advantage, not the agents themselves. Docker is positioning itself as that trusted foundation, whether you’re running locally or scaling in the cloud. The question isn’t whether agents will become central to development workflows. The question is whether we build the infrastructure to trust them.