MicroVM Isolation for AI Agents: Why Containers Aren't Enough (and What AWS Lambda's Firecracker Gets Right)

MicroVM Isolation for AI Agents: Why Containers Aren't Enough (and What AWS Lambda's Firecracker Gets Right)

AI agents need VM-level isolation, not container isolation, because they run untrusted code by construction. An agent writes its own scripts, installs its own packages, and decides its own tool calls at runtime. No human reviewed that code before it executed. A standard container shares the host kernel with every other tenant on the box, so one kernel bug turns one escaped agent into a compromise of the whole host. A microVM gives each agent session its own guest kernel behind a hardware virtualization boundary, which is exactly the model AWS Lambda uses via Firecracker. This post explains why that boundary is the right one for agents, and how to decide which isolation level a given agent actually needs.

Why the agent threat model breaks container isolation

The threat model for AI agents is different from the threat model for your own microservices, and that difference is the whole argument. Your service runs code you wrote and reviewed. An agent runs code a language model generated seconds ago, in response to a prompt you may not fully control, using tools that can touch a filesystem, a shell, a network, or a database.

Containers were built for the first case. They isolate processes using Linux namespaces and cgroups, but every container on a host shares that host's single kernel. When the code inside the container is untrusted, the shared kernel becomes the attack surface: a kernel vulnerability reachable from inside one container is reachable from inside all of them.

For a normal app that risk is theoretical enough to accept. For an agent that can write its own Python, install arbitrary packages, and manipulate file descriptors, the shared kernel is a live liability. The agent's job is to produce and execute novel code, so "we reviewed it first" is never true. The isolation question for agents is not "namespaces or not" — it is "does the untrusted code get its own kernel."

What AWS Lambda's Firecracker gets right

Firecracker is the reference implementation of the answer. It is an open-source virtual machine monitor written in Rust that Amazon open-sourced in 2018 to run serverless workloads with VM-grade isolation at container-grade speed. According to the Firecracker project, it "initiates user space or application code in as little as 125 ms," supports "up to 150 microVMs per second per host," and each microVM "runs with a reduced memory overhead of less than 5 MiB." It uses the Linux Kernel-based Virtual Machine (KVM) to create and manage each microVM, so the boundary is enforced by hardware virtualization, not by software namespaces. The design and its security model are documented in the Firecracker NSDI '20 paper.

That combination is what makes microVM isolation for AI agents practical. You get a real VM boundary without paying multi-second boot times or hundreds of megabytes of overhead per instance. Firecracker has proven this at scale: AWS states it is "the same lightweight virtualization technology that has powered over 15 trillions of monthly Lambda function invocations."

In June 2026 AWS made the agent use case explicit. It launched AWS Lambda MicroVMs, which it describes as "a new serverless compute primitive within AWS Lambda that lets you run code generated by users or AI in isolated, stateful execution environments." The isolation guarantee is stated plainly: "Each session runs in its own dedicated MicroVM with no shared kernel and no shared resources between users, so untrusted code supplied by one user is contained to their execution environment." Each session can run up to 8 hours with up to 32 GB of memory, 32 GB of disk, and 16 vCPUs, and startup is fast because Lambda resumes from a Firecracker snapshot of a pre-initialized environment rather than booting cold.

The signal is that the largest serverless platform on earth reached for microVMs, not containers, the moment the workload became "run code generated by AI." That is the design decision this post argues you should copy.

Container vs microVM isolation for agents: the boundary that actually matters

The difference is not a feature checklist. It is where the trust boundary sits.

gVisor, Google's user-space kernel, is the honest middle ground. It intercepts a sandboxed process's system calls and handles them in a kernel written in Go, so the workload never talks to the real host kernel directly. That is stronger than a plain container and weaker than a VM. For agents with narrow tool access it can be a reasonable choice. For agents that can install packages, spawn subprocesses, and reach the network, the microVM boundary is the one that assumes the code is hostile and still holds.

The agent isolation ladder: match the boundary to the capability surface

Isolation is a cost, not a virtue. The right boundary is the weakest one that still contains what your agent can actually do. We use a simple ladder that maps an agent's capability surface to the isolation it needs. Score the agent on four axes, then climb to the highest rung any axis demands.

1. Tool access. Text-only, no tools? A container is usually fine. Shell, code execution, or a package manager? Climb.
2. Network reach. No egress? Low risk. Open internet or internal services? Untrusted code that can reach the network is a data-exfiltration path, so climb — and add egress controls, which isolation alone does not give you.
3. Persistence. Ephemeral, destroyed after each run? Lower risk. Long-lived state the agent keeps mutating across sessions? Climb, because a compromise now persists.
4. Autonomy. Human approves every action? You have a backstop. Fully autonomous loop with no human in the path? Climb to the top rung.

