Agent Sandbox Comparison 2026: srt vs bubblewrap, Docker, gVisor, Firecracker, E2B and More
Agent sandboxes fall into two honest categories: lightweight OS-primitive wrappers you run a command with (srt, bubblewrap, Firejail, nsjail, Landlock, Seatbelt) and stronger-boundary tools (Docker containers, then gVisor and Firecracker/microVM services like E2B). srt tops the lightweight-local-peer tier because it is the only peer with a built-in deny-by-default domain allowlist and a ready JSON policy — but it is explicitly below VM-class tools on raw isolation strength.
You've decided your AI agent needs a sandbox. Now which one — and is it even in the right category for your threat model? The honest answer in 2026 is that "agent sandbox" spans two very different tiers: lightweight OS-primitive wrappers you run a command with, and stronger-boundary tools (containers, then user-space kernels and microVMs). Picking across tiers without saying so is how teams end up believing a command wrapper is a breakout-proof boundary. This guide compares the field and ranks it honestly, with Anthropic's newly open-sourced srt as the baseline.
Two categories, stated up front
- True peers of
srt— lightweight, host-local, OS-primitive sandboxes you wrap a command with: bubblewrap, Firejail, nsjail, Landlock, macOSsandbox-exec(Seatbelt). - Different category — stronger boundaries and/or remote services: Docker containers, gVisor, Firecracker/microVMs, and cloud sandbox services like E2B. Runtime permission models (Deno/Bun) are a different category again — in-process, not OS-level.
The comparison table
| Tool | What it is | Isolation model & strength | OS support | Built-in network allowlist | Category vs srt |
|---|---|---|---|---|---|
| sandbox-runtime (srt) | Anthropic's OS-primitive FS+network sandbox for agents/CLIs | Seatbelt (mac) + bubblewrap/netns+seccomp (Linux) + WFP (Win alpha); OS-level, not a VM | macOS, Linux, WSL2; Windows alpha | Yes — deny-by-default domain allowlist via host HTTP+SOCKS proxies | — (baseline) |
| bubblewrap (raw bwrap) | Unprivileged namespace sandbox — the Linux engine srt builds on | Linux namespaces (mount/pid/net/user); strong FS/process isolation | Linux only | None (netns on/off; you add a proxy yourself) | True peer (lower-level; srt wraps it) |
| Firejail | SUID sandbox with a profile library for desktop/CLI apps | Namespaces + seccomp + capabilities; good app confinement (SUID surface is a knock) | Linux only | Per-profile netfilter/netns rules (coarser than a domain allowlist) | True peer |
| nsjail | Google's namespace/seccomp process jail (CTF/CI origin) | Namespaces + seccomp-bpf + rlimits + cgroups; strong, very configurable | Linux only | netns-based; no domain allowlist | True peer |
| Landlock | Linux LSM for unprivileged per-process FS (and recent net) rules | Kernel LSM; FS access control, limited TCP port rules on newer kernels | Linux 5.13+ only | Minimal (port-level on newer kernels); no domain filtering | True peer (primitive/library) |
| macOS sandbox-exec (Seatbelt) | Apple's built-in profile sandbox — the mac engine srt builds on | Kernel sandbox via SBPL profiles; strong, but a deprecated/underdocumented API | macOS only | Profile can gate host/port; no domain allowlist by itself | True peer (lower-level; srt wraps it) |
| Deno / Bun permissions | Runtime-level allowlist flags (--allow-read/-net/-write) | In-process runtime gate; covers only code run by that runtime, not arbitrary child CLIs | Cross-platform (where the runtime runs) | --allow-net=host:port allowlist (runtime-scoped) | Different (runtime permission model, not an OS sandbox) |
| Docker / containers | OS-level container isolation (namespaces+cgroups, shared kernel) | Shared-kernel container; stronger than bare namespaces, weaker than a VM | Linux native; mac/Win via VM | iptables/network policies; no domain allowlist by default | Different category (good to nest srt inside) |
| gVisor (runsc) | User-space kernel that intercepts syscalls before the host | Userspace syscall interception; much stronger than containers, below a VM | Linux (x86-64/arm64) | Via container networking; no built-in domain allowlist | Different category (stronger kernel-boundary) |
| Firecracker / microVMs | KVM microVM with its own guest kernel (AWS Lambda/Fargate origin) | Hardware-virtualized VM boundary; strongest common isolation | Linux/KVM host | Full VM networking; policy is up to you | Different category (microVM) |
| E2B | Cloud sandbox service for AI code execution | Firecracker microVMs per session, remote (reported across secondary sources; not confirmed against E2B's own docs this session) | Cloud (SDK cross-platform) | Managed by the service | Different category (cloud microVM service) |
| Daytona | Open-source/hosted dev-environment & agent sandbox runner | Backend-dependent: Docker containers by default, with Kata/microVM options reported; isolation depends on the backend chosen | Cloud + self-host | Container networking | Different category (env orchestrator / cloud) |
| Cloudflare Sandbox / Workers | Edge compute: V8 isolates (Workers) + a container sandbox SDK [UNVERIFIED — not primary-source-confirmed this session] | V8 isolate (weakest tier) for Workers; container for the Sandbox SDK; remote | Cloud/edge | Platform-managed egress | Different category (cloud/edge) |
| Apple Containerization | Framework running each Linux container in its own lightweight VM on macOS [UNVERIFIED — details from general knowledge, not confirmed via a primary source this session] | Per-container micro-VM on Apple silicon; VM-grade boundary (as reported) | macOS (Apple silicon) | VM networking | Different category (per-container VM) |
Rows marked [UNVERIFIED] or "reported" could not be confirmed against a primary source in our research pass — treat them as directional, not authoritative. The srt and OS-primitive peer rows are sourced from Anthropic's own documentation.
Ranking
Tier 1 — lightweight local peers (wrap-a-command). Winner: srt
For wrapping a local agent or CLI command with the least setup and a built-in network allowlist, srt is the best-fit peer. It is the only tool in this group that ships a deny-by-default domain allowlist and a ready JSON policy out of the box. Raw bubblewrap, Seatbelt, nsjail, Firejail and Landlock give you the same isolation primitives — in some cases srt is literally built on them — but you build the ergonomics yourself, especially the network layer. Honest framing: srt's value is ergonomics plus the network-allowlist proxy plus agent focus, not a stronger isolation boundary than bubblewrap or Seatbelt. It is those, with a much nicer interface.
Tier 2 — the middle layer: Docker
Containers sit between the OS-primitive peers and the VM-class tools. A shared-kernel container is stronger process/FS isolation than bare namespaces but weaker than a VM. In practice Docker is the pragmatic "nest srt inside me" defence-in-depth layer: run the container for the outer boundary, run srt inside it for the fine-grained filesystem and domain-allowlist policy.
Tier 3 — assume-breakout isolation: gVisor, Firecracker, E2B
For untrusted, multi-tenant, or "assume the code tries to break out" execution, step up a category. gVisor (a user-space kernel) and Firecracker/microVMs (hardware-virtualized) give a materially stronger boundary at the cost of more overhead; E2B is the managed, hosted version of that microVM approach. This is where srt explicitly does not compete — its own docs state it is not a complete isolation boundary, so it ranks below VM-class tools on raw isolation strength.
Special case — runtime permissions (Deno/Bun)
These only help if the agent's code runs inside that runtime. The --allow-net/--allow-read/--allow-write flags are a genuine in-process gate, but they do not confine arbitrary shell commands or spawned subprocesses. They are a complement to an OS sandbox, not a replacement for one.
How to choose, in one line each
- Local dev, wrap an agent/CLI, want a domain allowlist with minimal setup:
srt. - You already live on Linux and want the raw primitive: bubblewrap (or Firejail/nsjail for profiles/config) — then add your own network layer.
- Defence in depth for a semi-trusted agent: Docker on the outside,
srton the inside. - Untrusted or multi-tenant code: gVisor or Firecracker/microVMs; E2B if you want it hosted.
- Agent code that genuinely runs inside Deno/Bun: use the runtime flags as well, not instead.
Whatever tier you land on, pair the sandbox with visibility into what your agents actually connect to. For the deep dive on srt itself — mechanism, limits and a 13-point hardening checklist — read Anthropic sandbox-runtime (srt), explained. Primary sources for this comparison: the sandbox-runtime repository, the Anthropic engineering blog, and the Claude Code sandboxing docs.
Ready to practise the decisions these articles describe?
Run a free War Room →