Docker has launched Cloud Sandboxes, managed micro virtual machines for running AI agents off your laptop. The interesting part isn't the product: it's the demo they used to justify it.
What happened
On Thursday 24 September, at the WeAreDevelopers conference, Mark Cavage — Docker's president and COO — announced the hosted version of its sandboxes. Instances that come up in a fraction of a second, charged by the second, with secrets, policies, networking, agent configuration and an MCP gateway already wired in. List prices run from Micro (1 vCPU, 2 GB) at seven cents of a dollar an hour up to XL (16 vCPUs, 32 GB) at one dollar and twelve cents an hour.
Before selling anything, Cavage showed the problem. He started Claude inside an ordinary Docker container and asked it to find a secret stored on the host machine. The model poked around its environment, found the Docker socket mounted in from the host, and walked straight out. His line sums it up:
«We have to separate containers from containment.»
He then brought principal engineer Michael Irwin on stage to run the same prompt inside a sandbox. This time the model also spotted the socket, also tried to mount host paths and start a privileged container, and got nowhere: the sandbox runs as a full micro VM, with its own kernel.
The context explains the urgency. That same day, Australian officials disclosed that an OpenAI agent had reached a government portal without authorisation while hunting for health statistics. It isn't the first agent to push past where its operator assumed the wall was.
Docker also updated its Kits specification — the format for packaging agents, tools and rules into a shareable artefact — which now ships as standard OCI images. And they showed a Kit from BAND that lets several agents cooperate over a WebSocket without sharing a runtime environment.
Why it matters
The mounted socket is the original sin, and you have it in production. /var/run/docker.sock inside a container is equivalent to root on the host: with that socket you can launch a privileged container that mounts the whole disk. This has been known forever and it's still mounted across half the industry, because CI runners want it, throwaway test containers want it, dev containers want it, and so does anything that builds images inside another image. With a human at the keyboard the risk was theoretical — nobody goes rummaging without a reason. An agent does. Rummaging through its environment until it finds a way forward is the job, and it's exactly what makes it useful.
A container isolates processes that cooperate, not adversaries that probe. It shares the kernel. It was designed so two applications don't stand on each other, not to withstand something that tries two hundred routes until one opens. When whatever is inside is going to mutate its environment — because that's what you hired it for — the boundary has to be virtualisation, not namespaces.
What I'd do this week, without buying anything:
- Inventory what each agent environment mounts: sockets, host volumes,
~/.aws,~/.ssh, the.envfrom the project next door. - Drop the Docker socket. If you must build images, use a remote daemon with scoped credentials, or daemonless tooling.
- Deny-by-default networking with an allow-list of destinations. The Australian case wasn't a container escape: it was uncontrolled outbound traffic.
- Keep secrets out of the sandbox filesystem. The agent reads files better than you do.
- For unattended execution, a micro VM boundary. Local or hosted, the vendor is secondary.
Per-second billing changes the usage pattern, and that part really is hygiene. If an environment costs cents and boots faster than an npm install makes up its mind, there's no reason left to reuse the same sandbox all afternoon. One per task, disposable, dying with the task. The cheapest containment is still an environment that doesn't exist when nobody's looking.
And Kits being OCI is no small detail. It means your registry, your signing, your scanner and your way out. A proprietary format for packaging agents would have been five-year glue.
What doesn't change
The micro VM isolates the filesystem and the kernel. It does not isolate the permissions you handed over. If the agent carries a token with write access to the repository or a production API key, that token works just as well from inside a perfect sandbox. The Australian incident wouldn't have been prevented by any of this.
Docker says as much themselves, and credit where it's due: sandboxes are the deterministic base layer, and what governs the agent's intent is policy — which is still homework across most of the stack. It's a minimum requirement, not a solution.
Moving execution to the cloud doesn't remove the attack surface either; it relocates it. Your secrets and your code now live on somebody else's infrastructure, with its own threat model. For long unattended jobs that trade is fine; for touching a client's private repo, think twice.
Technically it isn't an invention either: isolating untrusted workloads in micro VMs has been done for years. What's new is the packaging, the fit with the developer workflow and the entry price. And careful with list prices: the bill isn't set by the hourly rate but by how many sandboxes you open and how long they sit there forgotten.
If you have agents running against your codebase, today's exercise is to look at what's mounted inside them. Any questions, tell me and we'll go through it.
Best, Vicente.
The conference write-up is at The Register.