Skip to content

msyvr/awesome-agent-sandboxes

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

86 Commits
.claude
.claude
 
 
.github
.github
 
 
data
data
 
 
docs
docs
 
 
references
references
 
 
scripts
scripts
 
 
tests
tests
 
 
.gitignore
.gitignore
 
 
.python-version
.python-version
 
 
LICENSE
LICENSE
 
 
README.md
README.md
 
 
pyproject.toml
pyproject.toml
 
 
uv.lock
uv.lock
 
 

Repository files navigation

awesome agent sandboxes

A comprehensive guide to sandboxing options for AI agents — coding agents, browsing agents, automation agents, and general-purpose assistants.

Whether you're a developer building with AI agents or someone using them for personal tasks, this guide helps you understand how to keep your system safe while agents work on your behalf.

Living repo. This landscape is moving fast. A weekly automated discovery job posts newly found candidates as open issues for review before they get added to the curated list. If you're looking for the bleeding edge, check those issues — but be aware they're unreviewed and discovery leans toward over-inclusion (rejection on review is common).

Additions chart

Weekly breakdown (click to expand)

Week of 2026-07-06 (1 entry)

Week of 2026-06-22 (1 entry)

Week of 2026-06-15 (1 entry)

Week of 2026-06-08 (2 entries)

Week of 2026-05-25 (1 entry)

Week of 2026-05-04 (3 entries)

Week of 2026-04-27 (3 entries)

Week of 2026-04-20 (5 entries)

Week of 2026-04-13 (10 entries)

Week of 2026-04-06 (13 entries)

Initial seed (2026-04-07, 48 entries — the "seed" bar in the chart)

Status — intermittently maintained (May 2026)

This repo is now maintained intermittently. No guarantees on freshness — discovery has wound down from daily → weekly → occasional. The most recent additions are reflected in the graph above and its Weekly breakdown drop-down.

