An agent running on your laptop just wrote a Python script, called subprocess.run, and executed it - all without you touching a keyboard. That is the normal case now, not the edge case. The question is what sits between that script and your host filesystem.
That boundary is called a sandbox, and most teams have the wrong one.
Why a Docker container is not enough for AI-generated code
The standard move when you want to isolate something is to reach for Docker. Containers are fast to start, easy to reason about, and already in every CI pipeline. For code you wrote and you audited, they are fine.
Standard sandbox environments assume you control what code runs. AI agents write their own code during execution based on user prompts, external data, and model outputs you cannot predict or audit beforehand. The core problem: traditional sandboxing breaks when code writes itself at runtime.
AI agents generate and execute code at runtime from inputs that may be attacker-controlled. Standard containers share the host kernel, so a single runtime CVE can compromise the host. This is not theoretical. When runc CVEs dropped in 2024-2025 (CVE-2024-21626, then three more in 2025), engineers started thinking harder about what "isolation" actually means when an AI is writing arbitrary code on their machines.
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.
How a microVM actually works
Firecracker is an open-source virtualization technology purpose-built for creating and managing secure, multi-tenant container and function-based services. It runs workloads in lightweight virtual machines, called microVMs, which combine the security and isolation properties of hardware virtualization with the speed and flexibility of containers.
The key architectural fact: 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.
Firecracker has a minimalist design. It excludes unnecessary devices and guest-facing functionality to reduce the memory footprint and attack surface area of each microVM. This improves security, decreases startup time, and increases hardware utilization. Concretely: Firecracker, built by AWS for Lambda and Fargate, boots in under 125ms with less than 5MB memory overhead per instance by cutting everything a sandbox doesn't need - no PCI bus, no USB, no legacy devices.
The cold-start problem is solved through snapshots. Firecracker supports snapshotting a running VM's complete state to disk - full memory contents, CPU register state. When you restore from a snapshot, Firecracker doesn't boot a kernel. It doesn't run init. It doesn't start your agent. It memory-maps the snapshot file, loads the CPU state, and resumes execution from exactly where it left off. The VM doesn't know it was ever stopped. From the guest's perspective, time just skipped forward.
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 150ms.
Production services like E2B use exactly this model. E2B builds a full AI sandbox cloud service on top of Firecracker, used in production by Manus, Perplexity, and others.
In Manus's architecture, each agent task gets a full E2B sandbox VM containing Chromium, a terminal, a filesystem, and 27 other tools - one sandbox is a complete virtual computer.
The threat that sandboxing alone doesn't stop
A well-configured microVM isolates execution. It does not stop an agent from being told what to execute.
Tool 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 became concrete in December 2025. A Palo Alto Networks Unit 42 report documented the first real-world instance of malicious indirect prompt injection. This confirms that the attacks modeled in research are not theoretical; they already occur in production.
CVE-2026-22708, disclosed against Cursor, lets an attacker poison the agent's execution environment so allowlisted commands like git branch deliver arbitrary payloads. The allowlist made the attack easier by auto-approving the very commands the attacker needed.
The insight from Google DeepMind's CaMeL framework (March 2025) cuts to the heart of it: for AI agents with tool access, the most promising defence direction shifts from "detect malicious prompts" to "restrict what the agent can do regardless of what it is told." That is exactly what layered sandboxing enforces at the infrastructure level, independent of the model's behavior.
Scoping the sandbox: network, filesystem, credentials
Whenever an agent acts on the world - writing files, executing shell commands, calling external APIs - the harness must decide how much of the environment to expose and how to contain unintended side effects. Sandboxing is the engineering response to that requirement. It creates a controlled execution boundary that limits what the agent can read, write, and modify, and it provides the reproducibility guarantees that make failures diagnosable and rollbacks feasible.
Three controls matter most in practice.
Filesystem: The setup treats the agent as an untrusted process. It minimizes what it can access. The container gets the project workspace and a project-scoped state volume, and avoids broad host mounts. The developer's home directory is not exposed by default. Sensitive config is not implicitly shared.
Network: Network egress controls are among the most critical for cloud-hosted agent workloads. Agents that can reach the IMDS (169.254.169.254) can acquire host instance credentials, so the default policy should deny everything and explicitly allow only required endpoints.
Credentials: Scope credentials tightly - 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 doesn't explicitly need to finish its task.
Frontier models' success on apprentice-level cybersecurity tasks rose from under 10% in late 2023/early 2024 to roughly 50% in 2025. Sandbox designs calibrated to 2023 model capability may be insufficient for 2026+ models. That last point is worth sitting with: the sandbox you configure today is being tested against a more capable model tomorrow.
Beagle in action#eng-platform, 2:47pmThe practical hierarchy for most teams: Docker with a hardened profile for internal tooling where data exposure is limited and the code stays trusted; Firecracker or E2B for medium-to-high threat multi-tenant or untrusted input scenarios.
Cold starts of 500ms to 2 seconds make teams skip sandboxing on hot paths altogether. For AI-generated code, where the instruction itself is attacker-influenceable through prompt injection, that is the wrong threat model.
The engineering work here is not exotic. Spin up a pre-warmed microVM pool, mount the project directory read-only, block all outbound except the endpoints the agent actually needs, rotate credentials per-session. That is the whole checklist. The hard part is deciding to do it before something on your filesystem goes missing.