Firecracker, the microVM technology AWS built for Lambda, boots a fresh virtual machine in roughly 125 milliseconds. That specific number is why it became the default isolation primitive for AI agent sandboxes. Without it, every time a coding agent ran a snippet, you'd either wait seconds or accept a weaker security boundary. The two constraints-latency and isolation-are what the whole sandboxing design problem is trying to solve at once.
What an AI agent sandbox actually is
Whenever an agent acts on the world-writing files, executing shell commands, calling external APIs-the harness must decide how much environment to expose and how to contain unintended side effects. Sandboxing is the engineering response. It creates a controlled execution boundary that limits what the agent can read, write, and modify, and provides reproducibility guarantees that make failures diagnosable and rollbacks feasible.
The key distinction: a sandbox is not a content filter. It does not stop the model from generating bad code. It stops that code from doing real damage when it runs. The ability to write and execute code is among the most dangerous capabilities an agent can have-a vulnerability in this area can easily escalate to a full Remote Code Execution attack on the host system, giving an attacker complete control.
The concrete job the sandbox does:
- Restricts filesystem access to a known scope
- Blocks or filters network egress (the agent should not be able to call arbitrary endpoints)
- Caps CPU and memory so a runaway loop cannot starve the host
- Destroys the environment after the task, leaving no state behind
The isolation stack: containers, gVisor, microVMs
The three main isolation approaches are microVMs (Firecracker, Kata Containers), gVisor (user-space kernel), and hardened containers. MicroVMs provide the strongest isolation with dedicated kernels per workload, gVisor offers syscall interception without full VMs, and containers work only for trusted code.
Here is where the stack differences actually bite you:
| Approach | Isolation mechanism | Cold-start latency | Shared host kernel? | Typical use |
|---|---|---|---|---|
| Docker (hardened) | Namespace + cgroup | ~500 ms | Yes | Internal dev tooling |
| gVisor | User-space Linux kernel | ~100 ms | No (syscall-intercepted) | Google Cloud Run |
| Firecracker microVM | Separate kernel per VM | ~150 ms | No | Manus, Perplexity, Claude Code |
Standard containers share the host kernel, so a single runtime CVE can compromise the host. Production-safe agent execution requires hardware-level isolation (microVMs or userspace kernels), default-deny filesystem and network policies, and layered escape prevention.
The shared-kernel problem is not theoretical. When runc CVEs dropped in 2024-2025 (CVE-2024-21626, then three more in 2025), the question of what "isolation" actually means when an AI is writing arbitrary code became urgent.
Firecracker's code base is roughly 100K lines versus QEMU's ~2M, and it exposes only 6 virtual devices. More critically, each microVM has its own independent Linux kernel-two sandboxes share no kernel code paths whatsoever, fundamentally eliminating the possibility of kernel vulnerabilities propagating laterally.
The latency engineering behind Firecracker matters too. The key to fast startup is pre-warmed snapshots: a pool of VMs is started ahead of time, brought to a ready state, and a memory snapshot is taken. Incoming requests restore directly from the snapshot rather than booting a kernel from scratch, reducing cold-start time to around 150 ms.
How a sandbox handles a real agent task
Take a concrete scene: a data-analysis agent is asked to parse a CSV, calculate quartiles, and plot the result. The user sends the file. Here is what the execution layer does, step by step.
The system spins up a new, ephemeral container or microVM from a minimal base image; copies the generated code into it; executes the code inside; captures stdout, stderr, and any generated files; then destroys the environment.
The agent never touches the host filesystem. The plot file comes back as an output artifact through a controlled channel. If the generated code had a bug that tried to write to /etc/passwd, the sandbox's read-only filesystem mount would refuse it silently, and the container would be destroyed at the end anyway.
Beagle in action#data-team, 2:07pmTool output is a prompt injection surface. A malicious payload can live inside an API JSON response or a CSV file just as easily as in a webpage. Your orchestration pipeline should verify that downstream actions trace back to the original task prompt, not to instructions injected through a retrieved document.
This is the part most sandboxing discussions skip. The sandbox isolates execution. It does nothing about what the model reads. One of the most compelling documented production exploits is EchoLeak, a zero-click prompt injection in Microsoft 365 Copilot (CVE-2025-32711) that allowed remote, unauthenticated data exfiltration through crafted emails. The vulnerability arose because the agent ingested untrusted external data through connected tools and treated it as valid operational context, allowing malicious instructions to redirect the agent's control flow and trigger actions with developer-level privileges.
A hardened microVM would not have prevented EchoLeak. The attack never tried to escape the execution environment-it hijacked the model's decisions before any code ran.
Network policy: the control most teams skip
Network egress controls are among the most critical for cloud-hosted agent workloads. Agents that can reach the IMDS endpoint (169.254.169.254) can acquire host instance credentials, so the default policy should deny everything and explicitly allow only required endpoints.
The practical rule: default-deny outbound, then explicitly allowlist what the agent actually needs. An agent that only needs to read a specific directory does not need write access to the filesystem root. Use short-lived IAM roles instead of long-lived API keys-if a credential does get exfiltrated, it should be useless within minutes. Give the agent nothing it does not explicitly need to finish its task.
Limits must be enforced at the cgroup level because application-level limits can be bypassed by agent-generated code. OWASP's Top 10 for LLMs 2025 classifies unbounded resource consumption as LLM10:2025.
AI agent sandboxing: common questions
What is AI agent sandboxing?
AI agent sandboxing is an execution boundary that prevents agent-generated code from accessing the host system, real credentials, or production data. It works by running the code inside an isolated environment-a container, gVisor instance, or microVM-with restricted filesystem access, filtered network egress, and enforced resource limits.
Does a sandbox stop prompt injection attacks?
No. Sandboxing isolates code execution; it does not prevent the model from being manipulated by malicious content it reads. Prompt injection through tool output or retrieved documents operates at the model's instruction-following layer, before any code runs. Sandboxing and prompt injection defenses are complementary, not substitutes.
Why are microVMs better than Docker containers for AI agents?
Standard Docker containers share the host kernel, so a kernel-level exploit in the container can reach the host. MicroVMs like those powered by Firecracker give each execution its own independent Linux kernel. Two sandboxes share no kernel code paths, which closes the lateral-escape path that container-based isolation leaves open.
How fast does a sandbox need to start?
For interactive agent workloads-coding assistants, chat interfaces-anything over 500 ms is noticeable. Production sandboxes use pre-warmed VM snapshots to hit ~150 ms restore times. Batch or background agent tasks can tolerate a full cold boot of around 1 second. The right target depends on where the execution appears in the user experience.
What should go in the network allowlist for an agent sandbox?
Start with nothing allowed outbound. Explicitly add only the endpoints the agent's specific task requires: the object store for file I/O, the API the agent is supposed to call, and nothing else. Explicitly block the cloud metadata endpoint (169.254.169.254) even if your default-deny policy should cover it-defense in depth matters when agent-generated code can reach the network stack.