Docker Sandbox vs Full Container Isolation Tradeoffs

Docker containers and full container isolation are not two names for the same thing. A shared-kernel architecture gives Docker its speed, but it also sets a hard ceiling on how much protection a container can ever provide, and crossing that ceiling requires a different kind of boundary entirely. This piece walks through what that boundary is, when it matters, and when it doesn't.

The Docker container model's hard security ceiling

Every Docker container on a host runs on top of the same kernel, with Linux namespaces and cgroups doing the work of keeping one process from seeing or touching another. That separation holds up well in ordinary use, but it is a software convention enforced by the kernel itself, not a wall built independently of it. If something gets past the kernel, there is no second layer behind it.

In a sandbox where an adversary can influence configuration, injecting a bind mount for /var/run/docker.sock hands the sandboxed process full access to the Docker API, which opens the door to launching privileged containers, mounting arbitrary parts of the host filesystem, and walking straight out of the sandbox. The boundary between "inside the container" and "the thing that controls all containers" turns out to be a single socket file away.

Hardening flags exist for exactly this reason, and they matter. Dropping capabilities with --cap-drop ALL, mounting the filesystem read-only, setting --security-opt no-new-privileges, applying seccomp profiles, cutting network access with --network none: each one closes off a path an attacker might use, and together they add up to real defense-in-depth. What none of them do is change the fact that every container on the host still shares one kernel. They shrink the syscall surface an attacker can reach, but they don't touch the underlying exposure.

None of this means Docker built something flawed. The shared kernel is the same design choice that makes containers fast to start, dense to pack onto a host, and simple to operate at scale, so the ceiling is the cost of the thing that makes containers worth using in the first place. It gets much harder to accept once the code is AI-generated, submitted by an outside user, or otherwise untrusted, because now the question isn't whether the shared kernel is a risk in theory but whether anyone can say with confidence what that code is going to try to do.

What "full isolation" means at the hardware level

Crossing the ceiling means giving each workload a kernel of its own, and that's what a microVM does. Backed by hardware virtualization (Intel VT-x or AMD-V), a microVM puts a guest kernel between the workload and the host, so an attacker who compromises the guest still has to escape the hypervisor before reaching anything else. That's two independent boundaries to get through instead of one shared kernel standing alone.

Firecracker is the clearest implementation of this idea at speed. It delivers hardware-level isolation with a boot time around 125 milliseconds and minimal overhead per VM, which makes it workable for multi-tenant AI agent execution and other untrusted-code scenarios where spinning up a full traditional VM would be too slow to use. Kata Containers reaches the same hardware-enforced isolation guarantee but takes a different operational shape: it orchestrates multiple VMMs, including Firecracker, Cloud Hypervisor, and QEMU, through standard container APIs, and boots in around 200 milliseconds. That combination (hardware-enforced isolation exposed through standard container APIs) makes Kata a natural fit for regulated industries and Kubernetes-native teams that want the isolation of a VM without giving up container tooling.

Between hardened containers and full microVMs sits gVisor, which takes a different approach to the same problem. The isolation gVisor provides sits above what containers alone offer and below what a microVM guarantees, with startup times measured in milliseconds and some cost in I/O-heavy workloads. It fits compute-heavy AI workloads and multi-tenant SaaS platforms where a full VM would be more isolation than the threat model actually calls for.

Trust level and isolation tier

The question to ask before choosing an isolation tier is how much trust the code deserves and what happens if that trust turns out to be misplaced, not which one is fastest or which one the team already knows how to run.

Code an engineer wrote and reviewed, running in a single-tenant environment, doesn't need a dedicated kernel. Shared-kernel containers stop being a defensible floor for compliance-sensitive multi-tenancy, and gVisor-level syscall interception becomes the minimum bar worth meeting.

AI-generated code, autonomous agents, and anything where a prompt injection could redirect what gets executed sit at the far end of that scale. This is where the threat model stops being hypothetical, because the code wasn't written by anyone on the team and its intent can't be verified in advance. Hardware isolation at the microVM tier is the tier this workload requires: the kernel needs to be dedicated to that workload, not shared with anything else on the host.

A useful way to pressure-test that tier choice is to run it against five concrete threats: filesystem reads or writes outside the intended scope, network egress to arbitrary domains, exposure of the kernel's syscall surface, cross-tenant data leakage, and secret exfiltration through environment variables or /proc. Sandboxing limits the damage an attacker can do once inside, but it doesn't stop a prompt injection from happening in the first place, and no sandbox tier handles a compromised system prompt on its own.

When the code being executed is AI-generated or otherwise untrusted, which is the defining case for autonomous agent systems, the shared-kernel exposure is no longer a theoretical cost but the central problem a platform has to solve. The broader point holds regardless of which platform a team picks: the tier should come from an honest look at what the code is and who wrote it.

The GPU exception: where the security ideal and operational reality diverge

GPU workloads are the place where that prescription runs into friction it cannot fully resolve. Passing a GPU through to a virtual machine carries enough operational overhead that teams running compute-intensive inference and model evaluation often keep using containers instead, even when the container runtime in question (rootless Podman, for instance) has known CVEs on record. Teams are weighing a known, documented weaker boundary against the cost of VM passthrough and deciding, consciously, that the container is the workable choice for now.

One published sandbox design makes that tradeoff explicit rather than hiding it: containers are used whenever both the user and the agent need GPU access, while VMs are reserved for cases requiring full isolation, with the container path treated openly as the weaker boundary rather than something papered over.

