Sandboxing AI Agents

AI coding agents run arbitrary code with full shell access on developer machines, often at the user's primary home directory, with credentials reachable through the normal filesystem. That's a threat model: a poisoned dependency, a prompt-injected instruction, or just an agent that misunderstood its task can do anything the user can. Sandboxing is the practical response — put a fence around the agent that constrains damage without breaking its ability to do useful work.

There's no single sandboxing layer that covers every failure mode. The mature approach is defence-in-depth across multiple layers.

The four layers

1. Filesystem and process isolation

Prevent the agent from reading credentials or writing outside its intended work area.

• Linux: namespace-based. bubblewrap-dev-env (Ciężarkiewicz's bubblewrap setup) read-only-binds most of the filesystem, writable-binds only the project dir and a few state dirs, and runs the agent under that. wirez per-process routing is adjacent but focuses on network, not filesystem.
• macOS: user + Seatbelt. hazmat creates a dedicated macOS user for the agent (so the host home is structurally unreachable), then adds a per-session Seatbelt kernel sandbox with default-deny access to credential paths even within the agent's own home.
• macOS / Linux: microVM. superhq (and its underlying shuru-sdk) goes a step further — each agent session boots inside its own microvm with its own kernel, so escape requires a hypervisor break, not just a syscall trick. Heavier per-session cost than namespaces or Seatbelt, but the strongest containment in this layer. The full landscape of microVM-based platforms (Fly.io Sprites, E2B, Vercel Sandbox, AWS Bedrock AgentCore, Microsandbox, Docker Sandboxes, Matchlock, etc.) is surveyed in microvm-2026; the matryoshka-isolation pattern (containers nested inside VMs) is becoming the dominant architecture across them.

These approaches all aim for "almost normal dev UX, with a wall between the agent and anything sensitive it doesn't need." They work because most agent operations don't actually need write access outside the project.

1b. Credential isolation at the wire

A tangential layer the four-layer model didn't cover originally: even with a strong sandbox, the agent typically holds an API key or OAuth token, and a sufficiently determined exfiltration can leak that secret to a permitted endpoint. superhq's auth gateway moves the credential out of the sandbox entirely — a host-side reverse proxy injects the credential into outgoing API calls at the wire boundary. The agent never holds the key, so a leaked-credentials threat collapses to a leaked-session-traffic threat (still bad, but bounded). Composable with all four layers below.

2. Network egress policy

Prevent the agent from exfiltrating data or contacting C2 infrastructure.

• pf firewall rules (hazmat) — block outbound SMTP, IRC, FTP, VPN protocols. Resolve known tunneling services (ngrok, pastebin, webhook.site) to localhost via DNS blocklist.
• The HTTPS hole. Both hazmat and bubblewrap-based setups can't block port 443 without breaking API calls. An agent can curl any URL over HTTPS and exfiltrate data.

This is where network policy alone stops being sufficient.

3. HTTP-layer interception with policy

Sit on the HTTPS path and inspect every outgoing request.

• crabtrap — Brex's LLM-as-a-judge HTTP proxy. CA cert installed during setup; agent TLS traffic intercepted; each request matched against static rules first, then (if unmatched) evaluated by an LLM judge against a plain-English policy. Allow/block/log in real time.
• Tradeoffs. Requires the agent to trust the proxy's CA. Adds latency per unmatched request. Can still be bypassed if the policy allows an endpoint that permits free-form data (issue comments, Slack messages).

This layer complements the previous ones: the OS sandbox blocks obvious moves, the network policy blocks known-bad protocols, the HTTP layer makes nuanced decisions on the remaining HTTPS traffic.

4. Syscall-level interception

The lowest layer: see and filter every system call the agent process makes.

• syscall-binary-rewriting — replace syscall instructions with INT3 traps, catch every syscall in a handler, decide whether to allow/modify/deny. Sub-microsecond overhead per syscall.
• Other approaches — seccomp-bpf (the standard Linux syscall-filtering interface), eBPF-based monitoring (little-snitch-linux uses eBPF for per-app network monitoring).

Syscall filtering is the most expressive but also the most intrusive. You get total control over what the agent can do at the kernel-interface level, and also a performance cost per syscall and a compatibility risk when legitimate syscalls get caught in the filter.

Which layer to pick

Rough mapping from threat to layer:

Most practical setups combine layers 1 and 2 (OS-level containment) with layer 3 (policy-aware HTTP interception) and skip layer 4 unless the operational overhead is warranted.

What sandboxing doesn't solve

• Policy quality. A sandbox enforces rules; it doesn't write them. If the policy allows "create GitHub issues" and the agent posts stolen secrets in an issue title, CrabTrap saw nothing suspicious.
• Agent-state tampering. If the agent's working directory includes its own config/memory (e.g. ~/.claude), a compromised session can poison future sessions. Only partial defences exist (snapshot before session, diff after — hazmat does this with Kopia).
• Trust in the sandbox's implementation. Bubblewrap relies on user namespaces, which have CVE history. Seatbelt is Apple-undocumented. The LLM judge in CrabTrap can be prompt-injected. None of these are hard isolation; they're "good enough" vs nothing.
• Supply-chain attacks at build time. If the agent's own binaries are poisoned, the sandbox runs the poison. The usual supply-chain-security practices still apply.

Reading the wiki's tools

• bubblewrap-dev-env — Linux, filesystem + process (Layer 1)
• hazmat — macOS, user + Seatbelt + pf firewall (Layers 1 + 2)
• superhq — macOS microVM orchestration with auth-gateway credential isolation (Layer 1 + 1b)
• crabtrap — HTTP-layer LLM-judge policy enforcement (Layer 3)
• syscall-binary-rewriting — syscall-layer control (Layer 4)
• wirez — Linux per-process network routing (Layer 2-adjacent, not an AI-specific tool but useful in the stack)
• little-snitch-linux — Linux eBPF per-app network monitor (Layer 2 observability)

Related

• microvm-2026 — Beganović's industry readout on the microVM substrate behind most modern Layer-1 implementations
• microvm, matryoshka-isolation, rust-vmm — substrate concepts under the strongest Layer-1 setups
• human-in-the-loop — the non-sandbox alternative: pause for confirmation on sensitive operations
• supply-chain-security — upstream defence that reduces the agent's exposure
• peril-of-laziness-lost — why sandboxed agents still need human oversight on design choices