Posted inAI

Build a Secure Code Sandbox for AI Agents with E2B and Python

AI tutorial - IT technology blog
AI tutorial - IT technology blog

The 2:14 AM Out-of-Memory Alert That Froze Our Cluster

My phone went off at 2:14 AM with a high-priority PagerDuty ping. Our primary 32-core backend node had stopped responding, CPU load sat pegged at 100%, and disk I/O stalled completely.

Once I established a terminal session via our bastion host to inspect htop, the culprit was obvious. Our automated data analysis agent had tried parsing a 4 GB customer CSV by spawning an unchecked recursive subprocess loop. Even worse, it had dumped 18 GB of uncompressed chunk files straight into /tmp, filling the root partition to 100% capacity.

Invoking standard Python exec() on an application server turns every model hallucination into a potential infrastructure outage. In our case, one malformed prompt took down two critical internal services for nearly 45 minutes. If your application executes model-written code, sandboxing is non-negotiable.

Root Cause Analysis: Why Local Execution Models Collapse

After issuing kill -9 on the rogue parent process, our post-mortem highlighted three systemic flaws in local execution:

  • Process Escapes and Resource Starvation: Running untrusted scripts with subprocess.Popen or eval() shares the host kernel, swap space, and network interface. A runaway while True loop or an unconstrained NumPy array allocation starves adjacent worker threads immediately.
  • The Failure of AST Filters: Static analysis and syntax blacklists targeting modules like os or sys rarely hold up. Attackers—and creative LLMs—bypass naive string filters using getattr(), dynamic imports like __import__('sub' + 'process'), or base64 payloads.
  • Shared State Contamination: When an agent writes temporary files or mutates environment variables during Run A, Run B picks up those artifacts. That state leakage breaks run reproducibility and introduces severe security blind spots across tenants.

Evaluating Execution Strategies: From Subprocesses to MicroVMs

We tested three different execution models across 500 benchmark agent runs before finalizing our production design:

1. Native Subprocess with Resource Limits

import subprocess

# Risky: Shares host filesystem, memory space, and network
res = subprocess.run(["python3", "-c", agent_code], capture_output=True, timeout=10)

Linux cgroups and ulimit restrict CPU cycles and memory heaps, but they fail to enforce true isolation. They cannot prevent unauthorized outbound network requests, sensitive local file reads under /etc, or disk exhaustion attacks.

2. Ephemeral Docker Containers

Containerizing every task fixes filesystem leakage, yet spin-up times hover between 1.5 and 3.2 seconds per invocation. That delay degrades user experience during multi-turn LLM loops. Additionally, running Docker-in-Docker on Kubernetes worker nodes demands privileged access, which triggers compliance flags and expands your attack surface.

3. Firecracker MicroVMs via E2B Cloud Sandboxes

E2B boots isolated Firecracker MicroVMs in roughly 150 to 250 milliseconds. Each sandbox boots a stripped-down Linux kernel with dedicated CPU, memory, and virtual network interfaces. When the execution completes, the environment terminates cleanly, leaving zero lingering state on your servers.

Step-by-Step Implementation: Isolating Agent Workloads with E2B

Offloading code execution to isolated E2B sandboxes eliminated our server stability issues. Follow these steps to build a resilient execution runner in Python.

Step 1: Install the SDK and Export Credentials

Install the E2B code interpreter package alongside python-dotenv:

pip install e2b-code-interpreter python-dotenv

Add your API token to your shell environment:

export E2B_API_KEY="e2b_your_actual_api_key_here"

Step 2: Build the Sandbox Execution Wrapper

This implementation feeds raw agent code into an isolated environment, traps standard streams, and enforces a hard execution ceiling.

import os
from e2b_code_interpreter import Sandbox

def run_untrusted_agent_code(script: str) -> dict:
    """
    Runs arbitrary Python code inside an isolated E2B microVM.
    Returns stdout, stderr, and runtime errors without touching the host.
    """
    try:
        # Spin up a fresh, ephemeral microVM
        with Sandbox() as sandbox:
            execution = sandbox.run_code(
                script,
                timeout=30  # Hard 30-second ceiling
            )
            
            return {
                "status": "success",
                "stdout": [out.text for out in execution.logs.stdout],
                "stderr": [err.text for err in execution.logs.stderr],
                "error": execution.error.name if execution.error else None,
                "error_value": execution.error.value if execution.error else None
            }
    except Exception as exc:
        return {
            "status": "sandbox_failure",
            "error": str(exc)
        }

# Test payload: computing large values in memory
risky_agent_payload = """
import sys
import time

print("Executing analysis inside secure sandbox...")
data = [x ** 2 for x in range(500000)]
print(f"Processed {len(data)} items successfully.")
"""

result = run_untrusted_agent_code(risky_agent_payload)
print(result)

Step 3: Secure File Ingestion and Artifact Retrieval

Never mount host directories directly into agent environments. Write your input payloads to the VM virtual disk through the SDK, process the data, and stream generated artifacts back into application memory:

from e2b_code_interpreter import Sandbox

with Sandbox() as sandbox:
    # Upload a sample dataset into the VM environment
    csv_payload = "id,metric\n1,42\n2,85\n3,128\n"
    sandbox.files.write("/home/user/input.csv", csv_payload)
    
    # Execute data transformations inside the sandbox
    sandbox.run_code("""
import pandas as pd
df = pd.read_csv('/home/user/input.csv')
df['scaled'] = df['metric'] * 1.5
df.to_csv('/home/user/output.csv', index=False)
    """)
    
    # Retrieve the processed result as string or bytes
    processed_content = sandbox.files.read("/home/user/output.csv")
    print(processed_content)

Three Production Guardrails for Engineering Teams

Before launching agent-driven code execution to production users, enforce these baseline policies:

  1. Strict Timeouts: Explicitly pass a timeout argument (such as 30 to 60 seconds) to sandbox.run_code(). Generated code must never run indefinitely.
  2. Mandatory Context Cleanup: Wrap every call in Python’s with Sandbox() context manager. This ensures the MicroVM is destroyed promptly upon exit, preventing abandoned instances and excess billing charges.
  3. Restricted Network Egress: If your agent analyzes static CSV or JSON datasets, disable external network access in your sandbox template. Blocking outbound traffic eliminates data exfiltration and unauthorized external requests.
Share:
Tags: