What Docker Sandboxes Get Wrong for AI Agent Workloads

Docker sandboxes expose a mismatch between application infrastructure and autonomous AI workloads. Shared kernels, disposable environments, and application-centric controls do not by themselves provide the security, speed, or continuity agents need. The right infrastructure choice depends on identifying which of those assumptions fails for a particular workload, rather than treating containers as either universally sufficient or inherently broken.

Why Docker's container model was never designed for AI agent workloads

Agents are moving out of feedback loops where people watch them closely. They are invoked programmatically, chained together, triggered by webhooks, and left to run for minutes or hours. That changes the blast radius of their actions, even without a change in model capability. An agent can execute code, call APIs, read files, manipulate databases, and coordinate work across production infrastructure without anyone reviewing each step.

Containers addressed a different problem on shared infrastructure. They separated applications whose code was written by humans, reviewed, and trusted. Their shared kernel and application-centric boundaries fit that operating assumption. By contrast, an autonomous agent can generate the code it will execute and choose its next action from material it encounters while running. Container isolation therefore needs to match the authority and uncertainty of the workload inside it.

The shared-kernel problem: why container isolation is the wrong boundary for untrusted AI-generated code

A container shares the host kernel with other processes. A kernel-level exploit can therefore escape the container rather than remain confined to its application boundary. Installing packages gives hostile code another way in. Models recommend nonexistent packages, and the consistent recurrence of some hallucinated names across queries creates an opening for package-squatting attacks against the agent’s execution environment.

Yet escape is not the only security failure. An LLM acting through a trusted process can inherit database credentials, network access, and filesystem permissions as ambient authority. A prompt injection need not bypass role-based access control if it can persuade this “confused deputy” to exercise permissions already available to it. Resource limits do not solve that problem, because a cap on what the agent consumes does not control which authorized action it chooses. Kernel containment and control over agent authority are separate requirements, and neither substitutes for the other.

Four isolation approaches and where each one sits on the spectrum from application to agent workload

Standard containers isolate processes while sharing the host kernel. They work for trusted application workloads, but that boundary is too weak for arbitrary, untrusted AI-generated code. Hardened containers using gVisor sit in the middle, with container-speed startup and VM-like isolation. That description should not be mistaken for a separate kernel per sandbox. Their appeal is a stronger boundary without the full orchestration burden of microVM infrastructure.

Firecracker and Kata microVMs provide a different security boundary. Each sandbox has a separate kernel behind hardware-enforced isolation, so a kernel-level exploit inside the sandbox does not by itself cross into the host. The trade-offs include cold-start latency and orchestration complexity. To run untrusted agent code in production, the stronger architecture uses hardware isolation along with default-deny filesystem and network policies and layers of escape prevention. Hardware isolation alone does not control what actions are allowed.

Programmatic virtual desktops are the fourth approach, but they sit outside the code-execution spectrum. They supply the environment needed by agents that operate graphical applications. That is a different workload, considered later in the piece. The distinction prevents “sandbox” from concealing two separate questions about infrastructure, namely how untrusted code is contained and what kind of environment an agent needs to do its job.

Cold start latency: how container startup times break real-time agent tool execution

A stronger boundary introduces a second constraint, startup time. Second-scale container cold starts are poorly matched to an agent that invokes tools dozens of times during a task. MicroVMs start faster than full virtual machines, but cold starts still fall in the hundreds-of-milliseconds range. Those delays add up when code has to wait for a new environment over and over.

In conversational and interactive systems, a person or an orchestrating system waits for tool calls to complete before work can advance. Startup overhead therefore competes with the time available for useful execution. Batch and background tasks can tolerate a different balance, so cold-start speed is not an equally strong selection criterion everywhere. However, allowing more time does not answer what happens to the environment between invocations, which brings state management into the decision.

Ephemeral state: why disposable sandboxes break multi-step and long-running agent workflows

A fresh environment is not always a useful reset. Without persistent state, agents reinstall packages, re-establish context, and rediscover codebase state across runs. Some workflows instead benefit from cached dependencies, preserved configurations, and pinned tool versions. Multi-agent pipelines add a coordination requirement when an artifact produced by Agent A must reach Agent B in a separate disposable sandbox. An intervening storage layer supplies that continuity, but adds latency, complexity, and another failure surface.

Persistence also changes what isolation can promise. A microVM contains arbitrary code execution behind a hardware boundary, but it cannot make the contents of a writable workspace safe. The workspace is where the agent performs its work. A malicious post-commit hook, poisoned file, or prompt-injected payload can propagate outward through a shared workspace layer even when execution remains contained. Statefulness and policy controls consequently need to be designed together, because the channel that preserves useful work can also preserve hostile material.

Long-running agents need more than durable files. They need session logs, a harness, checkpoints, traces, policy checks, secret brokering, and cost limits outside the model. Sandbox isolation remains part of that system. The container’s ephemeral model does not supply these controls by default.

What high-frequency checkpoint and rollback demands reveal about the statefulness gap