What follows from that, for anyone running GPU-intensive agent workloads, is a specific obligation rather than a free pass. Teams that make this tradeoff need to acknowledge the weaker boundary explicitly, layer in other controls such as network isolation, resource limits, and active monitoring, and treat the container as a tier whose risk has been accepted rather than one that secretly matches what a microVM provides. One might argue this undercuts the whole case for hardware isolation made in the prior section. It doesn't so much undercut it as mark its edge: the GPU case is the one spot in this spectrum where the operationally available option and the ideal security option genuinely diverge, and no amount of hardening flags closes that gap outright.

WebAssembly is emerging as a middle layer for CPU-bound workloads where full microVM overhead is not justified. A WASM isolate isn't a real operating system environment: agents running inside one can't install system packages or run arbitrary shell commands, which rules it out for any coding agent that needs a genuine development environment to do its job.

Docker's pivot to microVMs

The clearest evidence that this ceiling is real comes from Docker itself, the company that made the container the default unit of cloud deployment. Docker's president and COO, Mark Cavage, put it directly: "While the containers Docker is known for still have a critical role to play, they weren't designed for the level of isolation AI agents demand." That's a company that built its entire business on containers saying, in public, that containers alone are the wrong tool for a workload class it now sees as significant enough to build a new product around.

Docker Cloud Sandboxes addresses a problem specific to coding agents: they routinely need to build and run their own containers, and doing that from inside a standard container requires elevated privileges that undercut the isolation the container was supposed to provide in the first place. Docker has described cold-start times for these sandboxes as sub-second, though that figure has not been independently benchmarked as of this writing.

Beyond the isolation boundary itself, Docker layered in controls that work alongside it rather than depending on it alone: a network egress firewall that blocks all outbound traffic except the agent's own API endpoints and a set of explicitly allowed domains, and credentials delivered through a network proxy so the agent itself never sees raw host credentials. Docker's own architectural writeup walks through four alternatives, full VMs, containers, WASM and V8 isolates, and no sandboxing at all, and lays out the tradeoff each one carries, landing on the microVM approach as the way to get a real development environment and hardware isolation running at the same time.

None of this amounts to Docker walking away from containers. It's Docker adding a tier above the one it already offers, for a class of workload that the container was never built to handle. For teams still running AI agents on standard containers because that's the setup they already know how to operate, Docker's own framing is now a public reference point for when that setup stops being defensible on security grounds alone. It also raises a second question the isolation tier by itself can't answer: what happens to an agent's work between one action and the next.

Isolation tier alone does not address the statefulness problem in agent workflows

A coding agent's work builds on itself. An execution environment that forgets everything between actions forces the agent to start that whole sequence over each time, regardless of how well-isolated that environment happens to be.

Ephemeral containers solve the isolation half of that problem well enough, but they weren't built with continuity in mind. Full VM provisioning has its own version of the same gap. It offers strong security guarantees, but startup latencies often run into the tens of seconds, long enough to break the think-act-observe loop that an autonomous agent depends on to feel responsive.

Checkpoint-based durability has become a serious infrastructure concern for exactly this reason. Community projects built on top of Vercel Sandbox, including Sandcastle and the AI SDK Computer Use demo, point toward a related but distinct need: virtual Linux desktops with VNC screen streaming and mouse and keyboard control for computer-use agents, even though Vercel itself does not sell a separate "Desktop Sandbox" product. That's a different category from code-execution sandboxing, but it shares the same underlying requirement, state that survives across turns rather than resetting with every action.

What this adds up to is that isolation tier and statefulness are two separate problems, and solving one does not solve the other. A platform can sit at the top of the isolation spectrum and still leave an agent re-installing the same dependencies on every run. The platforms worth paying attention to are the ones built to hold both requirements at once.

How purpose-built runtimes address both isolation and statefulness together

Retrofitting a container platform to behave statefully, or bolting hardware isolation onto a tool built for something else, tends to produce a system that's good at one job and improvised at the other. The alternative is infrastructure designed from the start to carry both requirements together, and Daytona is a useful example of what that design looks like in practice.

Daytona was built specifically to run AI-generated and otherwise untrusted code at scale, rather than being a general-purpose developer sandbox adapted after the fact for agent workloads.

On the statefulness side, Daytona sandboxes can be created from snapshots that already contain an operating system, installed packages, dependencies, and configuration, so an agent starts from a prepared environment instead of reinstalling the same tooling on every run, and sandboxes can keep running indefinitely rather than being thrown away after a single task. The platform also includes virtual desktops for computer-use agents, alongside an orchestrator, API server, sandbox runtime, filesystem API, Git integration, language server protocol support, and process execution with streaming output.

Because Daytona is Docker-native compatible, teams bring existing Docker workloads onto the platform without rewriting what they've already built.

For AI-generated code and autonomous agents operating at real scale, the threat model doesn't soften with volume, it hardens, because untrusted execution is the starting assumption rather than an exception to plan around. Customers using Daytona include SambaNova, LangChain, Turing, Writer, and Clay, a mix of LLM providers, agent builders, and enterprises running code that nobody on their own team wrote by hand. That customer list is itself a kind of evidence for the argument this piece has made throughout: once the code running in production is no longer code your own engineers wrote, the isolation tier is a matter of what the workload actually requires, not of preference.