The Bounding Box Comes From Infrastructure, Not From a Prompt

An LLM deciding its own security boundaries is not a security model. The bounding box has to come from infrastructure, not from a system prompt.

That sentence is the whole argument. Docker’s April 2026 post on the microVM architecture behind Docker Sandboxes gives it a production shape. The post is worth reading on its own merits. What makes it interesting for anyone building agent infrastructure is how explicitly it moves the trust boundary down the stack, from the model to the hypervisor.

What Docker Actually Shipped

Docker Sandboxes now runs each agent inside a dedicated microVM. The microVM has its own kernel, its own memory, and a hardware-enforced boundary to the host. The same design works across operating systems: macOS Hypervisor.framework, Windows Hypervisor Platform, and Linux KVM. The cross-platform piece matters because most agent tooling to date has been Linux-first. Developers work on three operating systems. The containment layer has to reach all of them.

Docker also cited two internal data points worth repeating carefully. They report that more than 25% of Docker’s production code is now AI-authored, and that developers using agents merge roughly 60% more pull requests. These numbers are self-reported. They are not independently audited. Take them as directional, not definitive. The direction, though, is consistent with what every other vendor is saying: agents are doing a nontrivial share of the work, and the share is growing.

The productization detail is the interesting part. MicroVMs are not new. AWS Firecracker, Kata Containers, and Fly.io’s Firecracker-based runtimes have been around for years. What Docker did is take the isolation technology that was previously a cloud primitive and push it to the developer laptop, across operating systems, with near-instant cold starts and a dev-loop integration that does not require a separate cluster. That is a productization event, not a research event.

The Argument Against Prompt-Level Boundaries

Why does the microVM matter? Because the alternative is still the default in most agent stacks: trust the model to behave.

The pattern looks like this. A system prompt tells the agent what it can and cannot do. The agent has tools. The tools have permissions. The agent decides, turn by turn, which tool to call. When something goes wrong, the postmortem often reads: “the model was instructed not to do X, but it did X anyway.”

This is not a security model. It is a wish.

Models are probabilistic. Prompts are suggestions. A system prompt that says “do not read files outside the project directory” is exactly as strong as the model’s current inclination to obey it. The same prompt works on Tuesday and fails on Wednesday because a tool result included content that shifted the model’s decision. Prompt injection is not an edge case. It is the architectural consequence of asking a language model to be its own security boundary.

Infrastructure does not have this problem. A hypervisor does not negotiate. A network proxy does not get persuaded by a crafted URL. A filesystem mount that does not include ~/.ssh cannot leak ~/.ssh, regardless of what the agent was instructed to do.

Isolation Is Not Authorization

The honest caveat is that a microVM solves one problem and does not solve several others.

Isolation keeps the agent from reaching things outside the box. It does not decide what should be inside the box in the first place. If the agent needs credentials to do its work, and those credentials sit inside the sandbox, then a successful prompt injection can still exfiltrate them through an allowed egress path. Docker’s earlier architecture addressed this with a credential proxy that injects secrets at request time, so the agent never holds the raw key. That is the pattern that matters: isolation plus credential choreography, not isolation alone.

There are three failure modes that microVMs do not fix:

Authorization drift. An agent with legitimate write access to a repository can still commit bad code. The microVM contains the blast radius of a rogue process. It does not review the pull request.
Audit gaps. A microVM is ephemeral by design. If the reasoning behind an action is not captured before the sandbox disappears, you have lost the record. Entire’s Checkpoints exists precisely because isolation without an audit trail is governance theater.
Cross-agent trust. When multiple agents collaborate, the boundary between them matters as much as the boundary around each. Docker’s multi-agent architecture addresses this with per-agent microVMs and a coordination layer on top. Other stacks collapse it into a single sandbox, which is simpler and weaker.

The point is not that the microVM is the whole answer. The point is that the microVM is the layer where the boundary becomes real, rather than requested.

Where This Fits

We have covered the convergence before. In The Containment Pattern: Sandboxing we mapped four independent approaches that shipped in a single week of February. In The Containment Convergence we documented how NVIDIA, Docker, and OpenAI arrived at the same architecture: YAML policies, egress proxies, credential isolation.

Docker’s April post does not add a new layer. It hardens the one layer that used to be aspirational for local development. Linux-only microVMs were a cloud tool. Cross-platform microVMs are a developer tool. That shift moves the containment pattern from “something your platform team runs” to “something every agent can inherit by default.”

This is what productization looks like. A research primitive becomes a cloud primitive. A cloud primitive becomes a developer primitive. A developer primitive becomes invisible, and you notice it only when it is absent.

The Operational Question

If you are running agents in production, the Docker post reframes a question you have probably been postponing.

It is not: what should the agent be allowed to do?

It is: where does the decision live?

If the decision lives in a system prompt, a tool permission flag, or a model’s chain of thought, then the answer is “the agent decides, and we hope.” If the decision lives in a hypervisor boundary, a network policy, a filesystem mount, or a credential proxy, then the answer is “the environment decides, and the agent operates.” Only the second answer scales.

The bounding box comes from infrastructure. The sooner a team internalizes that, the sooner its agent deployments stop depending on the model’s goodwill.

That is the whole argument. Docker just made it harder to ignore.

This analysis synthesizes Docker’s Why MicroVMs: The Architecture Behind Docker Sandboxes (April 2026).

Victorino Group helps teams enforce agent boundaries at the infrastructure layer. Let’s talk.