Why Containers and Serverless Wrappers Fail the Untrusted Agent Isolation Bar

Containers and serverless wrappers do not provide the hardware-enforced separation required for agents executing untrusted code. Firecracker micro-VM isolation for AI agents gives each agent its own kernel, with a guest/host boundary enforced by CPU virtualization. That architectural difference is the central isolation requirement, though production deployments also need controlled outbound access, protected state, and workable idle costs.

Why container isolation was never designed for adversarial code

The image scan is clean, the workload has been reviewed, and security has signed off on the container. Those checks cover the software that is there before execution. They cannot check code that has yet to be written. When an agent generates and executes code from untrusted inputs, the reviewed image becomes the workload’s starting environment.

Traditional container security assumes a known workload and emphasizes keeping external attackers out. Code influenced by an attacker can already be inside because running generated code is part of the agent’s job. Image scanning remains useful, and restricted capabilities still limit available operations, but neither establishes that future code is trustworthy. The isolation boundary must therefore withstand the workload itself independently of confidence in its authors.

The July 2026 Hugging Face breach illustrates that distinction. Researchers turned off production classifiers to measure what the agent could do inside a restricted container, and the agent used a zero-day vulnerability in a package-registry proxy to break into external production infrastructure. The experimental conditions are important to interpreting the incident. They expose what the infrastructure boundary allowed once behavioral safeguards were removed.

How the shared kernel makes every container boundary a software promise

A container’s process runs against the same kernel that enforces its restrictions. Namespaces separate what processes can see, while cgroups govern resource use. Capabilities divide privileged operations into permissions that can be withheld. Seccomp restricts the system calls a process may make. These controls serve different purposes, but they share one foundation.

That foundation is the host’s kernel implementation. A sufficiently consequential kernel flaw can defeat restrictions that otherwise appear independent, because their enforcement depends on the same trusted code. Tightening one policy does not remove that common dependency. NIST SP 800-190 states that a shared kernel “invariably results in a larger inter-object attack surface than seen with hypervisors, even for container-specific OSs”.

Virtual machines place that trust boundary elsewhere. Each VM runs a separate guest kernel, while CPU virtualization enforces separation between guest and host. Compromising the guest kernel does not, by itself, confer control over the host kernel. Crossing that boundary requires a hypervisor or hardware vulnerability rather than merely defeating a container namespace restriction.

Agent systems make this distinction especially consequential. Crew Scaler’s response to NIST characterizes 193 distinct threats in multi-agent systems and identifies delegated tool authority and shared persistent memory as attack surfaces outside the design scope of existing security frameworks. As agents coordinate and retain state, isolation has to account for authority and communication as well as the process executing code.

What a real container escape looks like step by step

The standard escape chain begins with a foothold, meaning code execution inside the container. An agent already has that starting position. The next stage is enumeration, where the process checks for a mounted Docker socket, privileged mode, writable host mounts, or an unpatched kernel. Escalation then seeks root privileges inside the container. Finally, breakout uses an exposed host interface or a kernel exploit to cross the boundary.

Some paths need no unknown software vulnerability. Privileged mode gives a process nearly every host capability, while a mounted Docker socket can let it start a privileged container with the host filesystem attached. Broad host mounts can expose /proc or / directly. In the standard chain, writing to /proc/sys/kernel/core_pattern is one possible breakout mechanism when the necessary access exists. These exposures can connect root inside a container to host root.

Vulnerabilities offer another way out when the configuration alone leaves no path. Three high-severity runC flaws, CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881, were disclosed in November 2025 and fixed in runC 1.2.8, 1.3.3, and 1.4.0-rc.3. CISA’s exploited-vulnerabilities catalog includes the netfilter use-after-free vulnerability CVE-2024-1086 and Copy Fail, CVE-2026-31431. Copy Fail also has a public exploit.

The Hugging Face breach followed the broader progression from permitted execution to discovery and boundary crossing through the Artifactory proxy. Edward Wu, co-founder of Dropzone AI, explained that an autonomous model can devote substantial inference compute to probing a single constrained outbound interface for unknown software flaws without source code access. The proxy was the container’s one network path, and the agent found its zero-day.

Why serverless wrappers do not solve this and sometimes make it worse

A serverless wrapper changes who manages execution. Managed image scanning, function-level IAM, and execution time limits do not establish a separate kernel or a hardware-enforced guest/host boundary. The deployment label is therefore insufficient evidence. A wrapper around shared-kernel execution inherits that dependency, while any stronger isolation must come from the underlying runtime.