The rungs map directly to the table above: mostly-low axes sit on containers, syscall-heavy but bounded workloads sit on gVisor, and anything scoring high on tool access, network, or autonomy belongs in a microVM. The failure mode we see most often is teams picking the boundary based on what their platform makes easy, not on what the agent can do. The ladder inverts that: the agent's capabilities pick the boundary, and the platform has to meet it. Note the framework's limit — "it's in a container" answers "is the process namespaced," not "is the untrusted code isolated."

Isolation is necessary, not sufficient

A hard isolation boundary stops code from escaping its box. It does not, by itself, stop that code from exfiltrating data over a network call it was allowed to make, and it does not let one agent's services reach each other safely. Those are separate problems a serious agent runtime solves on top of the microVM.

This is where CreateOS Sandbox goes past the AWS Lambda MicroVMs model. Each sandbox is a Firecracker microVM with its own guest kernel, and on top of that boundary we add kernel-level egress control enforced with eBPF on the host, outside the VM, plus real overlay networking between sandboxes. For the deeper mechanics of how the per-VM kernel isolation and egress control work together, that teardown covers it; for what an isolated test environment looks like before code ships, start with what an AI agent sandbox is.

The takeaway is unchanged from the threat model we opened with. If your agent can write and run code you did not review, give it a kernel of its own, govern what it can reach, and destroy it when the session ends.

Frequently asked questions

Why do AI agents need microVM isolation instead of containers?

Because agents run untrusted, model-generated code by construction. Containers share one host kernel across every tenant, so a single kernel bug reachable from inside one container can compromise the host and every other container. A microVM gives each agent session its own guest kernel behind a hardware virtualization boundary, so an escape must defeat both the guest kernel and the hypervisor.

What is a Firecracker microVM?

Firecracker is an open-source virtual machine monitor written in Rust that Amazon open-sourced in 2018. It uses the Linux KVM interface to run lightweight microVMs that boot user code in as little as 125 ms with under 5 MiB of memory overhead each. It powers AWS Lambda and AWS Fargate at a scale of over 15 trillion monthly Lambda invocations.

What are AWS Lambda MicroVMs?

AWS Lambda MicroVMs, launched in June 2026, are a serverless compute primitive that lets you run code generated by users or AI in isolated, stateful execution environments. Each session runs in its own dedicated Firecracker microVM with no shared kernel between users, can run up to 8 hours, and supports up to 32 GB of memory and disk with up to 16 vCPUs.

Is a container ever enough to isolate an AI agent?

Yes, for narrow cases. An agent with no tool access, no network egress, and no persistent state has a small risk surface, and a container or a user-space kernel like gVisor can be reasonable. The boundary should match the agent's capabilities: text-only agents can sit in containers, but agents that execute code, install packages, or reach the network need a microVM.

What is the difference between gVisor and a microVM for agent sandboxing?

gVisor intercepts a sandboxed process's system calls and handles them in a user-space kernel written in Go, so the workload never reaches the real host kernel directly. That is stronger than a plain container but weaker than a VM. A microVM gives each workload its own guest kernel enforced by hardware virtualization, which is the stronger boundary for fully untrusted, autonomous agent code.

Does microVM isolation stop an agent from exfiltrating data?

No. Isolation stops code from escaping its box, but untrusted code that is allowed to make a network call can still send data out over that call. Preventing exfiltration requires egress governance enforced outside the VM, such as an allowlist applied at the host with eBPF. Isolation and egress control are two separate controls, and a production agent runtime needs both.

How fast does a Firecracker microVM start compared to a container?

Firecracker initiates user code in as little as 125 ms and can create up to 150 microVMs per second per host. Snapshot-based systems like AWS Lambda MicroVMs cut startup further by resuming from a pre-initialized memory and disk snapshot instead of booting cold, giving near-instant startup while keeping full VM isolation.

Can AI agents run a real multi-service system inside microVM isolation?

Yes, if the platform provides networking between microVMs. A single isolated microVM runs one workload well, but many agent tasks are several services that need to reach each other. CreateOS Sandbox puts each Firecracker microVM on a private overlay network so sandboxes can talk to each other under default-deny rules, which lets an agent stand up and test a small distributed system, not just a snippet.

About the author

Naman Kabra is the founder of CreateOS, the unified execution layer for AI, and its Sandbox product for running untrusted, model-generated code. He has been building in Web3 and decentralized infrastructure since 2017, and works daily on the isolation, networking, and deployment problems that surface when AI agents start writing and running their own code in production. Connect on LinkedIn.

Next step

If you are building an agent platform and need to run agents in production with a real kernel boundary per session, that is the exact problem CreateOS Sandbox is built for. If you are a security or platform team that cannot send untrusted code to someone else's cloud, book a design-partner call and we will walk the self-host topology with you.