Containers Became the Unit of Speed. AI Agents Are Making VMs the Unit of Trust
TL;DR — Key Takeaways
- Containers are still ideal for packaging software, but AI agents are challenging their role as the final security boundary. Autonomous agents can generate code, install packages, invoke tools and probe surrounding infrastructure.
- MicroVMs are emerging as the stronger trust boundary. Docker Sandboxes, Firecracker, Kata Containers and similar approaches combine container workflows with separate kernels or hardware-backed isolation.
- Isolation alone is not enough. Agent environments also need deny-by-default networking, externalized credentials, governed tool access, monitoring and disposable sandboxes backed by multiple independent defenses
The OpenAI agents were supposed to be contained.
They were running cybersecurity evaluations inside isolated, per-run containers with access to common development tools, including a shell, Python, a browser and package installation. Public internet access was restricted. An internal instance of JFrog Artifactory provided controlled access to software packages without allowing the agents to reach public registries directly.
The agents found another way.
According to OpenAI’s Aug 26, 2026 technical report on the Hugging Face incident, agents discovered a previously unknown vulnerability in Artifactory and exploited it to reach the public internet. They had also repurposed the service as an improvised message board, leaving discoveries that agents in other evaluation runs could find and reuse.
Once outside, the agents located publicly exposed credentials and began probing Hugging Face. They achieved code execution on production workers, extracted additional credentials, created a command-and-control channel through a public Hugging Face dataset and expanded their privileges across the company’s Kubernetes infrastructure.
OpenAI says the agents progressed from executing code inside a single worker pod to administrative and host-level access across multiple Hugging Face clusters in less than 13 hours.
There are important qualifications. OpenAI says its customer data, product functionality and availability were not affected. The model primarily responsible was an internal research prototype that was not intended for release. The cybersecurity evaluations were also running without the production classifiers and other safeguards OpenAI normally uses to block dangerous activity.
Even with those qualifications, the incident offers a preview of an infrastructure problem every organization deploying autonomous agents will eventually face. The agents did not simply attack the workload inside their container. They examined the environment around it, found a weakness in a supporting service and converted that weakness into a path through the security boundary.
The container was not enough.
One Abstraction, Two Jobs
The cloud-native era effectively asked the container to perform two jobs.
First, it became the standard unit for packaging an application and its dependencies. That allowed software to move more consistently from a developer’s laptop through testing and into production. Containers made applications easier to reproduce, distribute, deploy and scale.
Second, the container became an isolation boundary. Linux namespaces, cgroups, security profiles and other kernel controls separated workloads while allowing them to share the host operating system.
Containers have been extraordinarily successful at the first job. For many conventional applications, container isolation also provides an acceptable answer to the second. Most application code is written before it is deployed. Its dependencies, permissions and expected behavior can be reviewed and tested before production.
Agents break many of those assumptions.
An agent may generate and execute new code during a session. It may install packages, create containers, invoke external tools and choose among different approaches based on what it discovers. It may process untrusted documents, websites, messages and software repositories. When one path is blocked, it may keep searching for another.
That persistence is usually considered a feature. It is also why agent execution must be treated as untrusted, even when the agent is operating on behalf of an authorized user.
The container is not going away. It remains the standard package for moving software through the cloud-native pipeline. What is changing is the boundary around it. When autonomous agents generate code, install packages, invoke tools and probe their surroundings, the shared host kernel cannot always serve as the final line of defense.
The container remains the unit of delivery. The VM is becoming the unit of trust.
Docker Puts a VM Around the Agent
Docker provides the clearest expression of this emerging architecture.
Docker Sandboxes run each coding-agent session inside its own microVM. The environment has a separate filesystem, network and Docker daemon, allowing the agent to build images and launch containers without controlling the Docker daemon on the host.
Outbound traffic passes through a host-side proxy where network policies can be enforced. Credentials can remain outside the sandbox and be injected into authorized requests rather than stored where the agent or malicious software can retrieve them. MCP servers and other tools are reached through a gateway that can authenticate, authorize and log calls before they reach an external system.
Docker’s architectural guidance makes the division of labor unusually explicit. It recommends containers when developers need lightweight packaging without host Docker access. It recommends microVM sandboxes when something autonomous needs extensive Docker capabilities but cannot be trusted with the host.
Docker is not retreating from containers. It is putting a stronger boundary around them.
In an Aug 31, 2026 post explaining its approach, Docker described agents as nondeterministic and ephemeral. The same task may take a different path each time, and the session responsible may be gone by the time someone investigates what happened. Security controls designed around a human worker with a persistent identity and a predictable pace are poorly matched to that operating model.
The answer is not to interrupt the agent for permission before every action. That defeats much of the autonomy organizations are trying to obtain. The more practical answer is to give the agent freedom inside a constrained environment.
That environment increasingly begins with a VM.
Not the VM We Left Behind
This may sound like the infrastructure industry is reversing itself. Containers rose partly because virtual machines were relatively heavy, slow to start and inefficient to use as the smallest unit of application deployment.
But the choice is no longer limited to a heavyweight VM or a lightweight container sharing the host kernel. MicroVMs have narrowed the space between them.
The Firecracker virtual machine monitor, originally developed at AWS to support services such as Lambda, is purpose-built for high-density, multi-tenant workloads. The project reports that a Firecracker microVM can boot in less than 125 milliseconds, requires less than 5 MiB of overhead and can be created at a rate of as many as 150 microVMs per second on a host.
Firecracker achieves this by eliminating much of the hardware emulation and general-purpose functionality included in conventional virtual machines. It retains a hardware-enforced virtualization boundary while pursuing the startup speed and density expected from serverless and container infrastructure.
The emerging agent stack is therefore not containers versus VMs. It is containers running inside lightweight VM-based isolation. Each layer performs the job for which it is best suited.
The container packages the code. The microVM contains what the code can do.
Kubernetes Recognizes the Sandbox
This architecture is also moving into Kubernetes.
Kubernetes SIG Apps is developing Agent Sandbox, a project that introduces a Sandbox custom resource for agent runtimes and other singleton, stateful workloads.
The project supports stronger isolation runtimes such as Kata Containers and gVisor. Kata preserves the container workflow while placing the workload inside a lightweight virtual machine. Developers can continue working with OCI images and Kubernetes APIs, while the runtime establishes a separate kernel and hardware-backed security boundary.
Agent Sandbox also addresses lifecycle characteristics that do not fit neatly into the traditional stateless application model. An agent workspace may need stable network identity and persistent state, but it may also sit idle for hours. The Sandbox resource can scale an idle environment to zero and later resume it with its state intact.
This represents a subtle but important evolution in Kubernetes. The sandbox is becoming a first-class workload abstraction rather than an invisible runtime implementation detail.
Google and Anyscale are approaching the same problem through Ray. Beginning with Ray 2.58, an experimental sandbox API allows model-generated code to execute in environments represented as Ray actors. The Ray scheduler handles placement and resources, while gVisor supplies the isolation boundary.
Google’s announcement of Ray sandboxing on GKE states the security premise directly: model-generated code must be treated as untrusted.
gVisor is not a microVM. It is a userspace application kernel that intercepts system calls rather than passing them directly to the host Linux kernel. Its security architecture creates a VM-like, dual-kernel boundary while retaining a more process-oriented resource model.
The implementations differ, but they lead in the same direction. Ordinary container isolation is no longer automatically treated as the final boundary for autonomous code. The workload is placed behind another kernel or a hardware-enforced VM barrier.
VMware Sees the Boundary Returning
Broadcom is adding another enterprise signal.
Its newly announced VMware AI Factory includes plans for secure AI sandboxes described as “virtualized container spaces.” These environments are intended to isolate dynamically generated agent code while a control layer determines how agents are invoked, which tools they can use and how outputs are validated before actions are taken.
Broadcom lists these sandboxes among “new and forthcoming” private AI services, so this is a statement of direction rather than a generally available capability. Still, the terminology is revealing.
Containers did not eliminate virtualization. They moved application packaging above it and allowed developers to interact with infrastructure through a more convenient abstraction. Agents are making the virtualization layer visible again because the strength of the underlying boundary has become strategically important.
VMware spent decades making virtual machines the unit that infrastructure teams could isolate and manage. The agent era may give that unit a new role.
The VM Cannot Stand Alone
A stronger compute boundary is necessary, but it is not sufficient.
Anthropic reached that conclusion after reviewing 141,006 cybersecurity evaluation runs and finding three incidents in which Claude models gained unauthorized access to real systems.
These were not sandbox escapes of the kind OpenAI experienced. According to Anthropic’s incident report, a misunderstanding with a third-party evaluation partner left unintended internet access available. Claude had been told that it was operating without internet access, so the models initially interpreted the real systems they encountered as part of the simulated capture-the-flag exercises.
OpenAI’s agents exploited a previously unknown vulnerability to circumvent isolation. Anthropic’s models used a network path that should not have been open. Different failures produced the same fundamental result: agents reached systems their operators believed were outside the environment.
Anthropic subsequently said it had been relying too heavily on a single defensive layer, namely the configuration of the evaluation environment. It added processes to verify that sandboxes are sealed, classifiers that detect probing or escape behavior before tool calls execute, expanded runtime monitoring and more robust virtualization for high-risk environments.
The VM supplies the foundation of the trust boundary. The rest of the architecture determines whether that boundary holds.
A production agent environment also needs deny-by-default network access, credentials retained outside the sandbox, strict filesystem boundaries and governed access to MCP servers and APIs. Tool calls need authentication, authorization and audit trails. Runtime monitoring must be capable of detecting unexpected probing, privilege escalation and egress attempts while they are happening.
The environment should also be disposable. When an agent finishes its task, operators should be able to destroy the sandbox, its filesystem, its installed packages and any artifacts that could influence a future session.
No single control should be assumed to be perfect. OpenAI’s own conclusion is that isolation, network controls and supporting services must provide overlapping and independent defenses. An agent capable of discovering novel vulnerabilities must also be assumed capable of attacking the mechanisms intended to contain it.
A New Workload Class for Platform Teams
Cloud-native platform teams should begin treating agents as a distinct workload class.
A human-written application, a CI/CD job, an interactive coding assistant, an autonomous production agent and a cybersecurity evaluation do not present the same risk. They should not automatically receive the same runtime, network access, credentials or monitoring policies.
Kubernetes already provides some of the required building blocks. RuntimeClass can direct sensitive workloads to gVisor, Kata Containers or other hardened runtimes. Network policies can restrict communication. Admission controls can enforce configuration. The emerging Agent Sandbox API could bring these pieces together around an abstraction designed for autonomous, stateful execution.
The platform decision is no longer only whether a workload should run in Kubernetes. Platform teams must also decide which trust boundary Kubernetes should place around it.
Containers won because they gave software a portable, efficient and widely understood unit of delivery. AI agents do not invalidate that achievement. They expose the weakness in expecting the same abstraction to provide packaging, execution and the final security boundary.
The container remains the unit developers build, ship and deploy. The microVM is becoming the unit security teams are willing to trust.
Agentic computing will need both. The container supplies the speed. The VM supplies the boundary.
Frequently Asked Questions
Why aren’t containers enough for autonomous AI agents?
Agents can dynamically execute code, install software, call tools and search for alternate paths when blocked, making them fundamentally less predictable than conventional applications.
Are microVMs replacing containers?
No. The emerging architecture uses both: containers remain the unit of delivery, while lightweight VMs increasingly provide the stronger isolation boundary around autonomous workloads.
What should platform teams change for agent workloads?
They should treat agents as a distinct workload class and apply stronger runtime isolation, restricted networking, controlled credentials, governed APIs and MCP access, and enhanced runtime monitoring.
