Sandboxing: Isolation Boundaries for Agent Execution

In Lesson 2, Section 5, we introduced the Autonomy Ladder—a tiered model for classifying actions by risk (Tier 0: Pure Read through Tier 3: Irreversible). That model answers what an agent is allowed to do. This lesson answers the harder question: how do we technically enforce those boundaries so that even a prompt-injected, hallucinating, or malicious model cannot cause real-world harm?

Sandboxing is the engineering discipline of building execution cages—constrained environments where agent tool calls run with minimized privileges, isolated resources, and no path of escape to the host system.

Why Sandboxing Is Non-Negotiable

Without sandboxing, an agent's tool calls execute with the full privileges of the user who launched the agent. This creates an extreme attack surface:

• Prompt Injection: A malicious web page or document instructs the agent to rm -rf / or exfiltrate SSH keys. Without a sandbox, the agent happily complies.
• Hallucinated Commands: The model generates a plausible-but-destructive command (e.g., DROP TABLE users) that was never intended by the user.
• Dependency Exploits: A compromised npm package or PyPI dependency executes arbitrary code during npm install or pip install.
• Infinite Resource Consumption: A buggy agent loop spawns thousands of processes, exhausting CPU, memory, or disk.

The Sandboxing Stack: Four Layers of Isolation

Production-grade sandboxing is not a single mechanism—it is a defense-in-depth stack where each layer provides independent containment. If one layer fails, the others still protect the host.

• L1 — Filesystem Isolation: The agent sees a read-only root filesystem with a writable tmpfs workspace mounted at /workspace. Source code is bind-mounted read-only. Sensitive paths (~/.ssh, /etc/passwd, browser profiles) are either hidden or mounted as empty directories.
• L2 — Network Restrictions: Egress is denied by default. The agent can only reach pre-approved endpoints (e.g., a package registry mirror) via an HTTP proxy that enforces DNS allowlisting. Raw sockets, curl to arbitrary IPs, and nc are blocked at the firewall layer.
• L3 — Resource Limits: Linux cgroups cap CPU (e.g., 1 core), memory (e.g., 512 MB), process count (e.g., 64 PIDs), and disk I/O bandwidth. This prevents fork bombs, memory exhaustion, and disk-filling attacks from impacting the host or other tenants.
• L4 — Syscall Filtering: A seccomp-bpf profile whitelists only the ~50 syscalls needed for a development agent (read, write, open, close, mmap, etc.). Dangerous syscalls like mount, ptrace, kexec_load, and reboot are blocked at the kernel level.

Container Runtimes: From Docker to Micro-VMs

Not all sandboxing runtimes are created equal. The choice of container runtime determines the strength of the isolation boundary:

Mapping the Autonomy Ladder to Sandbox Configurations

The four-tier autonomy model from Lesson 2 maps directly to concrete sandbox configurations. Each tier gets a progressively more restrictive execution environment:

Filesystem Sandboxing: The First Line of Defense

The filesystem is the most common attack vector for agent escapes. A robust filesystem sandbox must address three independent risks:

• Path Traversal: The agent writes to ../../etc/cron.d/backdoor or /root/.ssh/authorized_keys.
• Symlink Attacks: The agent creates a symlink from /workspace/config.json to /etc/shadow and reads it through an allowed path.
• Device Access: The agent opens /dev/sda directly to bypass filesystem permissions.

# Example: Setting up a sandboxed filesystem namespace
# Create an isolated mount namespace
unshare --mount --pid --fork --mount-proc /bin/bash

# Remount root as read-only
mount -o remount,ro /

# Create a writable tmpfs workspace
mount -t tmpfs -o size=1g tmpfs /workspace

# Bind-mount source code read-only
mount --bind /home/user/project /workspace/project
mount -o remount,ro,bind /workspace/project

# Hide sensitive paths
mount -t tmpfs tmpfs /root
mount -t tmpfs tmpfs /home/user/.ssh

Network Sandboxing: Controlling Egress

Network egress is the exfiltration channel. An unsandboxed agent can curl sensitive files to an attacker-controlled server, participate in a DDoS botnet, or scan internal network services.

• 1 — Default Deny: The sandbox starts with no network interfaces. The agent cannot make any outbound connection unless explicitly permitted.
• 2 — Egress Proxy: All outbound HTTP/HTTPS traffic is forced through a local proxy (e.g., a sidecar container running mitmproxy or a custom allowlist proxy). The proxy enforces URL allowlisting and blocks non-HTTP protocols.
• 3 — DNS Allowlisting: The sandbox's DNS resolver only resolves pre-approved domains. Requests to any other domain return NXDOMAIN, preventing DNS-based exfiltration and tunneling.
• 4 — Raw Socket Blocking: The CAP_NET_RAW capability is dropped. The agent cannot create raw IP packets, perform ARP spoofing, or use ping/traceroute for network reconnaissance.

Sandbox Escapes: Understanding the Adversary

Sandboxing is an arms race. Understanding how sandboxes are escaped is essential for building effective defenses:

Practical Patterns for Agent Sandboxing

Here are the most common architectural patterns for sandboxing agents in production systems:

References & Deeper Reading

• gVisor Documentation — Google's user-space kernel sandbox for containers.
• Firecracker — AWS's KVM micro-VM for serverless and sandboxing.
• seccomp(2) — Linux syscall filtering — Kernel-level syscall allowlisting.
• cgroups v2 — Linux resource control — CPU, memory, PID, and I/O limits.
• OWASP: Path Traversal — Filesystem escape patterns and defenses.
• Anthropic: Building Effective Agents — Autonomy tiers and sandbox architecture for production agents.