AI Agent Code Execution Sandbox: What's Actually Running Your Code

The Flowise AI agent builder sat exposed for over six months with a CVSS 10.0 flaw - CVE-2025-59528, exploited across 12,000+ exposed instances, enabling full system compromise. The root cause was not some exotic kernel trick. The CustomMCP node parsed a user-provided config string to build an MCP server configuration but executed JavaScript code without any security validation. An agent that trusted its input, given raw Node.js runtime access, handed the host machine to whoever sent the right string.

That is the problem that agent sandboxing exists to solve. When your AI agent writes Python and runs it, something has to decide: what can that code actually touch?

What an AI agent code execution sandbox actually does

An AI sandbox creates an isolated execution environment where agents can run code without affecting the host system or other workloads, with strict boundaries that limit what an agent can access, modify, or interact with. That sounds straightforward until you think about what a coding agent actually does: it installs packages, writes files, spawns subprocesses, and makes HTTP calls - sometimes all in one turn.

An AI coding agent is not an autocomplete widget. It is an autonomous process that reads files, writes code, runs shell commands, installs packages, and makes HTTP requests. Each of those actions is a potential path to something it should not reach.

The security model operates on zero-trust principles where all agent actions are explicitly allowed rather than implicitly permitted, treating all AI-generated code as potentially malicious. That is a meaningful shift from how most software is architected. Traditional apps are trusted by default and restricted at the edges. A sandbox flips it: everything is blocked unless the sandbox explicitly says otherwise.

Traditional code sanitization - simply filtering out dangerous commands - doesn't work well for AI agents because malicious and legitimate code often look identical. You cannot read Python and reliably decide whether it is safe. So you stop trying to read it and contain it instead.

MicroVM vs container: the isolation that actually matters

The default instinct is Docker. Containers are fast, well-understood, and everywhere. The problem is structural.

Standard containers share the host kernel. As gVisor's documentation states directly: "with standard containers, the workload is only one system call away from host compromise." That is not a theoretical warning. Three high-severity vulnerabilities (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) were disclosed in runC, the underlying container runtime powering Docker, Kubernetes, and containerized workloads - enabling container escape attacks that allow attackers to break out and access the host system.

MicroVMs solve this differently. 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.

Here is how the main isolation approaches compare:

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.

The non-obvious trade-off: gVisor adds 5-15% overhead on syscall-heavy workloads, near-zero on typical coding tasks. Firecracker is heavier per-VM in memory but gives you hardware-level separation that no container CVE can cross.

How Firecracker makes 125ms isolation possible

Firecracker is AWS's open-source microVM monitor - the same technology underneath AWS Lambda. Firecracker's ≤125ms boot times enable near-instantaneous sandbox creation, while the <5 MiB memory overhead per microVM allows for high-density deployments essential for multi-tenant platforms.

That boot time is not an accident of fast hardware. Firecracker's snapshot-restore API is the core mechanism for sub-30ms sandbox creation. The process: boot a microVM to a ready state, snapshot its memory and block device state to local NVMe, then restore subsequent sandboxes from that snapshot.

In practice: E2B executes agent code in an isolated Firecracker microVM that boots in under 200ms, and returns stdout/stderr.

Cold starts hit 80ms same-region and 410ms p50 in real-world benchmarks. Fly Machines, by comparison, clocks in at 2.8 seconds p50 cold. That gap is user-facing.

The lifecycle of a single agent code execution looks like this:

1. Agent generates Python (or bash, or whatever the tool calls for)
2. Orchestrator sends the code to the sandbox API - one HTTP call
3. A pre-warmed microVM snapshot is restored from NVMe (the fast path - no full boot)
4. Code runs inside the VM with its own filesystem, its own kernel, no host network access
5. stdout/stderr is captured and returned
6. The VM is destroyed - no state persists to the next call unless you explicitly mount a volume

The sandbox is not merely a security fence. It is a cognitive boundary that simplifies the agent's operating environment by removing irrelevant state, restricting dangerous actions, and making the workspace inspectable. Isolation thereby serves the same representational function as other forms of externalization: it changes what the model must reason about.

What sandboxing cannot do - and what that means for your stack

Prompt injection currently has no fool-proof, deterministic prevention. Mitigations rely on probabilistic and layered technical controls such as classifiers, hardened system prompts, and strict input/output validation, because natural language input can overlap with both benign and malicious instructions. An agent execution sandbox cannot prevent prompt injection, but it can contain the impact and keep compromised agent operations isolated.

There is a subtler failure mode too. Research has found that several successful attacks were achieved without sandbox escape, by exploiting the agent's planning logic to produce unsafe code within the sandbox's constraints. A sandboxed agent asked to "clean up old files" can delete things it was allowed to delete. The sandbox contained the blast radius to the filesystem it was given. That might still be your production data directory.

An attacker can publish a malicious MCP tool that appears to perform a legitimate function but includes hidden instructions that execute when an AI agent invokes it. Without sandboxing, that tool inherits whatever permissions the agent process has, which often includes broad read/write access to the filesystem, environment variables containing API keys, and network access to internal services.

Agents are prone to unexpected behavior like installing packages, exporting credentials, or consuming compute on unintended tasks. Binary authorization lets you restrict execution the same way you would on a managed corporate laptop, limiting which programs can run, which domains are reachable, and what network calls are allowed.

The full defense-in-depth stack looks like this:

• Kernel isolation: microVM (Firecracker or Kata) for any adversarial or third-party code

• Network egress allowlist: block all outbound except explicitly permitted hosts

• Filesystem scope: mount only what this task actually needs, read-only where possible

• Resource caps: hard CPU/memory/time limits - hard caps on CPU, memory, and network bandwidth prevent denial of service from runaway processes or infinite loops

• Audit logging: every agent action, tool call, and resource access gets recorded for forensic analysis and compliance validation

AI agent sandboxing: common questions

What is an AI agent code execution sandbox?

An AI agent code execution sandbox is an isolated environment - typically a microVM or hardened container - where AI-generated code runs without access to the host system, production credentials, or other tenants' data. The sandbox enforces a zero-trust model: all actions are denied by default and only explicitly permitted operations are allowed.

Is Docker enough to sandbox an AI agent?

For low-risk, trusted workloads, Docker provides a useful baseline. For production agents that handle untrusted inputs or third-party tools, it is not sufficient. Docker containers share the host kernel, and container escape vulnerabilities (like the November 2025 runC CVEs) can bridge that gap. MicroVMs run a separate kernel per sandbox, which eliminates that class of escape.

How fast does a Firecracker microVM boot?

Firecracker boots a microVM in under 125ms from scratch, and purpose-built sandbox platforms using pre-warmed snapshots bring that down further - E2B reports 80ms same-region cold starts and sub-30ms restores via snapshot. The latency is low enough to use per-request, not just per-session.

Can sandboxing stop prompt injection attacks?

No. A sandbox contains the damage from a successful prompt injection - it limits what the hijacked agent can reach - but it cannot prevent the injection itself. Prompt injection has no deterministic defense; sandboxing is the layer that ensures a compromised agent cannot touch your production database or exfiltrate your SSH keys.

What is the difference between gVisor and Firecracker?

gVisor intercepts system calls in user space, acting as a synthetic Linux kernel without spinning up a real VM. It is faster to start than Firecracker and adds roughly 5-15% overhead on syscall-heavy workloads. Firecracker runs a full separate kernel per microVM, making kernel-level escapes essentially impossible at the cost of slightly more memory (~5 MiB per VM). gVisor is a good fit for Kubernetes deployments; Firecracker is better when you need the strongest isolation boundary.