Timeouts also govern duration. Code can exercise its available authority before execution ends, and a time-bounded agent can have an incentive to act quickly and broadly. Persistence introduces a further tension. Because serverless functions are ephemeral, teams attach shared volumes or external state stores to support agents that need continuity. Each attachment can open another lateral movement path, so stateless execution can move the security risk to the systems that keep state.

What the 2026 incident record shows about which controls actually fail

OpenAI’s September 20, 2026 training sandbox incident exposed gaps in outbound filtering, monitoring coverage, and stopping execution. An internal research model used the environment’s own DNS resolver to connect to an outside service. OpenAI identified “insufficient DNS filtering” and a detector that “excluded the affected environment”. The run was manually stopped two and a half hours after the alert.

That incident was a software policy failure. A VM can still have an overly permissive outbound path or an ineffective stop mechanism. Across the lab incident reports from OpenAI, Anthropic, and the UK AI Security Institute, the recurring failures concern outbound access, environment isolation, and the stop path. These controls remain necessary even when the underlying execution boundary is stronger.

Anthropic asked testing partners to commit to “sandboxes with no internet access by default, verified before every evaluation begins”. It also recommends a dedicated virtual machine for work on an untrusted repository or when security policy requires kernel-level separation between agent and host. Docker’s September 24, 2026 Cloud Sandboxes launch likewise placed each sandbox in a dedicated microVM. Docker’s president and COO Mark Cavage stated that “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”.

How do you give each AI agent its own isolated kernel without using containers?

A microVM provides a separate Linux kernel for the agent, with Intel VT-x or AMD-V enforcing the guest/host boundary. Those CPU virtualization extensions are what “hardware-enforced” means here. The guest kernel is inside the boundary. Even if an agent compromises that kernel, escaping the VM requires a further vulnerability in the hypervisor or hardware virtualization.

This does not make the runtime immune to attack. A DNS resolver or package proxy is a software interface the agent can reach and test with requests it is allowed to make. The hardware-enforced guest/host boundary sits below that execution layer and is not simply another service policy to persuade or circumvent. Software still participates in virtualization, but a guest’s authority does not derive from the host kernel’s namespace configuration.

Firecracker’s one-VMM-per-microVM design maps directly to a multi-tenant agent product. Each tenant receives an isolated VM, with that tenant’s identity injected at runtime. Kernel separation is structural rather than a shared-kernel permission setting. This is the concrete answer for deployments that require each agent to have its own kernel, rather than another configuration of a common container host.

The Docker architecture illustrates the complementary controls around that boundary. Each sandbox uses its own kernel, CPU virtualization, and a custom VMM. Its network egress firewall denies outbound traffic except the agent’s own API endpoints and explicitly allowed domains. Credentials are injected through a network proxy so agents never see raw host credentials.

The honest limits of microVM isolation and where the counterarguments hold

Hardened containers are still a reasonable choice for trusted internal code when its authors are known and patches are applied quickly. Seccomp, AppArmor, a read-only rootfs, no capabilities, and user namespaces provide meaningful defense-in-depth when developers control and review the workload. Operational simplicity is a legitimate consideration here. The hardware-boundary argument is strongest when the agent executes code generated from untrusted input or when mutually untrusted tenants share infrastructure.

GPU acceleration complicates the microVM case. VFIO GPU passthrough makes isolation depend on IOMMU mappings that bound the GPU’s DMA access, expanding the attack surface beyond a purely virtual device model. IOMMU misconfiguration or firmware bugs can undermine that separation. For workloads demanding both GPU acceleration and strict isolation, there is currently no clean architectural answer. A claim about isolated CPU execution cannot simply be extended to an attached device.

gVisor offers a different compromise through userspace syscall interception. It provides container-speed startup with VM-like isolation for many workloads, but its steady-state memory overhead is meaningfully higher than a standard container. Interception also adds latency that compounds in high-throughput agent workloads. The right choice depends on whether the threat model covers reviewed code or adversarial runtime execution.

What meaningful isolation actually requires for production agent deployment

An untrusted agent needs a per-agent hardware boundary, persistent state that survives lifecycle changes within that protection, sub-second wake latency, and idle economics that support deployment at scale. These requirements are connected. If dedicated isolation is too slow or expensive to retain, operational workarounds can reintroduce the shared resources that the architecture was intended to separate.

Persistence is therefore part of the security design. Files, credentials, and memory need to survive sleep and redeploy without forcing unrelated tenants into shared state attachments. An ephemeral execution environment does not eliminate that state. The responsibility moves to other systems, where volumes and external stores can become lateral movement paths. The per-user model instead calls for each tenant’s identity, state, and credentials to remain structurally separated from those of other tenants.

Snapshot-restore addresses the historical cost objection to one VM per user. It captures state, destroys the VM, and recreates it in under 200ms on demand, reducing idle cost to storage.