You think a hardware virtualization boundary is a security guarantee. It is not. It is a trust assumption with a hypervisor-shaped hole in the middle.
On September 24, 2026, Docker announced Cloud Sandboxes: a microVM-based runtime for isolating AI agents. The pitch is clean. Agents execute inside their own guest kernel, on their own virtual machine, behind a hardware virtualization boundary. Credentials are injected through a proxy, so the agent never touches the raw secret. Network egress, volume mounts, and port bindings are declared as rules that travel with the image.
The marketing language is disciplined. The technical language is not. "Sub-second cold start" ships without a benchmark number. "Self-built VMM" ships without a third-party audit. "Deny-by-default" ships without a governance story for the one thousand two hundred permissions a mid-sized engineering org will be asked to approve in its first year. And the announcement's headline โ that containers were never designed for AI agent isolation โ is a mild act of surgery on the Docker president's actual quote, which included the preamble that containers still matter.
I have spent twenty years reading pre-mainnet code and mapping the distance between what a system claims and what a system does. That distance is never in the feature list. It lives in the layer nobody funded the audit for. For Docker Cloud Sandboxes, that layer is the hypervisor Docker built itself. The exploit wasn't in the microVM. It was in the assumption that the microVM was the boundary.
Context: The Last Brick in a Wall Nobody Named
To understand why this release matters beyond Docker's product roadmap, you have to look at what happened across the AI infrastructure stack over the previous eighteen months. Different companies, different business interests, different go-to-market motions โ all landed on the same architecture. The pattern is called harness mode: a deterministic loop that feeds a model tools, executes those tools, observes the results, and iterates. The model is the brain. The harness is the body. Everything else is plumbing.
The plumbing converged in layers.
At the cloud provider layer, AWS shipped Strands agents, DigitalOcean and Aiven added managed agent runtimes. At the framework layer, LangChain formalized the graph-based execution model. At the edge layer, Cloudflare pushed V8 isolates as the sandbox of record. Each of these was a partial answer. None of them addressed the deepest layer: the container runtime itself, the thing that actually decides whether two workloads share a kernel.
That is where Docker lives. Docker did not invent the container. It defined the container as a product category and, more importantly, defined the mental model that millions of developers now hold in their heads when they say the word. When the company that named the paradigm says the paradigm has a boundary, people listen. That is the strategic weight of this release. It is not a technical breakthrough. It is a confession, delivered by the only company with the standing to make it.
The specific technical claim is narrower than the confession. Docker Cloud Sandboxes replaces the shared kernel of container isolation with a microVM boundary. Each agent gets its own guest kernel. The isolation is enforced by Intel VT-x or AMD-V โ commodity hardware virtualization that has existed since 2005. The microVM concept was industrialized by AWS Firecracker in 2018 and has since been validated at scale across serverless platforms. None of this is new. The novelty is in two places: Docker built its own cross-platform virtual machine monitor instead of licensing Firecracker, and it wrapped the runtime access policy โ network, credentials, volumes, ports โ into the OCI image itself, under a specification it calls Kits v3.
That is the whole pitch. The rest is packaging.
Core: A Systematic Teardown of Seven Claims
The Innovation Is Integration, Not Architecture
Let me be precise about the innovation level, because the vocabulary matters. There are three tiers of technical change: architectural, combinatorial, and engineering. Architectural change rewrites the fundamental assumptions of a system. Combinatorial change puts existing primitives together in a way nobody assembled before. Engineering change makes an existing design work reliably at scale.
Docker Cloud Sandboxes is combinatorial and engineering. The microVM is mature. The hardware virtualization is commodity. What Docker contributes is (i) a self-built VMM that unifies macOS, Windows, and Linux behavior โ Firecracker only supports Linux over KVM, and that constraint is the specific gap Docker is filling โ and (ii) an OCI-based carrier for runtime policy. Both are real. Neither is a moat by itself.
I don't grade infrastructure on elegance. I grade it on the cost of being wrong about it. And the cost of being wrong about a self-built VMM is higher than the cost of being wrong about almost anything else in this stack, because the VMM is the security boundary. It is the code that decides whether the sandbox stays a sandbox.
The Sub-Second Claim Is Doing a Lot of Work
The announcement says "sub-second cold start." No number. No P50, no P99, no conditions. In engineering terms, sub-second spans one hundred milliseconds to nine hundred ninety-nine milliseconds โ a tenfold range. Firecracker's published figure is roughly one hundred twenty-five milliseconds. Commercial sandboxes built on Firecracker publicly claim around one hundred fifty milliseconds. If Docker's actual number sits at four hundred milliseconds under load, it is not a leader. It is a laggard with better vocabulary.
The absence of a benchmark is not a documentation oversight. It is a narrative softening. When a company is proud of a number, it publishes the number. When it is uncertain, it publishes the adjective. Sub-second is an adjective.
There is a second-order problem here, and it is the one that actually matters for unit economics. To deliver consistent sub-second performance, you generally maintain a pre-warmed pool of microVMs. A pre-warmed pool is paid-for capacity that is running idle. The idle capacity does not show up in your latency chart. It shows up in your margin. Docker has not described a pre-warmed pool, which means either the cold path is genuinely fast, or the idle cost is being absorbed somewhere the announcement does not disclose.
Kits v3 Is the Genuine Technical Contribution
Here is where Docker earns credit. The Kits v3 design does three things that most runtime security models get wrong.
First, rules travel with the image. Network egress policy, credential access, volume requirements, and port exposure are declared inside the OCI artifact rather than configured at the runtime host. This is a semantic migration: the image stops being a passive data artifact and becomes an object that carries behavioral intent. That migration has supply chain implications the announcement never discusses, but the design instinct is correct.
Second, rules are requests, not grants. The image requests access. The host decides whether to grant it. This inverts the usual failure mode where a workload silently gets more than it needs because the default is permissive.
Third, and most importantly, when the host cannot satisfy a required request, it refuses to start the workload rather than starting it with reduced permissions. This is the mature engineering judgment. Silent privilege degradation is one of the most dangerous security anti-patterns in existence, because it produces a running system that looks healthy and is quietly less safe than the operator believes. The Android permission model learned this lesson the hard way. Docker appears to have internalized it before shipping. Deny-by-default, refuse-on-unsatisfiable โ that is the correct semantic.
The Credential Proxy Is the Real Differentiator
The single most valuable design decision in this release is the credential proxy. When an agent needs to call an authenticated endpoint, the proxy injects the authentication header only when the destination hostname matches a policy whitelist. The agent never receives the raw secret. There is no key material inside the sandbox to steal.
This cuts one specific and famous attack chain. There is a security framing โ popularized in agent security work โ describing the "lethal trifecta": private data, untrusted content, and external communication, all reachable from the same execution context. Any two are tolerable. All three is a breach waiting for a trigger. The credential proxy removes the raw-secret leg of that trifecta. It does not remove the other two, and that distinction is where the announcement overreaches.
Because here is the thing the press release wants you to skip. The claim "even if the agent is compromised, it cannot steal credentials or reach unauthorized endpoints" is true only if the authorized scope itself is safe. If you grant a coding agent legitimate write access to your GitHub repository, an agent hijacked through prompt injection can open a pull request that exfiltrates private source code. That is not a credential theft. That is a fully authorized action. The proxy cannot stop it, because the proxy's job is enforcement of policy, and the policy said yes.
Greed is the feature; the bug is just the trigger. I have watched the same pattern in bridge contracts: the guardrail is real, the guardrail is correctly implemented, and the exploit routes around it because the guardrail was never the attack surface. The attack surface was the authorization the guardrail granted.
Stateless by Design โ and the Cost Nobody Counted
The announcement states that microVMs do not retain persistent state and can be killed and restarted on demand. It lists persistent state as a requirement of agentic systems in the same breath. Those two statements are in direct tension, and the tension is unresolved.
If the microVM holds no state, then state lives elsewhere: object storage, an external database, a mounted Kits volume. Every restart rebuilds the environment โ pull the image, initialize the kernel, restore context. For a short task, that is fine. For a multi-hour coding agent that has built up a working tree, a conversation history, and a set of intermediate artifacts, the checkpoint-and-restore cost is not free, and it is not evaluated anywhere in the announcement.
The design is resource-optimal from a scheduler's perspective. It unloads state management onto the customer and off the platform. That is good for Docker's infrastructure and potentially bad for the customer's latency budget. Whether the trade is worth it depends entirely on task duration distribution, which is exactly the data Docker did not provide.
The Business Model Quietly Changed Type
Here is the commercial event hiding inside a technical release. Docker's existing revenue is seat-based subscription: Docker Desktop, Docker Business. High margin, predictable, near-zero marginal cost per additional user. Cloud Sandboxes is usage-based infrastructure: low margin, high capital expenditure, high marginal cost per additional running sandbox.
That is not an extension of the business. It is a change in the business's type.
For an analyst, the important question is not whether Docker can build the runtime. It clearly can. The question is whether a private, private-equity-controlled company can absorb the capital intensity of an IaaS business long enough to reach scale. MicroVM clusters require real CPU, real memory, real NVMe, and real pre-warmed capacity. AWS can run agent sandboxes as a loss-leading funnel into Bedrock consumption, recovering the loss through model spend. Cloudflare can amortize sandbox cost across an edge network that was already paid for. Docker cannot do either. It is a small capital player entering a capital war.
And the pricing is undisclosed. In infrastructure, undisclosed pricing usually means one of two things: the pricing has not stabilized, or the pricing is high enough that publishing it would chill adoption. Given Docker's history โ the Docker Desktop pricing adjustment that triggered community backlash โ publishing a number is itself a reputational event the company is presumably sequencing carefully.
The PLG funnel itself is sound. Docker owns the largest developer desktop footprint in the industry, plus Docker Hub for distribution, plus the new MCP catalog and gateway. The "try locally, pay when the team scales to the cloud" path is real and is something pure-cloud competitors like E2B and Modal cannot replicate. But the buyer is not the developer. The developer likes it; the CTO and the security lead sign the contract. The announcement addresses the developer experience in depth and the enterprise procurement path not at all.
The Security Matrix the Article Skipped
I built a risk matrix from the announcement's own claims. It is more revealing than the feature list.
Sandbox escape at the hypervisor layer: medium. The hardware virtualization boundary is genuinely stronger than a shared kernel. But the VMM is self-built and unaudited, which means its own CVE surface is unknown. The architectural mitigation is solid; the implementation is unverified. Those are different things, and conflating them is how organizations end up surprised.
Credential theft: low. The proxy design is a real improvement. This is the strongest line in the whole announcement.
Prompt injection leading to over-privileged action: high. Isolation and credential proxying cannot prevent an injected agent from abusing permissions it legitimately holds. This is unmitigated, and the announcement does not name it.
Whitelist social engineering or compromised allowlisted domains: medium-high. Every allowlisted destination is a potential exfiltration channel if the attacker controls it or can abuse it. Deny-by-default does not help when the default list includes the attacker.
Kits image supply chain poisoning: medium-high. Because permission requests travel inside the image, a poisoned image plus a habitual approval click is a new attack path. Deny-by-default is correct, but it depends on the human reading the request.
Permission fatigue: medium-high. This is the quiet killer of every well-designed consent model. If the sandbox asks for approval often enough, users approve reflexively, and deny-by-default becomes a ritual rather than a control. The announcement offers no UX evidence to the contrary.
MCP server attacks: high. This is the most conspicuous omission. The MCP ecosystem has a documented attack surface โ tool poisoning, rug pulls, malicious tool descriptions, cross-server shadowing. The announcement lists MCP integration as a positive feature and devotes zero words to the risk.
The Infrastructure Reality Nobody Modeled
One correction is worth making loudly, because the market will get it wrong. This is a CPU, memory, and storage business. It is not a GPU business. Agent execution โ tool calls, code runs, file operations, network requests โ is CPU-intensive. Unless the agent is calling a model endpoint, the GPU sits somewhere else. This release does not pull the GPU supply chain forward by a single wafer. Anyone pitching agent infrastructure as a GPU story is selling you the wrong category.
The real structural constraint is density. Each microVM carries a guest kernel with fixed memory overhead, plus the VMM's own footprint. Firecracker-class designs can compress per-VM overhead to single-digit megabytes, but any VMM's floor is orders of magnitude above the process-level floor of a shared-kernel container. If every agent gets its own microVM, the number of concurrent agents per physical host drops, and unit cost rises. Docker published no density number. Without density, the unit economics are not estimable. Without unit economics, the pricing cannot be evaluated. This is the single largest unknown in the entire release.
A second hidden cost: running microVMs in the cloud requires nested virtualization. Nested virtualization usually means bare metal or specific large instance classes, which carry a per-unit premium and coarser elasticity. If Docker is reselling cloud capacity with a VMM layered on top โ cloud-on-cloud โ it absorbs that premium, competes with its own supplier, and inherits a platform risk that has killed smaller infrastructure companies before.
A third, and least discussed: the egress proxy and credential proxy sit on the critical path of every sandbox's outbound traffic. That is the architectural price of the security win. It is a new single point of failure, and the announcement describes no high-availability design, no latency penalty, and no horizontal scaling story for that layer.
The Competitive Position Is Unique and Fragile
Docker's differentiation is real but narrow. It holds the only "local-to-cloud consistent" story, backed by a cross-platform VMM that competitors do not have because Firecracker does not run on developer laptops. It holds an open standard path โ OCI plus Kits plus an Apache 2.0 specification donation to CNCF. It holds the largest developer distribution. And it is structurally behind on capital, behind on published performance, and behind on enterprise certifications.
The competitor matrix makes the squeeze visible. E2B has Firecracker isolation and a published cold-start figure near one hundred fifty milliseconds. Cloudflare has edge distribution and millisecond-class isolate startup for a subset of workloads. AWS Bedrock AgentCore has the enterprise procurement entry point and Firecracker isolation, and can subsidize. Modal has gVisor and a mature developer motion. Docker's edge is portability and standards. Its constraint is that standards only matter if someone else implements them.
Logic doesn't bend because the standard-maker is well-intentioned. Kubernetes was donated to a neutral foundation and ended up governed by the cloud vendors who had the most capacity to implement it. If Kits follows that path and AWS or Cloudflare implement it, Docker becomes a contributor to its own commodity. If nobody implements it, the standard degrades into a private extension of Docker's product, and the word "standard" becomes marketing again.
The honest read of the competitive position is this: Docker's real rivals are not E2B. They are AWS and Cloudflare. And the niche Docker occupies โ the cross-cloud, locally consistent AI agent runtime โ is real, valuable, and structurally medium-sized. That is a survivable position, not a dominant one.
Contrarian: What the Bulls Got Right, and a Missed Positive
The skeptical case is easy to make, so let me make the opposing one, because the announcement did things that deserve credit and one thing the announcement itself failed to claim.
First, the credential proxy and the refuse-to-start semantics are genuine advances over the industry baseline. Most agent runtimes today execute with ambient credentials and permissive defaults, and pay for the convenience with an unbounded blast radius. Docker inverted the default. That inversion is not cosmetic. It changes what an attacker can do after the first failure.
Second โ and this is the point the announcement left on the table โ the stateless design is an underrated security feature. Because microVMs are killed and rebuilt rather than persisted, an attacker who lands inside a sandbox cannot establish residency. There is no long-lived foothold, no place to hide a backdoor, no accumulated state to exfiltrate later. The horizontal movement window collapses to the lifetime of a single task. Docker sold statelessness as a scheduling property. It is also a containment property, and it was framed as neither.
There is one more contrarian note that the bulls should read carefully. The most valuable thing here is not the isolation, because isolation is already commodity. The most valuable thing is the position: the deepest layer of the agent stack, occupied by the company with the strongest standards credibility and the largest developer entry point. Standards positions outlive product features. If Kits gets a second implementer within a year, the skeptical case weakens considerably, because the standard, not the VMM, is the durable asset.
Takeaway: Track the Second Implementer
The interesting question was never whether a microVM is stronger than a shared kernel. It is. The interesting question is whether the standard Docker wrote becomes infrastructure or becomes marketing. Watch three signals: an independent benchmark that translates "sub-second" into a P99, a CNCF decision on the Kits specification, and a second organization announcing an implementation. If all three land, Docker bought itself a position. If only the VMM ships and the standard stalls, Docker built a very good sandbox inside a market it cannot afford to fight for. The verifier is the story. The sandbox is just the bait.