Where did agent sandboxing land? After ~80 curated entries and a couple of months of discovery (strategy notes), the answer isn't "everyone converged on one tool." The category split by tier:

  • Commodity isolation got absorbed into infrastructure. "Run the agent in a box" stopped being a product. Frontier coding agents ship it built in — Claude Code (macOS Seatbelt + Linux bubblewrap), OpenAI Codex (Seatbelt/Landlock/seccomp). Cloud platforms turned it into a network primitive: Cloudflare Sandboxes reached GA in April 2026 (InfoQ), and gateways like Tailscale's Aperture now mediate agent credentials and config at the infrastructure layer rather than per-agent.
  • The cloud-sandbox vendor tier fragmented rather than consolidated. No M&A among E2B / Daytona / Modal / Runloop (Daytona raised a $24M Series A in February 2026); each carved a niche — cold-start, price, GPU/ML, ecosystem lock-in. The Superagent 2026 benchmark frames the open question directly: do sandboxes stay a discrete primitive or get absorbed into the platforms above them?
  • What survives as a distinct, still-evolving category is opinionated security primitives — credential isolation, audit chains paired with real isolation, threat detection, formal verification, and diff/commit/rollback governance — plus the macOS-without-Docker niche. That's what the curated list below is really about.
  • Regulation became a driver. The EU AI Act's high-risk obligations become enforceable August 2, 2026, demanding built-in audit logging and human oversight (Article 12) — spawning a wave of governance/audit-flavored orchestrators that layer compliance over commodity isolation. Useful for compliance; not sandboxes by this repo's definition.
  • Safety researchers reframed the box as one layer, not the mechanism. Dangerous-capability evaluations now run inside sandboxes (AISI's Inspect Sandboxing Toolkit), but the field's AI-control agenda treats containment as one layer beneath monitoring and control protocols — because escape benchmarks show frontier models can break out of plain containers, and agents can fingerprint their own evaluation environment from inside the sandbox. See docs/safety-research.md for depth.

Full reasoning: strategy updates 2026-04-25 and 2026-05-05.

Table of Contents

What is sandboxing and why should you care?

A sandbox limits what your AI agent can do on your computer (or in the cloud). Think of it like giving someone access to one room in your house instead of handing them the keys to the whole building.

Without a sandbox, an AI agent typically has the same access you do: it can read and modify any of your files, make network requests, install software, and run arbitrary commands. Most of the time that's fine. But when things go wrong, they can go wrong fast:

  • Deleted or overwritten files — an agent misinterprets an instruction and removes important data
  • Leaked credentials — API keys, tokens, or passwords in environment variables get sent to external services
  • Unwanted network requests — the agent reaches out to URLs you didn't expect, exfiltrating data or triggering costs
  • Runaway cloud bills — an agent spins up resources or makes API calls in a loop
  • Supply chain attacks — the agent installs a malicious package that compromises your system

A sandbox constrains these risks by enforcing boundaries the agent can't cross, no matter what instructions it follows.

Sandboxing is not all-or-nothing

Different sandboxes protect against different things. Understanding what a sandbox does and doesn't cover helps you choose the right one:

  • Filesystem isolation prevents the agent from reading or writing files outside a designated area. Most sandboxes offer this.
  • Network isolation controls what the agent can reach over the network. Some sandboxes block all network access; others use allowlists.
  • Credential isolation keeps API keys, tokens, and secrets out of the sandbox entirely. Few sandboxes do this — most rely on you to not pass secrets in.
  • Rollback lets you undo what the agent did if something goes wrong. Very few sandboxes offer this.
  • Audit records what the agent actually did, with cryptographic proof. This is rare but valuable for understanding incidents.

When evaluating a sandbox, ask: what specific risks does this protect against, and what does it leave exposed?

Sandboxing alone isn't enough

A sandbox limits what your agent does, but it doesn't address every risk an agent introduces. Defense in depth means combining a sandbox with other tools that cover different threats:

  • Supply chain defense — protect against malicious dependencies an agent might install. Tools like pmg intercept package installs (npm, pip, uv, etc.), check packages against threat intel, and run install scripts inside their own OS-level sandboxes.
  • Credential brokers — give agents temporary, scoped access to services like Google Drive or AWS without handing over real credentials. Tools like extrasuite provision per-user service accounts so an agent only sees explicitly shared resources.
  • Secret encryption — prevent agents from reading secrets out of .env files on disk. Tools like cloak encrypt secrets into an AES-256-GCM vault and replace them with structurally valid fakes, gating decryption behind Touch ID or password auth.
  • Credential proxying — inject secrets at the network layer so agents never see them. agent-vault (from Infisical) sits as an HTTP proxy between agents and APIs, transparently injecting credentials per-request. Works with any agent that speaks HTTP; SDKs for Docker, E2B, and Daytona environments.
  • Egress monitoring — observe and audit what an agent reaches over the network, even within an allowlist. Useful for catching unexpected behavior before it becomes a problem.
  • Action verification — cryptographic proof of what an agent actually did. Tools like signet provide Ed25519-signed action receipts with hash-chained audit logs, so you can verify and replay agent actions after the fact.

These complement a sandbox; they don't replace it. This guide focuses on sandboxes themselves, but if you're building a serious defense posture, look at the layers above and below.

Quick Start: sandbox your agent in 5 minutes

The fastest path to protection depends on what agent you're using and what OS you're on. Each option below includes what it protects and what it doesn't.

If you're using Claude Code

Claude Code has built-in sandboxing enabled by default. It uses OS-level primitives (bubblewrap on Linux, Seatbelt on macOS) to restrict filesystem and network access.

# Sandboxing is on by default — no setup needed.
# To verify, check that you haven't set dangerouslyDisableSandbox.

Protects against: Filesystem writes outside your project directory. Unrestricted network access (proxy-based domain allowlisting).

Known risks:

  • The dangerouslyDisableSandbox flag can be triggered by the agent itself — a demonstrated escape vector (Ona, March 2026)
  • macOS sandbox-exec is deprecated by Apple — could break in a future macOS update with no announced replacement
  • Process-level isolation (shared kernel) — weaker than VM or container isolation. A kernel exploit could bypass it.

If you're using OpenAI Codex

Codex enables sandboxing by default in both cloud and local modes.

  • Cloud mode: Code runs in an isolated container. Network access is disabled during the agent phase.
  • Local CLI (Linux): Uses Landlock + seccomp to restrict the agent to workspace-only writes.

Protects against: Filesystem access outside workspace. Network access during execution (cloud mode).

Known risks:

  • Cloud mode requires GitHub integration — your code is sent to OpenAI's infrastructure
  • Local mode is Linux-only (kernel 5.13+) — no macOS or Windows support
  • Container isolation (cloud) shares the host kernel

If you want stronger isolation

The options below provide deeper isolation than built-in agent sandboxing. They're listed in order of what security properties they offer, not brand recognition.

nono — kernel-enforced sandbox with credential proxy and audit (macOS, Linux, WSL2)

nono is the only sandbox that combines kernel enforcement with credential isolation, atomic rollback, and a cryptographic audit chain. Your API keys never enter the sandbox — nono proxies them at the network layer so the agent can use services without seeing credentials.

brew install nono
nono run -- claude

Protects against: Filesystem and network access (kernel-enforced). Credential leakage (keys never enter sandbox). Unrecoverable mistakes (atomic rollback). "What happened?" questions (cryptographic audit chain with Sigstore attestation).

Known risks:

  • Early alpha — not yet security-audited
  • Relatively new project, though very actively developed

Docker Sandboxes — microVM isolation for multiple agents (macOS, Linux)

Docker Sandboxes run your agent inside a dedicated microVM with its own Docker daemon, filesystem, and network. Stronger isolation boundary than process-level sandboxing.

# Requires Docker Desktop 4.58+ (or Docker Engine 29.1.5+)
docker sandbox run --image ubuntu:latest

Works with Claude Code, Codex, Copilot, Gemini, and Kiro.

Protects against: Filesystem and network access at the VM level. Cross-agent contamination (each sandbox is a separate microVM).

Known risks:

  • Experimental (released March 2026) — not production-hardened, no security guarantees yet
  • Docker daemon attack surface: Docker has a steady cadence of escape-class CVEs. CVE-2025-9074 (CVSS 9.3) allowed unauthenticated Docker Engine API access. Multiple runc CVEs in 2024-2025 enabled container escape. The daemon runs as root.
  • Isolation gap: Docker Sandboxes isolate where code runs but not what it's authorized to do. An agent with an API key inside a sandbox can still merge PRs, delete production data, or exfiltrate via allowed network egress.
  • macOS nesting complexity: On macOS, you get host → Apple VM → microVM → container → agent. Each layer adds potential attack surface and makes debugging harder.
  • Licensing: Docker Desktop requires a paid subscription for organizations with >250 employees or >$10M annual revenue. Docker Engine (CLI only) remains free.

cleanroom (Buildkite) — microVM isolation with credential proxy (macOS, Linux)

cleanroom runs your agent inside a Firecracker microVM (Linux) or Apple Virtualization.framework VM (macOS) with deny-by-default network egress and a host-side credential proxy — your API keys never enter the sandbox.

Protects against: Filesystem and network access at the VM level (hardware isolation boundary). Credential leakage (host-side proxy, keys never enter sandbox). Unauthorized egress (deny-by-default, policy-controlled allowlists via per-repo cleanroom.yaml).

Known risks:

  • Early project, no LICENSE file in repo
  • Newer than Docker Sandboxes, less community testing

Anthropic srt — sandbox any process or MCP server (macOS, Linux)

srt is a lightweight sandbox for arbitrary processes. Particularly useful for sandboxing MCP servers, which run with your permissions but are often third-party code.

npm install -g @anthropic-ai/sandbox-runtime
srt "your-command"

Protects against: Filesystem access outside allowed directories. Network access (proxy-based domain filtering with interactive approval — useful for discovering what a tool actually needs).

Known risks:

  • Beta research preview — APIs may change
  • Same macOS sandbox-exec deprecation risk as Claude Code
  • Requires Node.js

microsandbox — local microVM isolation (macOS, Linux)

microsandbox provides microVM isolation using libkrun, with no external server. Your credentials and data never leave your machine.

Protects against: Full VM-level isolation. Data locality (nothing sent to cloud).

Known risks:

  • Self-hosted — you're responsible for security updates
  • Smaller community
  • Requires KVM on Linux

Agent Safehouse — macOS sandbox profiles (macOS only)

Agent Safehouse generates macOS sandbox-exec profiles with a deny-first policy. Pre-built profiles for major coding agents, composable profile system, and a policy builder web tool.

brew install eugene1g/safehouse/agent-safehouse

Protects against: Filesystem and process access via macOS Seatbelt kernel enforcement.

Known risks:

  • macOS only (permanently — sandbox-exec is Apple-specific)
  • sandbox-exec deprecation risk
  • No network proxy or credential isolation

Cloud sandbox services (any OS)

If you'd rather not manage infrastructure, sign up for a cloud sandbox:

  • E2B — Firecracker microVMs, ~150ms startup, free tier
  • Modal — GPU support, sub-second starts
  • Daytona — container-based, state management (pause/resume)
  • Fly Sprites — persistent Firecracker microVMs with 100GB NVMe per sprite

Protects against: Full VM or container isolation. No local system access.

Known risks:

  • Your code and data run on someone else's infrastructure
  • Cloud-only — requires internet access
  • Usage-based pricing can accumulate
  • Ephemeral by default (except Daytona and Fly Sprites which offer persistence)

Choosing a sandbox

Use this decision tree to narrow down your options:

Do you already use an agent with built-in sandboxing?
├── Yes (Claude Code, Codex) → You have basic protection. Consider
│   stronger options below if you handle sensitive credentials or
│   need rollback/audit capabilities.
│
└── No → What matters most to you?
    │
    ├── Credential safety (API keys, tokens)
    │   ├── nono — keys never enter the sandbox + rollback + audit
    │   └── cleanroom — keys never enter the sandbox + microVM isolation
    │
    ├── Undo mistakes (rollback)
    │   └── nono — atomic rollback with integrity verification
    │
    ├── Strongest isolation boundary
    │   ├── Local → cleanroom, Docker Sandboxes, microsandbox, or sand (microVM)
    │   └── Cloud → E2B, Modal (Firecracker microVM)
    │
    ├── Sandbox MCP servers / third-party tools
    │   └── Anthropic srt — designed for this use case
    │
    ├── Simplest macOS setup
    │   └── Agent Safehouse (brew install, pre-built profiles)
    │
    ├── Cloud (don't want to manage infrastructure)
    │   ├── Need GPU? → Modal
    │   ├── Need persistence? → Fly Sprites or Daytona
    │   └── General purpose → E2B (most mature, free tier)
    │
    └── Kubernetes
        ├── On GKE? → GKE Agent Sandbox
        └── Any K8s cluster → agent-sandbox (kubernetes-sigs)

Safety & Alignment Research

If you're doing AI safety research, RL training, capability evaluation, or adversarial red-teaming, see Sandboxing for AI Safety & Alignment Research — these contexts have fundamentally different containment requirements from general agent use.

The sections below are generated from data/sandboxes.yaml. They cover the full landscape: cloud services, standalone tools, VM runtimes, OS primitives, and WebAssembly runtimes.

Detailed Sandboxes Reference

The landscape at a glance, followed by per-category tables. Full per-entry details are in docs/.

Quick Triage

Three views of the same landscape to help you find what fits.

How strong is the isolation?

Tier Mechanism Examples Trade-off
Hardware VM (KVM) Full hardware virtualization with separate kernel per sandbox. locki, brood-box, cleanroom, gondolin, cua, +4 more Higher overhead and resource use; requires KVM/hypervisor.
MicroVM Lightweight VMs (e.g., Firecracker) with fast startup and low overhead. E2B, Modal, Runloop, Northflank, Fly Sprites, +11 more Slightly weaker than full VMs; Linux-only for most options.
Container / User-space Kernel Shared kernel with namespace or syscall isolation (Docker, gVisor). Daytona, Koyeb, OpenAI Codex Sandbox, agent-infra/sandbox, llm-sandbox, +25 more Shared kernel means a kernel exploit can bypass isolation.
Process-level OS-level restrictions on a process (namespaces, LSMs, Seatbelt). Claude Code Sandbox, pi-sandbox, loop, nono, Anthropic sandbox-runtime (srt), +21 more Weakest containment boundary; not for adversarial workloads.
Wasm / Language Runtime WebAssembly or V8 isolate sandboxing. Cloudflare Dynamic Workers, monty, Wasmtime, WasmEdge, wasmCloud, +2 more Limited to specific runtimes; can't run arbitrary binaries.

How do I get started?

Effort What it means Examples
Zero-config Built into the agent — sandboxing is on by default with no setup. Claude Code Sandbox, OpenAI Codex Sandbox
Sign up for a service Create an account and use a cloud API/SDK. No local infrastructure. E2B, Daytona, Modal, Runloop, Northflank, +11 more
Install a tool Install a standalone tool or runtime on your machine. pi-sandbox, loop, Docker Sandboxes, nono, Anthropic sandbox-runtime (srt), +49 more
Compose building blocks Assemble from OS primitives or VM runtimes. Requires systems knowledge. Firecracker, gVisor, Kata Containers, libkrun, Zeroboot, +11 more

Where does it run?

Model What it means Examples
Built into agent Sandboxing ships with the agent itself. Claude Code Sandbox, OpenAI Codex Sandbox, pi-sandbox
Cloud managed Runs on someone else's infrastructure. E2B, Daytona, Modal, Runloop, Northflank, +13 more
Local Runs on your machine, data stays local. loop, Docker Sandboxes, nono, Anthropic sandbox-runtime (srt), NVIDIA OpenShell, +44 more
Self-hosted You host and manage the infrastructure. Coder, OpenSandbox, Firecracker, gVisor, Kata Containers, +6 more
Kubernetes Runs on a Kubernetes cluster. Agent Sandbox (kubernetes-sigs), GKE Agent Sandbox, treadstone, openkruise/agents, sandbox0, +2 more

Cloud Managed Sandboxes

Managed cloud services that provide sandbox environments via API/SDK. You sign up and get isolated environments on demand.

Name OSS? Isolation Notes
Bunnyshell AI Sandboxes No microvm MCP server integration is notable — direct plugin for Claude Code, Cursor, and Windsurf.
Cloudflare Dynamic Workers No v8-isolate Unique edge-first approach using V8 isolates instead of containers/VMs. Credential injection without agent visibility is a strong security feature. Open beta early 2026.
CodeSandbox SDK No microvm Well-established brand from the browser IDE space, expanding to agent use.
Daytona Yes (Apache-2.0) container Pivoted from CDE space (Feb 2025). $31M Series A (Feb 2026). State management (pause/resume) is a key differentiator vs. ephemeral-only platforms.
E2B Yes (Apache-2.0) microvm One of the earliest and most widely adopted agent sandbox platforms. Docker MCP Catalog partnership.
Fly Sprites No microvm Persistence is the key differentiator — most sandboxes are ephemeral. Checkpoint/restore enables warm resumption of long-running agent sessions.
Modal No microvm Only major sandbox platform with GPU support — unique differentiator for ML/AI workloads that need compute.
Northflank No kata, gvisor BYOC option is unusual in this space — most cloud sandboxes are single-provider. Production-proven at scale (2M+ workloads/month).
Runloop No microvm Enterprise compliance focus (SOC 2) differentiates from developer-oriented alternatives. GA May 2025.
Superserve Yes (Apache-2.0) microvm Firecracker-based like E2B. SDK is open source (Apache-2.0) but the sandbox backend infrastructure is in a separate private repo. Beta — evaluate maturity before committing to production use.
Vercel Sandbox No microvm Tightly integrated with Vercel deployment pipeline and v0.

Agent-Integrated Sandboxes

Sandboxing built directly into AI agent products. These activate automatically or with minimal configuration.

Name OSS? Isolation Notes
Claude Code Sandbox No user-namespace, seatbelt Demonstrated escape by Ona (March 2026) via dangerouslyDisableSandbox flag. Uses bubblewrap on Linux, Seatbelt on macOS — different mechanisms per OS.
loop Yes (Apache-2.0) container, seccomp Differentiator vs commodity Docker-tier entries is the seccomp RET_USER_NOTIF + chat-routed HITL approval stack: kernel-parked traps resume only on SECCOMP_IOCTL_NOTIF_SEND with the CONTINUE flag, with path arguments read via process_vm_readv and symlink-resolved before the chat card is rendered. README credits agentsh for design inspiration; novel axis here is HITL governance via team chat rather than CLI prompts. ~11,500 LOC with a 1:1 test ratio despite low star count — code is production-grade on the security-critical paths.
OpenAI Codex Sandbox No container, landlock, seccomp Only major agent with sandboxing enabled by default. Two-phase model (online setup, offline agent) is a unique security architecture — the agent never has network access during execution.
pi-sandbox Yes (MIT) seatbelt, user-namespace Thin agent-specific layer atop Anthropic sandbox-runtime, demonstrating that runtime as a reusable library for non-Anthropic agents. Differentiator over Claude Code's sandbox is the four-tier permission persistence with explicit asymmetric precedence between read and write rules.

Standalone / Self-Hosted Tools

Tools you install and run yourself to sandbox any agent or process on your own machine.

Name OSS? Isolation Notes
Agent Safehouse Yes seatbelt More mature than it appears — has CI tests, docs site, and thoughtful profile composition. The most polished macOS-specific sandboxing option.
agent-infra/sandbox Yes container Kitchen-sink approach — good for prototyping and development, less suitable for security-critical production use.
agent_sandbox Yes (MIT) user-namespace, landlock, seccomp Only sandbox surveyed with first-class HPC/Slurm awareness — the chaperon proxy intercepts Slurm submission and wraps job commands so an agent cannot escape by submitting an unsandboxed job to a compute node. Munge auth is deliberately blocked inside the sandbox so only the outside chaperon can submit. Bind-mount filesystem isolation returns ENOENT rather than EACCES, which sidesteps the ld-linux and /proc/self/root evasions that have hit Landlock-allowlist sandboxes. Ships with a 32 KB threat model and a documented pentest cycle.
agentsh Yes (Apache-2.0) process, landlock, seatbelt Real runtime enforcement, not just wrapping. The "redirect" policy decision is unusual — can transparently steer agent network calls or out-of-workspace writes to scratch dirs without the agent knowing it was redirected.
ai-sandbox-wrapper Yes container Opinionated hardening over default Docker — capability dropping and Git fetch-only mode are substantive choices most Docker wrappers don't make. No license means the code is technically all-rights-reserved by default; consider asking the author to add one before relying on it.
aide Yes (MIT) seatbelt The capability model is the differentiator — 19 built-in capabilities (docker, k8s, aws, etc.) with composable grants and never-allow hard denials. More opinionated than fence or Agent Safehouse about what agents should be allowed to do. Linux sandbox is planned but not yet implemented.
alcless Yes (Apache-2.0) process From AkihiroSuda (maintainer of Lima, nerdctl). Deliberately positioned as the lightweight complement to Lima (VM-based). Zero VM overhead — just Unix user separation. The rsync + confirm workflow means changes don't land on the host without approval.
Anthropic sandbox-runtime (srt) Yes (Apache-2.0) user-namespace, seatbelt Designed to sandbox any process, not just Claude Code. Interactive network approval mode is useful for discovering what network access a tool actually needs.
brood-box Yes (Apache-2.0) kvm, microvm From Stacklok (founded by Luke Hinds of Sigstore). Hardware VM isolation like cleanroom, but adds TOCTOU-resistant diff review — the VM is stopped before the user reviews changes, preventing the agent from modifying files during review. DNS egress firewall and non-overridable secret exclusions are strong default posture.
cleanroom Yes microvm, kvm From Buildkite (established CI company). Strongest isolation in recent discovery batches — hardware VM boundary, not containers or namespaces. Credential proxy model is similar to nono (keys never enter the sandbox). cleanroom.yaml per-repo policy is a clean declarative approach.
code-on-incus Yes (MIT) container, seccomp Goes beyond isolation into active defense — the monitoring daemon uses kernel-level nftables packet inspection to detect reverse shells, C2 callbacks, DNS tunneling, and data exfiltration patterns, then auto-pauses or kills the container. Supply-chain hardening (read-only git hooks) is a detail most sandboxes miss.
Containarium Yes (Apache-2.0) container SSH-native per-tenant LXC/Incus boxes; blast radius is bounded by an SSH key rather than a cluster token. Ships two MCP servers (host admin and an in-box shell_exec). The tagline advertises eBPF egress, but that code is experimental — the shipping egress control is a userspace SOCKS5 proxy.
cua Yes (MIT) microvm Provisions full graphical desktops for macOS, Windows, Linux, and Android — distinct from container/microVM sandboxes that only give Linux shells. One of few options that legally and performantly virtualizes macOS for agent workloads, via Apple Virtualization.framework on Apple Silicon. Designed for visual/UI-driven agents rather than code-execution agents.
Docker Sandboxes No microvm Very new (March 2026). Multi-agent support is notable — works with most major coding agents out of the box.
EdgeBox Yes (GPL-3.0) container The GUI desktop environment (VNC) is the differentiator — agents can operate browsers and desktop apps, not just execute code. Essentially a self-hosted E2B with a GUI layer for computer-use agent workflows.
envpod-ce Yes (BSL-1.1) user-namespace, seccomp The diff/commit/rollback workflow is unique — agents work on real host files via an OverlayFS overlay, and changes are staged for human review before committing to the host. Most sandboxes either fully isolate (agent can't touch host files) or don't isolate at all. This is a middle ground that enables real work with reversibility. BSL-1.1 license restricts production use without a commercial license.
fence Yes (Apache-2.0) seatbelt, user-namespace Lightest-weight option for wrapping agent processes with real isolation — no container runtime needed. Inspired by Anthropic's srt. Built-in agent templates mean zero config for common agents. Well-documented security model and architecture.
gocker Yes (Apache-2.0) microvm Different from cleanroom/sand/locki — gocker is a Docker replacement on macOS, not an embeddable sandbox library. The Docker-compatible API means existing Docker workflows and tools (compose, Portainer, Testcontainers) work out of the box, but each container is a hardware-isolated microVM via Apple Virtualization.framework.
gondolin Yes (Apache-2.0) kvm, microvm The programmable egress hooks are the differentiator — host-side HTTP/TLS interception with per-secret, per-destination injection gives fine-grained control over what credentials reach which endpoints, without the agent ever seeing the real values. Similar credential model to nono and cleanroom but with a TypeScript programmable control plane rather than CLI/config.
hazmat Yes (MIT) seatbelt, process Strongest macOS-specific sandbox — layers everything alcless (user isolation) and Agent Safehouse (Seatbelt) do individually, plus pf firewall and DNS blocklists. TLA+ formal verification of session lifecycle is unusual rigor for a sandbox tool. Honest about limitations (HTTPS exfil, shared /tmp).
hole Yes (Apache-2.0) container The --dump-network-access flag is useful for discovering what network access an agent actually needs — similar to Anthropic srt's interactive approval mode but post-hoc. Docker-in-Docker support is unusual and needed for agents that themselves use containers.
jailoc Yes (MIT) container Backed by Seznam (Czech search engine). Network isolation via iptables allowlist prevents pivot to internal infra. The DinD sidecar approach avoids the common docker.sock mount escape vector.
LINCE Yes (MIT) user-namespace Bundled agent-sandbox module is usable independently of the dashboard (agent-sandbox run -a codex). Differentiator is the multi-agent TUI orchestration plus voice input layered on standard bubblewrap isolation, packaged as a complete coding workstation.
llm-sandbox Yes (MIT) container Multi-backend support is the differentiator — same API across Docker, Podman, and K8s. Good for sandboxing LLM-generated code execution specifically. SonarCloud + codecov CI suggests reasonable code quality standards.
locki Yes kvm, container One of the few sandboxes that layers VM (Lima/QEMU) plus container (Incus) for coding agents — interesting design worth tracking. Author is candid about "no security guarantees" in the README. No license means the code is technically all-rights-reserved by default; consider asking the author to add one before relying on it.
microsandbox Yes microvm Local-first is the key differentiator — no credentials leave your machine. Good for privacy-conscious users handling sensitive API keys.
monty Yes (MIT) process Different approach from Pyodide — a custom Rust interpreter rather than CPython compiled to Wasm. Will power Pydantic AI's codemode feature. Backed by Pydantic, but explicitly experimental. Categorized in the wasm tier because language-runtime sandboxing fits the same isolation strength characterization (fastest/lightest, limited to specific runtimes), even though it's not actually Wasm.
nono Yes (Apache-2.0) landlock, seatbelt Unique combination of properties no other tool offers: credential proxy (API keys never enter the sandbox), attestation, and atomic rollback. Easy setup (brew install, then nono run -- claude). Very active development.
NVIDIA OpenShell Yes (Apache-2.0) landlock, seccomp NVIDIA backing gives visibility. OPA/Rego policy support targets enterprise governance workflows. Announced at GTC 2026.
OpenSandbox Yes (Apache-2.0) container Broadest scope of any sandbox — covers evaluation and RL training environments, not just agent sandboxing.
pixels Yes (MIT) container Second Incus-based entry alongside code-on-incus, but distinct differentiators: ZFS snapshot fan-out makes spinning up N task containers from a "ready" base a first-class primitive, and the built-in MCP server fits the "MCP server sandboxing" specialized use case called out in the raised-bar criteria. Has a SECURITY.md with documented threat model.
sand Yes (Apache-2.0) microvm Apple Containerization gives hardware-isolated micro-VMs (Kata-based) on Apple Silicon. APFS clonefile makes workspace clones instant without copying files. eBPF egress filtering is a notable hardening choice for a solo project.
sandcastle Yes (MIT) container Uses Docker containers it creates directly — not delegating to E2B or Daytona. The git branch strategy (agents work on branches, commits merge back) is the differentiator. Useful if you want multi-agent orchestration with isolation included.
scode Yes process Early entry in the space (Sept 2025), motivated by Claude Code's initial lack of built-in sandboxing.
sevorix-lite Yes (AGPL-3.0) seccomp, user-namespace Multi-layered runtime containment rather than VM/container isolation. The "Yellow Lane" human-in-the-loop model with countdown timer is unusual — the agent pauses pending human approval via dashboard. Claude Code support is built in, not bolted on.
skilllite Yes (MIT) seatbelt, user-namespace, seccomp The skilllite-sandbox component is independently usable — you don't have to use the agent engine to get the sandbox. Three-layer defense model (install scan + pre-exec auth + runtime sandbox) is more depth than most standalone tools offer.
warren Yes (MIT) user-namespace Unlike control planes that delegate isolation to a cloud backend, warren ships its own bubblewrap sandbox — the host is unreachable and the control plane talks to the runtime over a unix socket. The differentiator is the governance layer (mid-run steering, sign-off gates, PR-merge-gated serial dispatch) on native isolation. 33 scenario-based acceptance tests; runs on Fly.io.

Kubernetes-Native

Sandbox solutions designed for Kubernetes clusters.

Name OSS? Isolation Notes
Agent Sandbox (kubernetes-sigs) Yes (Apache-2.0) gvisor, kata Official Kubernetes SIG project (launched KubeCon Atlanta Nov 2025). Likely to become the standard for K8s agent sandboxing.
DAM Yes (Apache-2.0) container Brings a credential proxy plus a policy-enforced egress gateway to the Kubernetes tier — most k8s sandbox entries isolate pods but do not proxy credentials. IBM-backed (ibm.biz docs; the bundled "Bob" harness targets IBM workflows). Runs any ACP-compatible harness, not just the bundled ones.
GKE Agent Sandbox No gvisor, kata Managed wrapper around the open-source agent-sandbox project. If you're already on GKE, this is the path of least resistance.
mitos Yes (Apache-2.0) microvm, kvm Distinct from raw Firecracker (already listed): a live copy-on-write fork of a warm, running microVM plus a Kubernetes operator, CRDs, and a KVM device-plugin. Fast memory-snapshot restore suits parallel agent exploration and RL-style environment resets.
openkruise/agents Yes (Apache-2.0) container CNCF-affiliated via OpenKruise (Alibaba). The E2B API compatibility is notable — lets you use existing E2B SDK integrations against self-hosted K8s instead of E2B's cloud. Sandbox hibernation with GPU memory checkpoint is unusual.
sandbox0 Yes (Apache-2.0) container, gvisor The procd process manager inside pods provides REPL session management — unusual for a K8s sandbox. Egress credential injection keeps secrets outside the sandbox boundary, similar to nono's credential proxy model but at the K8s level.
treadstone Yes (Apache-2.0) gvisor Built on kubernetes-sigs/agent-sandbox as the underlying CRD. Browser handoff is an unusual feature — enables smooth transitions from autonomous agent execution to human intervention. Offered both as open source and as a hosted service.

Development Environments

Development environment platforms that can be repurposed for agent isolation. These aren't agent-specific but provide usable isolation out of the box.

Name OSS? Isolation Notes
Coder Yes (AGPL-3.0) container Not agent-specific, but good for teams wanting self-hosted isolation without cloud dependency. AGPL license means modifications must be shared.
DevPod Yes container Not agent-specific. Good open-source alternative to Codespaces for local-first workflows where you want reproducible isolated environments.
GitHub Codespaces No container Not purpose-built for agents, but accessible to anyone familiar with GitHub. A "good enough" isolation option for personal agent use without learning new tools.
klangk Yes (MIT) container, seccomp The only multi-user collaborative sandbox platform in this list — the isolation axis is the per-user workspace (rootless podman), not multiple parallel agents (see LINCE and warren for that). The differentiator is the team-collaboration use case (presence, terminal-sharing, ACLs) on real per-workspace container isolation, not the isolation mechanism itself.
Koyeb No container General-purpose serverless platform, not purpose-built for agents, but usable for agent isolation out of the box with standard container workflows.
Ona (formerly Gitpod) No container Major pivot from Gitpod (rebranded Sept 2025). Demonstrated Claude Code sandbox escape (March 2026). Not agent-specific but increasingly agent-oriented.
sandcat Yes (Apache-2.0) container Transparent full-traffic capture via WireGuard (not per-tool HTTP_PROXY) combined with proxy-level secret substitution brings the credential-proxy pattern — previously VM-tier only in this list (nono) — down to the container tier. Part of VirtusLab's Visdom delivery infrastructure.

Abstraction Layers

SDKs and frameworks that abstract across multiple sandbox providers.

Name OSS? Isolation Notes
agentbox-sdk Yes (MIT) microvm, container Differentiator vs other abstraction-tier entries is heterogeneous-protocol agent transport: each upstream agent is reached via its native protocol rather than CLI-wrapped, so mid-run interactivity, approval flows, and sub-agent orchestration survive being inside a sandbox. ComputeSDK is closed-source and sandbox-only; LangChain Sandboxes is framework-bound; NanoClaw is Claude-only; AgentScope Runtime is Python-only and ships its own agent framework.
AgentScope Runtime Yes (Apache-2.0) container, gvisor Real sandbox depth despite being a runtime framework — pre-built images covering GUI (VNC), browser, and mobile (Android emulator) environments go well beyond typical container sandboxes. Multiple sandbox backends (Docker, gVisor, BoxLite, K8s) abstracted behind a single API.
ComputeSDK No microvm, container Useful if you want to avoid vendor lock-in. Isolation strength depends entirely on the chosen backend provider.
LangChain Sandboxes Yes container Only relevant if already using LangChain. The sandbox capabilities come from the underlying provider, not LangChain itself.
NanoClaw Yes (MIT) container More of an agent orchestration framework with sandbox support than a sandbox itself. High adoption. Sandbox capability comes from Docker or Docker Sandboxes underneath.

Building Blocks

The underlying technologies that sandbox products are built on. Most users interact with these indirectly — this section is for people building their own sandbox infrastructure or evaluating isolation claims.

VM & Container Runtimes

The underlying VM and container runtimes that sandbox products are built on. Use these if you're building your own sandbox infrastructure.

Name OSS? Isolation Notes
Firecracker Yes (Apache-2.0) kvm, microvm The foundation most cloud sandbox platforms build on. Battle-tested at AWS scale (Lambda, Fargate). If you're building a sandbox product, this is likely your starting point.
gVisor Yes (Apache-2.0) gvisor Used by GKE and kubernetes-sigs/agent-sandbox. Good middle ground between container and VM isolation — stronger than containers, lighter than full VMs.
Kata Containers Yes (Apache-2.0) kata, kvm Production-proven at scale via Northflank (2M+ workloads/month). Good for Kubernetes environments that need VM-level isolation per pod.
libkrun Yes (Apache-2.0) kvm macOS support via Apple Virtualization.framework is unique among VM runtimes — Firecracker and Kata are Linux-only. Used by microsandbox.
Zeroboot Yes kvm, microvm 0.8ms sandbox creation via COW forking is remarkable if verified at scale. Worth watching as a potential next-gen approach to sandbox provisioning.

OS-Level Sandboxing

OS-level isolation primitives. These are building blocks — most users interact with them indirectly through higher-level tools.

Name OSS? Isolation Notes
bubblewrap (bwrap) Yes (LGPL-2.0+) user-namespace Years of hardening via Flatpak. Claude Code's Linux sandbox builds on this. The go-to unprivileged sandbox primitive on Linux.
Firejail Yes (GPL-2.0) user-namespace, seccomp Primarily for desktop app sandboxing, but applicable to agent processes. SUID requirement is a trade-off — convenience vs. attack surface.
Landlock LSM Yes (GPL-2.0) landlock The modern Linux answer to unprivileged sandboxing. Network support in kernel 6.7 makes it much more complete. Used by Codex CLI and OpenShell.
Linux Namespaces + cgroups Yes (GPL-2.0) user-namespace Everything in the container and VM space builds on these primitives. Understanding namespaces and cgroups is foundational to evaluating any Linux-based sandbox's isolation claims.
macOS Seatbelt / sandbox-exec No seatbelt Deprecated but still the only game in town for macOS process sandboxing. Used by Claude Code, Agent Safehouse, and srt on macOS. No replacement announced by Apple.
nsjail Yes (Apache-2.0) user-namespace, seccomp Google-maintained. Kafel policy language is more ergonomic than raw seccomp-BPF. Used by competitive programming judges for untrusted code execution.
seccomp-BPF Yes (GPL-2.0) seccomp Building block, not standalone. Almost always used alongside Landlock or namespaces to provide full sandbox coverage.

WebAssembly Runtimes

WebAssembly runtimes providing language-level sandboxing. Architecturally elegant but require compiling tools to Wasm.

Name OSS? Isolation Notes
Pyodide Yes (MPL-2.0) wasm Good for sandboxing Python-only agent code execution where you need browser-grade isolation guarantees without running a VM.
wasmCloud Yes (Apache-2.0) wasm Higher-level than Wasmtime or WasmEdge — it's an application platform, not just a runtime. Useful if building distributed agent systems with Wasm isolation.
WasmEdge Yes (Apache-2.0) wasm CNCF project. Differentiates from Wasmtime with AI/ML inference extensions and edge deployment focus.
Wasmtime Yes (Apache-2.0) wasm The reference Wasm runtime from Bytecode Alliance. Architecturally elegant sandboxing but requires toolchain buy-in — you can't run arbitrary binaries.
Wassette Yes wasm Interesting intersection of MCP and Wasm — agents discover and load sandboxed tools via MCP from OCI registries. Microsoft backing. Released Aug 2025.

References

See references/reading-list.md for blog posts, papers, and discussions on agent sandboxing.

Contributing

To add or update a sandbox entry:

  1. Edit data/sandboxes.yaml — follow the existing schema (all fields documented in the file header)
  2. Run python scripts/generate_readme.py to regenerate the README
  3. Open a PR

The generate script validates the YAML schema and will fail fast on missing required fields or invalid vocabulary values.

See docs/strategy-update-2026-04-25.md for how the landscape is evolving and what we're looking for in new entries.

About

Comprehensive list of sandboxing options for AI agents + detailed sandboxing guide + analysis of AI safety research specific concerns/solutions. nb: intermittent updates post-2026.05

Resources

Readme

License

MIT license
Activity

Stars

3 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

 
 
 

Contributors

Languages