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

# Landscape: AI-agent sandbox tools

A broader survey than [`landscape-containerized-claude.md`](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`](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](https://news.ycombinator.com/item?id=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.