Sandboxed Execution Environments

"A sandbox is not a prison. It is a safe place to let an agent make mistakes without consequences."

Guard, Carefully Contained AI Agent

1. Why Sandboxing Is Non-Negotiable

Any agent that executes code, modifies files, or interacts with system resources must operate in a sandboxed environment. Without sandboxing, a single hallucinated command could delete production data, install malware, or exfiltrate sensitive information. The sandbox provides a controlled environment where the agent can operate with the tools it needs while being physically isolated from systems it should not access. This is the single most important safety measure for production agents.

Sandboxing operates on the principle of least privilege: give the agent access to exactly what it needs and nothing more. A code execution agent needs access to a Python runtime and specific libraries, but not to the host machine's filesystem, network, or other processes. A browser agent needs access to a browser instance, but not to the host's other applications or local files. A data analysis agent needs access to the specific datasets it is analyzing, but not to other databases or services on the network.

The choice of sandboxing technology depends on the isolation level required. Process-level isolation (restricted user, chroot) is the lightest weight but provides the weakest guarantees. Container-level isolation (Docker, Podman) provides a good balance of security and performance. VM-level isolation (Firecracker, gVisor) provides the strongest guarantees at the cost of higher overhead. Cloud sandboxes (E2B) provide VM-level isolation as a managed service, eliminating the operational burden of managing sandbox infrastructure.

E2B Cloud Sandboxes

This snippet runs agent-generated code inside an E2B cloud sandbox, isolating execution from the host system.

from e2b_code_interpreter import Sandbox

# Create an isolated sandbox for code execution
sandbox = Sandbox(
 timeout=300, # 5-minute timeout
 # The sandbox runs in an isolated VM
 # No access to host filesystem, network is restricted
)

# Install required packages
sandbox.run_code("!pip install pandas matplotlib scikit-learn")

# Execute agent-generated code safely
result = sandbox.run_code("""
import pandas as pd
import matplotlib.pyplot as plt

# This code runs in a fully isolated environment
df = pd.read_csv('/data/sales.csv')
monthly = df.groupby('month')['revenue'].sum()
monthly.plot(kind='bar')
plt.savefig('/output/chart.png')
print(f"Total revenue: ${monthly.sum():,.2f}")
""")

print(result.text) # "Total revenue: $1,234,567.89"

# Download results
chart = sandbox.files.read("/output/chart.png")

# Sandbox is automatically destroyed after timeout
sandbox.close()

2. Docker and Container-Based Isolation

Docker containers provide the most commonly used sandboxing approach for production agent systems. Containers offer filesystem isolation, network control, resource limits (CPU, memory, disk), and reproducible environments. The agent's execution environment is defined in a Dockerfile, ensuring consistent behavior across development and production. Network policies can restrict the container to specific endpoints, preventing data exfiltration even if the agent's code is compromised.

Key Docker security practices for agent sandboxes include: running as a non-root user, mounting filesystems as read-only except for specific output directories, setting memory and CPU limits to prevent resource exhaustion, configuring network policies to allow only necessary outbound connections, using minimal base images to reduce the attack surface, and setting filesystem quotas to prevent disk-filling attacks. These controls should be enforced at the infrastructure level, not by the agent itself, since a compromised agent would disable its own restrictions.

3. Resource Limits and Abuse Prevention

Without resource limits, an agent-generated code snippet could consume all available memory, spawn infinite processes, or fill the disk with output. Resource limits are essential for operational stability and cost control. Set hard limits on CPU time, memory usage, disk I/O, network bandwidth, and execution duration. These limits should be enforced at the operating system or container level, where they cannot be circumvented by the agent's code.

Common abuse patterns to defend against include: fork bombs (the code spawns processes recursively), cryptocurrency mining (using the sandbox's compute resources for unauthorized purposes), network scanning (using the sandbox to probe internal infrastructure), and data exfiltration (encoding sensitive data into DNS queries, HTTP headers, or other covert channels). Each pattern requires specific mitigations beyond general resource limits.

4. Isolation Runtimes: gVisor, Firecracker, and Beyond

When Docker-level isolation is insufficient, two specialized runtimes provide stronger guarantees with different trade-off profiles. Understanding their architectures helps you choose the right isolation level for your agent workloads.

gVisor (Google) implements a user-space kernel that intercepts and re-implements Linux system calls. Instead of the container's code talking directly to the host kernel, gVisor's Sentry component mediates every syscall, applying its own security policy. This means a kernel vulnerability in the host cannot be exploited from within the container, because the container never makes direct kernel calls. gVisor runs as an OCI-compatible runtime (runsc), so existing Docker containers work without modification. The trade-off is performance: syscall-intensive workloads (heavy file I/O, many network connections) see 5% to 30% overhead due to the user-space interception layer.

Firecracker (AWS) takes a different approach: each sandbox runs inside a lightweight microVM with its own guest kernel. Firecracker VMs boot in under 125 milliseconds and consume as little as 5 MB of memory overhead per instance. The hypervisor exposes a minimal device model (no USB, no GPU passthrough, no PCI) that dramatically reduces the attack surface compared to QEMU or VirtualBox. AWS Lambda and Fargate use Firecracker in production to isolate millions of concurrent workloads. For agent systems that execute untrusted code, Firecracker provides near-hardware-level isolation with container-like startup times.

Network, Filesystem, and Capability Hardening

Beyond choosing an isolation runtime, production agent sandboxes require layered hardening at the network, filesystem, and capability levels:

Network isolation. Apply egress filtering so the sandbox can only reach approved endpoints. Use DNS allowlists to restrict which domains the agent's tool calls can resolve. Block all outbound traffic by default, then explicitly allow the LLM API endpoint, approved package registries, and any tool-specific services. This prevents data exfiltration even if the agent is compromised by prompt injection.

Filesystem isolation. Mount the root filesystem as read-only. Provide a tmpfs mount for scratch space with a strict size limit (e.g., 100 MB). Any volumes containing input data should be mounted read-only. Output directories should be the only writable paths, and they should be on a separate mount with quota enforcement. Never bind-mount host directories into the sandbox; copy data into isolated volumes instead.

Linux capability dropping. Containers start with a set of Linux capabilities that are often far more permissive than necessary. For agent sandboxes, drop all capabilities and add back only what is strictly needed. Critical capabilities to remove include: NET_RAW (prevents raw socket creation and network sniffing), SYS_ADMIN (prevents mounting filesystems, changing namespaces, and many privilege escalation paths), SYS_PTRACE (prevents debugging and memory inspection of other processes), and NET_BIND_SERVICE (prevents binding to privileged ports). Combine capability dropping with --security-opt=no-new-privileges to prevent any process inside the sandbox from gaining additional capabilities through setuid binaries or other mechanisms.

Exercises