# Agent Sandbox Comparison 2026: srt vs bubblewrap, Docker, gVisor, Firecracker, E2B and More

> A category-honest comparison and ranking of AI-agent command sandboxes in 2026 — Anthropic's srt against bubblewrap, Firejail, nsjail, Landlock, Seatbelt, Deno/Bun, Docker, gVisor, Firecracker, E2B, Daytona and others.

Source: https://playciso.com/blog/agent-sandbox-comparison-srt-vs-alternatives-2026 · Published: 2026-10-23 · Publisher: PlayCISO (https://playciso.com)

---

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](/blog/anthropic-sandbox-runtime-srt-explained) 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, macOS sandbox-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, srt on 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](/blog/anthropic-sandbox-runtime-srt-explained). Primary sources for this comparison: the [sandbox-runtime repository](https://github.com/anthropics/sandbox-runtime), the [Anthropic engineering blog](https://www.anthropic.com/engineering/claude-code-sandboxing), and the [Claude Code sandboxing docs](https://code.claude.com/docs/en/sandboxing).