Tree search and reinforcement learning make this gap measurable. Agents exploring candidate paths need frequent checkpoints and rollback of complete sandbox state, including files and running processes. DeltaBox, developed by Shanghai Jiao Tong University and Huawei in 2026, identifies full-state duplication as a bottleneck in existing mechanisms. Each operation can take hundreds of milliseconds to seconds, which limits deep search and large fan-outs. Under a fixed time budget, time spent preserving state displaces time available to explore another path.

DeltaBox instead duplicates changes between consecutive states, which often differ only slightly. Its DeltaFS mechanism preserves file state through copy-on-write layer switching, while DeltaCR preserves process state through forked frozen templates. Instead of rebuilding a complete copy for every checkpoint, the system preserves a starting state and accounts for what changed.

The same study reports approximately 10.83 ms of checkpoint work hidden under inference and approximately 1.86 ms for fast-path rollback on software-engineering benchmarks and RL micro-benchmarks. It reports overall rollback in 5 ms. Faster state transitions let agents explore more nodes in the same amount of time and finish a larger share of tasks. Reinforcement learning compounds the pressure because each training step starts many independent rollouts from a warm state and then tears them down. With tens to low hundreds of parallel rollouts, fork latency bounds training throughput, making OS support for change-based checkpoint and restore an agent-capability constraint.

Computer-use agents and why GUI-driving workloads need a different sandbox model entirely

Computer-use agents need more than a place to execute code. They inspect screenshots or video, interpret a desktop, and act on graphical applications. The required sandbox is therefore a full virtual environment. This reaches software that API-only agents cannot, including legacy ERP systems, thick-client applications, and proprietary tools without API access. Process isolation does not supply that desktop.

AWS integrated generally available computer-use support with WorkSpaces. Agents get an identity through IAM and use a unique pre-signed URL to access a WorkSpace, where they run applications in a full virtual machine. Microsoft created a version of Windows 365 for agents using managed Azure Cloud PCs with VM-level isolation.

For container-based stacks supporting this workload, the recommended approach is Kata Containers. Its microVM-per-pod model provides VM-grade isolation and near-full syscall compatibility. Standard containers alone do not provide the virtual desktop environment this category requires. A team whose hardened containers are enough to run code can still need a different architecture when its agents start using graphical applications.

Enterprise compliance frameworks and why container-based deployments create structural audit gaps

GDPR, HIPAA, SOC 2, and the EU AI Act must be applied to agents that access data and create side effects without a human present. Container-based deployments lack per-agent identity, audit trails, and credential scoping by default. That leaves essential controls outside the container abstraction.

GDPR’s right to deletion requires traceable, purgeable personal data across agent memory, logs, and derived embeddings. A generic container without a persistent identity layer cannot supply that traceability on its own. HIPAA’s minimum-necessary-access principle raises a related scoping problem. Per-session credentials can narrowly constrain access, whereas inheriting ambient credentials does not establish that the agent receives only what its task requires.

HIPAA’s Security Rule calls for unique user identification, authentication, and audit controls in systems that handle electronic protected health information, though it does not name AI agents as a separate category. Applying those requirements to agent-level identity and logging is an architectural interpretation. Systems that work with protected health information must also be covered by a Business Associate Agreement. Transmitting that information to a consumer-tier model endpoint violates the stated requirement, while tasks using fully de-identified data do not trigger the agreement requirement solely because of the endpoint tier.

What the industry has converged on: the harness pattern and purpose-built agent runtimes

The response is a layer above the model and below the application. A harness observes execution, applies controls, and intervenes in agent behavior, supplementing retrospective logs. The model cannot be its own deterministic authorization boundary, and a sandbox cannot judge whether every action inside it serves the task it was given.

Amazon Bedrock AgentCore Runtime illustrates how that layer combines previously separate concerns. It gives each agent session an isolated microVM, secure tool access, observability, and support for a persistent workspace. Parallel runs of Claude Code, Codex, Kiro, and Cursor can proceed without sharing secrets, ports, or filesystems. Persistence has a configuration condition, however. Filesystem state survives stop/resume cycles only when managed session storage is configured.

The runtime supports extended workflows on microVMs and much longer periods on Instances. That combination ties how long code runs to state and session controls, so each launch is part of a continuing workflow. It provides a place for isolation, continuity, tool access, and observation to operate as parts of the same system, with policy still needing to be defined.

The strongest objection to purpose-built runtimes and what it gets right

The strongest objection is that hardened containers are sufficient for many agent workloads today. Containers with gVisor offer a strong middle ground, and microVM orchestration imposes real operational costs. A small team with a few hundred agent invocations per day may gain little by taking on that burden. When agents run less often and the risk is low, a simpler architecture can be enough.

That objection is persuasive on cost and complexity. It is less complete when workload frequency stands in for workload requirements. An infrequent agent handling sensitive data still needs appropriate identity, access controls, and audit logging. An agent that explores candidate paths or runs for hours still needs checkpointing or persistent state.

gVisor fits lower-frequency, lower-stakes workloads, while microVM-based purpose-built runtimes fit production agents handling sensitive data, acting autonomously, or requiring stateful continuity. Sandboxes make damage containable, so infrastructure decisions must account for policy and state as deliberately as they account for isolation.