An AI agent that can write Python is only useful if it can also run that code without putting the rest of your infrastructure at risk. Coding agents, data analysis assistants, and autonomous “computer use” systems now routinely generate and execute arbitrary code on the fly, and none of that code has been reviewed by a human first. Sandboxed code execution is the discipline of giving agents a place to run that code where a mistake, a bug, or a deliberately malicious prompt injection can’t reach anything that matters.

This isn’t a theoretical concern. Agent harnesses built on frameworks like SmolAgents and OpenDevin treat the model’s code generation as trusted output but its runtime behavior as untrusted by default, because an agent’s script can attempt to read environment variables, write to disk, open outbound network connections, or probe for a way off the machine. The isolation layer underneath the agent is what decides whether any of that succeeds.

Why Standard Containers Aren’t Enough

Docker containers isolate processes using Linux namespaces and cgroups, but every container on a host still shares that host’s kernel. A kernel vulnerability or a misconfigured privilege can let code escape the container entirely. That risk is usually acceptable for code your own engineers wrote and reviewed. It is a different calculation when the code was generated seconds ago by a language model responding to a user’s prompt, because you have no guarantee the agent won’t be manipulated into writing something harmful. Security research published in 2026 found that sandboxed agents cut security incidents by roughly 90% compared to agents given unrestricted host access, which is the gap standard containers leave open.

MicroVMs: A Dedicated Kernel Per Execution

The strongest common answer is the microVM, popularized by AWS’s Firecracker project. Instead of sharing a kernel, each Firecracker microVM boots its own minimal Linux kernel inside hardware virtualization (KVM), with a deliberately small device model of roughly 50,000 lines of Rust. If an attacker escapes the guest operating system, they land inside the hypervisor’s tightly restricted process, not the host. Firecracker microVMs boot in around 100-125 milliseconds from cold, and snapshot-restore techniques can cut that to single-digit milliseconds by resuming a pre-booted image instead of starting from scratch. This is the approach platforms like E2B use to run untrusted LLM-generated code at scale, and it’s what Kata Containers builds on when it wraps microVM isolation inside a standard container API for Kubernetes environments.

gVisor: Isolation Without a Full VM

Google’s gVisor takes a different route. Rather than booting a second kernel, it runs a user-space kernel called Sentry that intercepts every system call a sandboxed process makes before it reaches the real host kernel. Of the hundreds of Linux syscalls an application might invoke, gVisor lets only a small, audited subset through. That shrinks the attack surface dramatically without the overhead of full virtualization, though it adds roughly 10-30% latency on I/O-heavy workloads and implements only a subset of Linux syscalls, so some low-level operations simply aren’t supported. Daytona’s workspace platform leans on this container-plus-gVisor model to prioritize persistence and fast cold starts for agents that need to keep files and dependencies across sessions.

Choosing Between Containers, gVisor, and MicroVMs

There’s no single right answer, only a fit for the threat model. Hardened containers are appropriate only when the code an agent runs is fully trusted and reviewed. gVisor is a solid middle ground for compute-heavy, semi-trusted workloads like CI pipelines or internal automation. MicroVMs through Firecracker or Kata Containers are the standard for anything running untrusted, LLM-generated code in production, especially in multi-tenant systems where one customer’s agent must never be able to see another’s data. The trade-off is that microVMs currently support GPU passthrough only on bare-metal hosts, since nested virtualization on managed cloud VMs blocks direct PCIe access.

What Production Sandboxing Requires Beyond Isolation

Isolation technology alone isn’t a complete answer. Production deployments pair it with egress filtering that blocks outbound network access by default, resource limits on CPU, memory, and disk to stop runaway loops, short-lived credentials scoped to a single task, and audit logging of every execution so a security team can reconstruct what an agent actually did. Treating all agent-generated code as potentially hostile, and building the sandbox around that assumption rather than around convenience, is what separates a demo from something a business can run unattended.

As agents take on more autonomous, multi-step work in 2026, the sandbox they run in has quietly become one of the most consequential infrastructure decisions a team makes. Getting the isolation boundary right the first time is far cheaper than discovering its limits after an incident.

References

1. How to sandbox AI agents in 2026: MicroVMs, gVisor & isolation strategies
2. Daytona vs E2B in 2026: which sandbox for AI code execution?
3. AI Agent Code Execution Sandboxes on GPU Cloud: E2B, Daytona, and Firecracker Setup Guide (2026)
4. Choosing a Workspace for AI Agents: The Ultimate Showdown Between gVisor, Kata, and Firecracker
5. awesome-agent-runtime-security (GitHub)

Research and written by Peter Jonathan Wilcheck