bot-bottle/docs/research/agent-sandbox-landscape.md

Landscape: AI-agent sandbox tools

A broader survey than landscape-containerized-claude.md, which focused on Claude-Code-specific containerizers. This one covers general AI-agent sandbox / containment projects — some Claude-specific, some agent-agnostic, some hosted SaaS — and contrasts them with bot-bottle's design.

Research conducted 2026-05-11. CubeSandbox added 2026-07-18 (see its per-project note and the addendum at the end). Also updated 2026-07-18: bot-bottle no longer uses pipelock — outbound DLP is now bot-bottle's own (deliberately simple) egress scanner (a mitmproxy addon with custom detectors, PRD 0017 / 0053), and git-push secret scanning is handled by gitleaks in the git-gate. "pipelock" below has been replaced with the current mechanism; it survives only in older PRDs as history.

Updated again 2026-07-18: six additional tools added (Cleanroom, container-use, Docker sbx, Anthropic srt, Microsoft AGT, Open Agent Passport); an Agent-tailored policy row added to the comparison table; a separate Governance layers section added for AGT and OAP. See the second addendum at the end.

Summary

Fifteen projects surveyed across two categories: isolation/sandbox tools and governance/pre-action authorization layers (the latter don't provide VM or container isolation but do per-agent policy enforcement at the tool-call level). None duplicate bot-bottle's combination of local VM-per-bottle isolation, a declarative per-role manifest, per-agent egress allowlist + outbound-content DLP, bottle/agent split, and the composable extends: policy model. Three clusters stand out:

• Closest neighbours — agent-safehouse and litterbox: local, single-user, thin wrappers over an existing OS primitive (sandbox-exec, Podman + Landlock).
• Different category (isolation) — tilde.run (hosted SaaS), boxlite and microsandbox (microVM libraries for platform builders), CubeSandbox (self-hosted multi-tenant microVM service), endo-familiar (capability-security paradigm, no OS isolation).
• New: governance/pre-action layers — Microsoft AGT and Open Agent Passport (OAP): framework-embedded tool-call interceptors with per-agent declarative policy. Closest competitors on agent-tailored policy, but operate at the tool-call level rather than providing network/filesystem isolation; they complement rather than substitute.

The microVM cluster (matchlock, smolmachines, boxlite, microsandbox, CubeSandbox) is the most relevant for the v2 isolation discussion in stronger-isolation-alternatives.md: libkrun and Apple's Virtualization.framework have made local microVMs ergonomic enough that microVMs are now bot-bottle's default backend (Firecracker on KVM Linux, Apple Container on macOS), with Docker kept only as a legacy fallback for CI / hosts without KVM or Apple Container. That discussion has since shipped, not just been theorized.

The one that matters most for positioning is CubeSandbox — it is the first surveyed project to ship bot-bottle's would-be wedge (default-deny egress allowlist + full audit logs + in-flight credential custody so keys never enter the sandbox) combined with per-sandbox microVM isolation, open-source under Apache 2.0, with Tencent Cloud behind it and 10.4k stars. It's a self-hosted multi-tenant service for platform builders, not a single-user declarative tool, so it doesn't collide head-on — but it narrows the "nobody else bundles egress custody + credential injection" claim that the monetization positioning leans on. See the addendum.

Per-project notes

endo-familiar

• Source: https://dcfoundation.io/containing-ai-agents-the-endo-familiar-demo/ ; https://github.com/endojs/endo
• License: Apache 2.0
• Isolation: Object-capability runtime in Hardened JavaScript. Not OS-level — agents simply cannot reference resources they were not handed.
• Locality: Local / decentralized; WebSocket relay for capability sharing across machines.
• Agent integration: Agent-agnostic, demo only.
• Config: Programmatic capability passing; "pet name" system for human-readable capability handles.
• Network policy: Capability model is the policy; no allowlist or firewall.
• Maturity: Research demo, Foresight Institute grant. Production use of endo is via Agoric and MetaMask, not as a containment tool.

litterbox

• Source: https://litterbox.work/ ; https://github.com/Gerharddc/litterbox
• License: Apache 2.0 (~66 stars)
• Isolation: Podman container on Linux + Wayland socket forwarding; optional Landlock LSM for filesystem restriction.
• Locality: Local, Linux only.
• Agent integration: Generic dev sandbox; works with any agent that runs inside the container.
• Config: Interactive CLI wizard — define (Dockerfile template), build (prompts), start (launch).
• Network policy: "Limited isolation by default" — no strict allowlist documented.
• Notable: Per-key SSH agent confirmation dialogs.
• Maturity: Early-stage, ~66 stars.

agent-safehouse

• Source: https://agent-safehouse.dev/ ; https://github.com/eugene1g/agent-safehouse
• License: Apache 2.0 (~1,400 stars)
• Isolation: macOS sandbox-exec (Seatbelt) profiles — kernel-level syscall interception, no container.
• Locality: Local, macOS only.
• Agent integration: Explicit multi-agent wrapper — Claude Code, OpenAI Codex, Gemini CLI, Cline, Aider. Usage: safehouse claude --dangerously-skip-permissions.
• Config: Shell functions or custom sandbox-exec profile files; LLM-assisted profile generation supported.
• Network policy: Not addressed.
• Maturity: Active through March 2026.

matchlock

• Source: https://github.com/jingkaihe/matchlock
• License: MIT (~574 stars, v0.2.10)
• Isolation: MicroVMs — Firecracker on Linux, Apple Virtualization.framework on macOS. Transparent proxy via nftables DNAT (Linux) or gVisor userspace TCP/IP (macOS).
• Locality: Local (Homebrew, .deb, .rpm).
• Agent integration: Agent-agnostic; SDK examples for Anthropic Claude API and OpenAI. Go, Python, TypeScript SDKs.
• Config: CLI flags (--allow-host, --secret, --no-network) or SDK builder pattern. No manifest file.
• Network policy: Default-deny + per-host allowlist.
• Notable: Secrets injected in-flight by the host proxy — they never enter the VM.
• Maturity: Marked experimental.

tilde.run

• Source: https://tilde.run/
• License: Proprietary, hosted SaaS.
• Isolation: Cloud-hosted containers; underlying mechanism not publicly stated (unverified whether OCI containers or microVMs).
• Locality: Hosted only.
• Agent integration: Claude orchestration explicit; CLI (tilde exec) and Python SDK; plain-English agent instructions.
• Config: DSL for RBAC policies (allow / deny / require human approval per action, per repo, per agent).
• Network policy: Default-deny with per-request logging; cloud metadata endpoints and private networks blocked.
• Persistence: All changes versioned and rollback-able via lakeFS; atomic commits per run.
• Maturity: Private preview, © 2025, built by the lakeFS team.

boxlite

• Source: https://boxlite.ai/ ; https://github.com/boxlite-ai/boxlite
• License: Apache 2.0 (~4,700 stars, YC-backed)
• Isolation: MicroVMs with dedicated Linux kernel per box — KVM on Linux, Hypervisor.framework on macOS. Not containers/namespaces.
• Locality: Local, no daemon.
• Agent integration: Explicitly targets AI agents; MCP server companion (boxlite-ai/boxlite-mcp). Pivoted from dev environments in 2025.
• Config: SDK only — Python, Node.js, Rust, C; Go pending. No declarative manifest.
• Network policy: "Isolated Network per VM" — details not public (unverified).
• Notable: Sub-50ms boot, snapshot / fork / clone of VM state. Self description: "the SQLite of sandboxing".
• Maturity: Active, YC.

microsandbox

• Source: https://github.com/microsandbox/microsandbox (the superradcompany/microsandbox URL redirects to the same project).
• License: Apache 2.0 (~6,000 stars, YC-backed)
• Isolation: MicroVMs via libkrun, OCI-compatible images. Sub-100ms boot, rootless, no daemon, embeddable as a library.
• Locality: Local.
• Agent integration: Explicit Claude Code + Cursor targeting via "Agent Skills" packages and an MCP server. Agents can create their own sandboxes programmatically.
• Config: CLI (msb), SDKs (Rust, Python, TypeScript), MCP server.
• Network policy: Not detailed in public docs.
• Maturity: Beta, breaking changes expected; most-starred project in this set.

smolmachines

• Source: https://smolmachines.com/ ; https://github.com/smol-machines/smolvm
• License: Apache 2.0 (~3,100 stars)
• Isolation: MicroVMs via libkrun — Hypervisor.framework on macOS, KVM on Linux. No shared kernel.
• Locality: Local, no daemon.
• Agent integration: Includes an AGENTS.md; designed with coding agents in mind but no MCP/Skills turnkey integration.
• Config: TOML Smolfiles declaring image, networking, volumes, SSH agent access, GPU acceleration. Portable .smolmachine files.
• Network policy: Off by default; per-host allowlist via --allow-host.
• Persistence: Named machines persistent by default; ephemeral runs also supported.
• Maturity: Active through April 2026.

CubeSandbox (added 2026-07-18)

• Source: https://github.com/TencentCloud/CubeSandbox ; HN launch https://news.ycombinator.com/item?id=47863430
• License: Apache 2.0 (~10.4k stars). By Tencent Cloud; described as "battle-tested, production-ready" infra already running in Tencent Cloud. Rust / Go / C.
• Isolation: MicroVMs via RustVMM + KVM — "each sandbox gets its own Guest OS kernel, no Docker shared-kernel escapes." Hardware-level isolation, dedicated kernel per instance.
• Locality: Self-hosted, but server/cluster-oriented, not a single-user local CLI. Deploy guides target PVM cloud VMs, bare metal, and dev. A single 96-vCPU host is claimed to run 2,000+ concurrent sandboxes.
• Agent integration: Drop-in E2B SDK replacement (single env-var change) — the headline compatibility claim. OpenClaw assistant integration; general LLM-code execution. Aimed at platform builders, not one developer's laptop.
• Config: Programmatic via the E2B-compatible SDK. No declarative manifest.
• Network policy: This is the striking part — domain allowlists, instant block on unauthorized egress, full audit logs, per-sandbox traffic tokens, policy-routing egress, enforced by an eBPF-based virtual switch giving kernel-level network isolation. Closest match yet to bot-bottle's own default-deny + per-bottle allowlist egress model.
• Credentials: Credential vault — agents call external APIs / LLMs while "keys never enter the sandbox, model context, or logs." Same in-flight-injection idea as matchlock, but productized as a vault.
• Performance: <60ms cold start (claimed 2.5–50× faster than alternatives), <5MB memory per instance; millisecond snapshot rollback is upcoming.
• Maturity: Open-sourced July 2026 off production Tencent Cloud use; most-starred project in this set (~10.4k).

Cleanroom (added 2026-07-18)

• Source: https://github.com/buildkite/cleanroom
• License: Apache 2.0
• Isolation: MicroVM — Firecracker on Linux, Virtualization.framework on macOS. Digest-pinned OCI images.
• Locality: Self-hosted server (CI-oriented).
• Agent integration: Generic process sandbox; CI-first, not a Claude/agent wrapper.
• Config: cleanroom.yaml in the repo being sandboxed defines egress rules, resources, and network policy. Cleanroom resolves this from the commit being run.
• Network policy: Default-deny + per-repo hostname allowlist (resolved from DNS answers + destination IP:port). Co-hosted services on the same IP:port are not distinguished. OIDC-backed auth for remote servers.
• Credentials: Host-side only; not injected in-flight but not present in the VM.
• Notable: Policy lives in the repo being sandboxed, not in an agent-role definition — closer to per-repo scoping than per-role. Supports Docker-inside-sandbox (services.docker.required: true), OIDC authorization, suspend/resume lifecycle.
• Maturity: Active Buildkite product.

container-use (added 2026-07-18)

• Source: https://github.com/dagger/container-use
• License: Apache 2.0
• Isolation: Docker container per agent + git worktree per agent. Containers share the host kernel; stronger than bare host but weaker than microVM.
• Locality: Local.
• Agent integration: MCP stdio server — Claude Code, Cursor, Windsurf. claude mcp add container-use -- container-use stdio.
• Config: None for security policy. Environments are provisioned on demand; no allowlist or credential config.
• Network policy: Not addressed.
• Notable: Per-agent git branches (container-use/<env_name>); parallel agents without filesystem conflict; real-time log visibility and terminal attach for intervention; git-based review workflow. Oriented toward parallel development safety, not security containment.
• Maturity: Early development, active.

Docker sbx (added 2026-07-18)

• Source: Docker proprietary (sbx CLI, separate from docker).
• License: Proprietary.
• Isolation: MicroVM (Docker's own implementation) — each session gets its own kernel, Docker daemon inside the VM, and filesystem.
• Locality: Local (macOS and Windows; does not require Docker Desktop).
• Agent integration: Explicit wrapper — Claude Code, Codex, Gemini CLI, Copilot CLI, Kiro. Launches agent inside the VM with --dangerously-skip-permissions by default.
• Config: Open / Balanced / Locked Down network presets at launch. No per-role manifest.
• Network policy: Default-deny; preset levels control strictness. TUI dashboard shows a live log of every outbound connection (allowed and blocked) with point-and-click allow/block for hosts.
• Credentials: OS keychain + host-side proxy injection — API keys never enter the VM.
• Notable: Best DX among microVM tools (one command, works like native yolo Claude but inside a VM); branch mode creates a git worktree in .sbx/. Network policy is preset-based, not role-declarative.
• Maturity: GA 2026.

Anthropic srt (added 2026-07-18)

• Source: https://github.com/anthropic-experimental/sandbox-runtime (@anthropic-ai/sandbox-runtime on npm, sandbox-runtime on PyPI)
• License: Apache 2.0 (experimental).
• Isolation: OS-level only — Seatbelt (sandbox-exec) on macOS, bubblewrap on Linux, WFP (Windows Filtering Platform) account-fenced on Windows. No container or VM. Lowest overhead in the set.
• Locality: Local.
• Agent integration: Claude Code's sandboxed bash tool uses this internally. Can wrap any arbitrary process (srt <command>). Cloud Claude Code sessions use full microVMs instead.
• Config: Programmatic per-invocation — allow/deny path lists for filesystem; allow/denylist for network (HTTP proxy + SOCKS5).
• Network policy: Proxy-based filtering (HTTP + SOCKS5); domain allowlist/denylist enforced at proxy layer. Custom proxy supported (e.g. mitmproxy for inspection + audit). Processes that ignore proxy env vars may bypass filtering on some platforms.
• Notable: Cross-platform (macOS/Linux/Windows); wraps any process, not just agents; no role/manifest concept. Annotated as a research preview — APIs may change.
• Maturity: Early research preview.

Governance / pre-action authorization layers

These two tools don't provide VM or filesystem isolation; they intercept tool calls before execution and evaluate them against a per-agent declarative policy. They are the closest competitors on agent-tailored policy and complement isolation sandboxes rather than substituting for them.

Microsoft Agent Governance Toolkit (AGT) (added 2026-07-18)

• Source: https://github.com/microsoft/agent-governance-toolkit
• License: MIT (~3.3k stars, open-sourced April 2, 2026).
• Isolation: None (OS/VM). Execution rings (0–3, inspired by CPU privilege levels) control what an agent can do at the framework layer. MCP security gateway treats MCP traffic as an untrusted boundary.
• Locality: Embedded in the agent framework (Python, TypeScript, .NET, Rust, Go; 20+ framework adapters).
• Agent integration: Framework-agnostic. Plugs into Semantic Kernel, AutoGen, and others as a middleware layer.
• Config: YAML policy per agent — tools can be allowed, denied, sandboxed, or routed through an approval step. Every action passes through a governance gate checking: agent DID, trust score, risk tier, requested tool, action type, and policy rules.
• Network policy: Not directly — operates at tool-call level.
• Credentials: Per-agent DID (Ed25519 decentralized identifier); agent does not borrow a human's credentials.
• Notable: Dynamic trust score (0–1,000, behavioral decay) — privilege follows observed behaviour, not just provisioning. Covers all 10 OWASP Agentic Top 10 risks. Kill switch + SLO monitoring. Sub-ms policy enforcement.
• Maturity: MIT, ~3.3k ⭐, v3.7.0 May 2026.

Open Agent Passport (OAP) (added 2026-07-18)

• Source: https://github.com/aporthq/aport-spec ; spec at https://api.aport.io/spec/spec/oap/oap-spec.md/ ; arXiv 2603.20953
• License: Open specification.
• Isolation: None. Pre-action hook only — intercepts tool calls synchronously before execution, evaluates against a cloud-registry declarative policy, fails closed.
• Locality: Local hook + cloud policy registry.
• Agent integration: Framework-agnostic; hook pattern.
• Config: Declarative policy rules in a cloud registry (evaluated in order; first failing rule denies). Ed25519-signed, hash-chained audit records per decision.
• Network policy: Not directly.
• Notable: 53ms median authorization decision (N=1,000). In an adversarial testbed ($5,000 bounty, 1,151 sessions), social engineering succeeded 74.6% of the time under a permissive policy; under a restrictive OAP policy, 0% success across 879 attempts. Assumes framework runtime is not compromised.
• Maturity: Specification + reference implementation, 2026.

Comparison table

Isolation/sandbox tools only. AGT and OAP are governance layers — see their per-project notes above.

Axis	bot-bottle	endo-familiar	litterbox	agent-safehouse	matchlock	tilde.run	boxlite	microsandbox	smolmachines	CubeSandbox	Cleanroom	container-use	Docker sbx	Anthropic srt
Isolation	MicroVM per bottle default (Firecracker/KVM on Linux, Apple Container on macOS) + own egress DLP scanner; Docker legacy fallback, gVisor there if present	Object-capability (no OS isolation)	Podman + opt. Landlock	macOS sandbox-exec	MicroVM (Firecracker / Virt.fw)	Hosted container (unverified)	MicroVM (KVM / Hypervisor.fw)	MicroVM (libkrun)	MicroVM (libkrun / KVM)	MicroVM (RustVMM / KVM)	MicroVM (Firecracker / Virt.fw)	Docker container + git worktree	MicroVM (proprietary)	OS-level (Seatbelt / bubblewrap / WFP) — no container
Local vs hosted	Local	Local	Local (Linux)	Local (macOS)	Local	Hosted SaaS	Local	Local	Local	Self-hosted (server/cluster)	Self-hosted server	Local	Local	Local
Open source	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0	MIT	No	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0	Proprietary	Apache 2.0 (experimental)
Agent target	Claude Code	Generic (demo)	Generic	Multi-agent wrapper	Generic (+ Claude/OpenAI SDKs)	Claude focus	Generic	Claude + Cursor (MCP/Skills)	Generic (AGENTS.md)	E2B-compatible (platform builders)	CI / generic process	Claude Code, Cursor, Windsurf (MCP)	Claude Code, Codex, Gemini CLI, Copilot, Kiro	Claude Code (and any process)
Network policy	Default-deny via own egress scanner + per-bottle allowlist + content DLP + gitleaks on git push	Capability model only	Limited	Not addressed	Default-deny + allowlist + secret-injecting proxy	Default-deny + logging	Per-VM net (unverified)	Not documented	Off by default + allowlist	Default-deny allowlist + instant egress block + audit logs + per-sandbox tokens (eBPF) + credential vault	Default-deny + per-repo host allowlist (cleanroom.yaml)	Not addressed	Default-deny; Open / Balanced / Locked Down presets; live TUI network panel	Proxy-based allowlist/denylist (HTTP + SOCKS5); custom proxy supported
Parallel agents	Yes (one bottle per agent)	n/a	Not addressed	One at a time	Multiple VMs	Yes (dashboard)	SDK-level	SDK-level	Architectural	Yes (2,000+/host claimed)	Yes (server model)	Yes (per-agent containers + worktrees)	Yes	Yes
Long-running posture	Persistent by default (named, supervised)	n/a (demo)	Session (up while in use)	Per-invocation	Ephemeral VM per run	Per-run (versioned)	Ephemeral + snapshot/fork	Ephemeral / on-demand	Named persistent by default	Ephemeral + auto pause/resume	Per-run + suspend/resume	Per-agent container (ephemeral)	Per-session; branch mode creates git worktree in .sbx/	Per-invocation
DX: run Claude yolo-style	One command → interactive yolo Claude (start <agent>, --dangerously-skip-permissions default)	n/a (lib demo)	Wizard + build, then run claude inside (Linux only)	One-command wrapper (safehouse claude --dangerously-skip-permissions)	CLI: run a cmd in a VM (not a Claude wrapper)	Hosted (tilde exec), not local-native	SDK code required (build the run yourself)	CLI/MCP: sandbox-as-a-tool for the agent, not a wrapper around it	SSH into a named machine, run claude there	Stand up a cluster + drive via E2B SDK	CI-oriented, not a Claude wrapper	MCP server: claude mcp add container-use -- container-use stdio	One command: sbx wraps claude with --dangerously-skip-permissions default	Library/wrapper, not a standalone CLI
Config	JSON manifest (bottles + agents)	Programmatic refs	CLI wizard	Profile files / shell fns	CLI / SDK	DSL + CLI + SDK	SDK	CLI / SDK / MCP	TOML Smolfile	E2B-compatible SDK	cleanroom.yaml in repo	None (no policy config)	Preset levels at launch	Programmatic per-invocation (allow/deny lists)
Agent-tailored policy	Yes — bottle/agent split; declarative per-role egress + credentials; composable via extends:	Partial — capability model scopes per-agent, but no declarative role manifest	No	Partial — per-agent profile files (Seatbelt); no egress	No	Yes — per-agent DSL RBAC (allow/deny/approve per action/repo/agent)	No	No	No	No — per-sandbox SDK config, not role-scoped	Partial — per-repo cleanroom.yaml, not per-role	No	No — network presets only	No
Maturity	Active July 2026	Research (2022+)	Early (~66 ⭐)	Active (~1.4k ⭐)	Experimental (~574 ⭐)	Private preview	YC, ~4.7k ⭐	YC, ~6k ⭐, beta	~3.1k ⭐	Tencent, prod, ~10.4k ⭐	Active (Buildkite product)	Early development	GA 2026	Early research preview

What's closest, what's different

Closest in design and scope. agent-safehouse and litterbox sit nearest bot-bottle: local, single-user, thin wrappers over an existing OS primitive, low-dep. The split is the isolation primitive — bot-bottle now defaults to a VM per bottle (Firecracker microVM on KVM Linux, Apple Container on macOS) with its own DLP-scanning egress proxy, keeping Docker only as a legacy fallback; agent-safehouse uses sandbox-exec; litterbox uses Podman + Landlock. matchlock and smolmachines are close on both the policy side (default-deny net, per-host allowlist) and — now that bot-bottle has moved off containers-by-default — the microVM isolation primitive.

New closest on agent-tailored policy. Two governance tools are the direct competitors on the "coarse-grained sandbox" axis. tilde.run has had per-agent DSL RBAC since its launch (though it's hosted SaaS). Microsoft AGT is the most serious new entrant: per-agent DID identity, YAML policy that can allow/deny/sandbox/approve individual tool calls per agent, and a dynamic behavioural trust score. It operates at the framework tool-call layer, not the network layer — so it's complementary to bot-bottle's network/filesystem isolation rather than a direct substitute, but on the "does this sandbox know what this agent is for?" question it is the most complete answer in the field. OAP's pre-action hook pattern achieves similar goals with cryptographic audit and a 0% adversarial-attack success rate under a restrictive policy.

New closest on DX. Docker sbx is the first tool in this set that matches bot-bottle on the "one command, dangerously-skip-permissions safe by default" DX bar, at microVM isolation strength, with host-side credential injection. It is proprietary, preset-based (not role- declarative), and cloud-agent-specific, but it directly competes on the UX proposition. agent-safehouse was the previous DX peer; Docker sbx materially raises the bar.

New closest on repo-scoped policy. Cleanroom (Buildkite) is the first tool to combine microVM isolation with a declarative egress policy file — though the policy lives in the repo being sandboxed (cleanroom.yaml), not in an agent-role manifest. That makes it per- repo rather than per-role: the same Cleanroom config applies to any agent running in that repo. The distinction matters for bot-bottle's use case (one developer running multiple agent roles with different egress footprints), but for CI/CD use cases Cleanroom is a direct alternative.

Solving a different problem. tilde.run is hosted SaaS for team / production agent pipelines with data-versioned rollback — explicitly opposite to bot-bottle's "infrastructure I control" goal. boxlite, microsandbox, and CubeSandbox are infrastructure libraries/services aimed at platform builders embedding sandboxes into agent frameworks; they would be a backend bot-bottle could call, not a competitor to its manifest layer. endo-familiar is in a different paradigm entirely: capability passing rather than kernel boundaries.

Borrowable ideas

What bot-bottle already has that the survey suggested as differentiators:

• Default-deny egress with a per-agent allowlist (own egress scanner).
• DLP scanning of outbound traffic.
• Bottle / agent split (manifest layer above the isolation primitive).
• gVisor auto-detection on Linux.

Ideas worth considering, without abandoning the Python-stdlib-first / local, single-operator stance:

1. Per-use SSH key confirmation (from litterbox). Even with KnownHostKey pinning and the egress DLP scanner, a wrapper SSH agent that prompts on each key use (e.g. via osascript / notify-send) would catch an agent doing something off-policy with a key it legitimately holds. Pure-stdlib, no new deps.
2. In-flight secret injection (from matchlock). The egress scanner already does allowlisting and DLP; teaching it to inject tokens at proxy time so e.g. GITEA_TOKEN never appears in the container's env would close the "agent reads its own env and exfiltrates" path. Fits the existing egress-proxy architecture.
3. MicroVM backend — on the radar shipped since this survey. microVMs are now bot-bottle's default (Firecracker on KVM Linux, Apple Container on macOS); Docker is the legacy fallback. The libkrun / Apple Virtualization.framework ergonomics that microsandbox, smolmachines, and matchlock demonstrated turned out to be enough to make it the default rather than an opt-in.

Not worth borrowing: the SDK-first programmatic API style of boxlite / microsandbox (cuts against the declarative-manifest stance), and the hosted-SaaS dashboard model of tilde.run (cuts against the "infrastructure I control" goal).

Caveats

• Star counts and last-commit dates are point-in-time snapshots.
• Several projects' network and persistence behaviour is not documented publicly; items so derived are marked (unverified).
• The superradcompany/microsandbox URL in the original prompt redirects to microsandbox/microsandbox; the surveyed project is the same.
• CubeSandbox performance/scale numbers (<60ms cold start, <5MB/instance, 2,000+ sandboxes per 96-vCPU host) are the project's own launch claims, not independently verified here.

Addendum 2026-07-18 — CubeSandbox and the positioning read

CubeSandbox (Tencent Cloud, Apache 2.0, ~10.4k stars, HN launch #47863430) is the first project in this survey to combine, in one open-source stack, everything bot-bottle treated as its differentiator:

• Egress custody (connection level) — default-deny domain allowlist (L7 domain/SNI filtering), instant block on unauthorized egress, per-sandbox traffic tokens, full audit logs of destinations (eBPF virtual switch, "CubeVS"). This matches bot-bottle's egress scanner at the connection level, productized — see the one thing it does not match, below.
• Credential custody — a vault where keys "never enter the sandbox, model context, or logs." This is the in-flight-injection idea from matchlock, but as a first-class feature, and it's exactly the cross-vendor "egress audit + custody" wedge the monetization positioning treats as the one defensible moat.
• Isolation on par with bot-bottle's current default — a dedicated guest kernel per sandbox (RustVMM/KVM). bot-bottle now defaults to the same class of boundary (Firecracker microVM / Apple Container), so this is parity, not an edge; CubeSandbox's remaining edge is running that per-kernel isolation multi-tenant at scale on one host.

The one axis CubeSandbox does not cover — and where bot-bottle stays distinctive:

• Content DLP on authorized channels. CubeSandbox's egress control is connection-level: it decides whether a destination is allowed and logs it, and its vault keeps injected credentials out of the sandbox entirely. Neither inspects the payload of traffic to an allowed destination. So an agent that exfiltrates over a permitted channel — pasting a repo's contents, an agent-derived secret, or PHI into an allowed API/domain — is not caught by CubeSandbox. bot-bottle's own egress DLP scanner does scan that: response + websocket content against the resolved per-flow config, with per-bottle token redaction (see recent egress commits). The vault approach is arguably stronger for the specific case of pre-known injected credentials (they can't leak if they were never present), but it is not a substitute for content inspection of everything else.

Long-running posture — a sharper axis than raw isolation. E2B and CubeSandbox are ephemeral-per-task by design; a long-running agent is an architected pattern on top, not the default. E2B: 5-minute default timeout, continuous runtime tier-capped (~1h Hobby / ~24h Pro), duration achieved via pause/resume (preserves filesystem + memory + processes; reconnect by sandbox ID via Sandbox.connect(); resume resets the timeout to 5 min; auto-pause via on_timeout: "pause"). CubeSandbox mirrors this (E2B drop-in) with first-class auto pause/resume and hundred-ms checkpoint/fork — and, self-hosted, sets its own timeout policy with no vendor tier caps. bot-bottle inverts the model: a bottle is persistent, named, and supervised by default — long-running is the default, not a session-management loop over pause/resume. smolmachines is the other persistent-by-default project in this set. For anyone building agents that run for hours/days, this posture difference matters more than the isolation primitive.

DX — the "run Claude yolo-style" bar. The reason claude --dangerously-skip-permissions is so widely used is DX: it's one command and the agent just goes. The bottle thesis is to make a sandboxed run that easy — start <agent> builds the image on first run and drops you into an interactive Claude session that already has --dangerously-skip-permissions on by default (contrib/claude/agent_provider.py), with the sandbox as the guardrail instead of per-action prompts. On this axis the field splits cleanly:

• Wrappers around the agent (as-easy-as-native): bot-bottle and agent-safehouse (safehouse claude --dangerously-skip-permissions). These are the run-Claude experience. agent-safehouse is the real DX peer — but it's macOS-only Seatbelt, single-run, and doesn't address network egress; bot-bottle adds VM-grade isolation, egress DLP, and persistent/parallel bottles across macOS + Linux.
• Libraries / services (you build the run yourself): boxlite, microsandbox, CubeSandbox, E2B. These hand you an SDK or a cluster and expect you to wire the agent in — powerful for platform builders, heavyweight for "just run Claude on my laptop." microsandbox's MCP/Skills angle is sandbox-as-a-tool the agent calls, which is the inverse of wrapping the agent.
• In between: litterbox (wizard + build, Linux only), smolmachines (SSH into a named machine), matchlock (run a command in a VM).

So DX is a genuine bot-bottle differentiator, and the only project that matches it (agent-safehouse) does so with materially weaker isolation and no egress story. "As easy as native yolo, but actually sandboxed" is a defensible one-liner.

Why it still doesn't collide head-on:

1. Shape. CubeSandbox is a multi-tenant service for platform builders (drop-in E2B replacement, SDK-driven, 2,000 sandboxes on a box). bot-bottle is a single-operator, declarative-manifest tool for the infrastructure I run. Different buyer, different ergonomics — no JSON manifest, no bottle/agent split, no "one command on my laptop."
2. Backend, not competitor. Like boxlite/microsandbox, CubeSandbox is something bot-bottle could sit on top of — a "runtime": "microvm" or "runtime": "cubesandbox" backend under the manifest layer — while keeping the manifest, the bottle/agent split, and the local, single-operator default.

Why it matters anyway:

• The "nobody else bundles connection-level egress allowlist + audit + in-flight credential custody" line is no longer true for the primitive — a well-funded, 10k-star open-source project now ships it. But content DLP on authorized channels is still not matched (see above), and neither is the layer above the primitive (declarative manifest, cross-vendor orchestration, operator UX, the phone-control/dashboard north star). Those two — outbound-payload DLP and the orchestration layer — are where the defensible ground now sits; the connection-level allowlist + vault mechanism, on its own, is no longer differentiating. Revisit the monetization open/paid line with that in mind.
• Worth a closer look at how CubeSandbox does credential injection and per-sandbox egress tokens (eBPF virtual switch vs. bot-bottle's mitmproxy egress proxy) before the next iteration of bot-bottle's in-flight-secret feature — see borrowable idea #2 above.

Addendum 2026-07-18 (second pass) — agent-tailored policy landscape

The second-pass question was: how novel is bot-bottle's per-agent, role-tailored sandbox relative to the expanded field?

The short answer: on the isolation + network + role-tailoring combination, bot-bottle remains the only tool in this set. On role-tailored policy at the tool-call level, Microsoft AGT and OAP are the most complete answers, but they don't provide isolation; they complement rather than substitute.

The competitive picture by axis:

• Agent-tailored egress (declarative, per-role) — bot-bottle and tilde.run. Cleanroom is per-repo, not per-role. Everyone else is per-session or not addressed.
• Agent-tailored tool-call policy (declarative, per-agent identity) — Microsoft AGT (YAML policy + DID identity + trust score), OAP (declarative policy rules + cryptographic audit). Neither provides network/filesystem isolation.
• Composable policy (role overlays) — bot-bottle (extends:). No other tool surveyed supports composable role-policy inheritance.
• Isolation + DX (one-command safe yolo) — bot-bottle and Docker sbx. Docker sbx is proprietary, preset-based, and cloud-agent-specific; it's the first DX-class competitor at microVM isolation strength.

What the HN "coarse-grained" complaint maps to: The complaint is that a VM isolates the filesystem but doesn't know if the agent should be sending an email. bot-bottle's bottle/agent split is a structural answer to this: the bottle manifest declares exactly what the role can reach, and the sandbox enforces it at the network layer. Microsoft AGT is the most complete answer at the semantic/tool-call layer. The gap both leave open is intent classification — knowing whether a permitted action is consistent with the agent's actual task. See hn-agent-safety-discourse-july-2026.md for the blast-radius analysis.

Borrowable from new tools:

• Microsoft AGT's trust-score decay — privilege that reflects observed behaviour rather than static provisioning. Applied to bot-bottle: a bottle that has triggered DLP alerts or supervise holds could auto-downgrade its network preset, or flag the session for closer review. Fits the existing supervise-server architecture.
• Docker sbx's live network TUI — real-time per-session view of allowed and blocked outbound connections with point-and-click allow/block. cli.py supervise is the right surface; adding a live-connections panel would directly address the "I can't see what the agent is doing" gap without any backend changes.
• OAP's cryptographic audit chain — Ed25519-signed, hash-chained audit records. Currently bot-bottle logs egress decisions but doesn't chain them. A tamper-evident audit record per session would be useful for the compliance use case the CubeSandbox positioning targets.