From a6e1aebda1f73dd7b0d8ec27b7de6a2d943f8b22 Mon Sep 17 00:00:00 2001 From: codex Date: Mon, 27 Jul 2026 03:44:41 +0000 Subject: [PATCH] docs: update agent sandbox competitor landscape --- docs/research/agent-sandbox-landscape.md | 301 ++++++++++++++++++++++- 1 file changed, 293 insertions(+), 8 deletions(-) diff --git a/docs/research/agent-sandbox-landscape.md b/docs/research/agent-sandbox-landscape.md index 5e8abd91..a05b0b4d 100644 --- a/docs/research/agent-sandbox-landscape.md +++ b/docs/research/agent-sandbox-landscape.md @@ -32,9 +32,17 @@ not a principled scope exclusion: both are major hosted sandbox platforms and belong in this landscape even though they target platform builders rather than bot-bottle's local single-operator workflow. +Updated 2026-07-27 after a scan of recent Show HN launches: **Black LLAB, +Eve, CloudRouter, Nucleus, yolo-cage, and Sandbox Agent SDK** added as a +dated entrant cohort. They sharpen the comparison on three axes the original +table underweighted: the browser/preview loop, parallel-agent operator UX, and +a provider-neutral automation/session API. + ## Summary -The main table compares bot-bottle against fifteen isolation/sandbox tools. +The main table compares bot-bottle against fifteen canonical +isolation/sandbox tools; a later section evaluates six recent HN entrants +without widening an already unwieldy table. Governance/pre-action authorization and credential-only layers are covered separately because they don't provide VM or container isolation. None duplicate bot-bottle's combination of local @@ -542,6 +550,199 @@ them. framework runtime is not compromised. - **Maturity**: Specification + reference implementation, 2026. +## Recent HN entrants (added 2026-07-27) + +These are grouped by launch date rather than promoted into the main table. +Several are young or sparsely documented, and putting them beside mature +runtime platforms with false precision would obscure the useful comparison. +The HN launch posts are the evidence snapshot; feature claims should be +rechecked against their repositories before relying on them for a security +decision. + +### Black LLAB + +- **Source**: https://github.com/isaacdear/black-llab ; + HN launch https://news.ycombinator.com/item?id=47402394 +- **Isolation/locality**: Local Docker environment, with an isolated container + created for each agent task. Shared host kernel; no stronger boundary is + claimed. +- **Agent integration**: General local/cloud model workspace. Its headline is + dynamic routing of simple prompts to local models and complex prompts to + hosted models, with code execution and web scraping inside the task + container. +- **Network/credentials**: No default-deny egress, payload inspection, or + host-side credential injection documented in the launch. +- **Competitive read**: Superficial overlap ("a container per agent task"), + but not a direct security-policy competitor. Its useful challenge is the + integrated model-selection UX, which bot-bottle intentionally leaves to the + selected agent provider. +- **Maturity**: Early solo project; HN launch received 1 point. + +### Eve + +- **Source**: https://eve.new/ ; + HN launch https://news.ycombinator.com/item?id=47721255 +- **Isolation/locality**: Managed, hosted Linux sandbox per user/session + (claimed 2 vCPU, 4 GB RAM, 10 GB disk), with filesystem, code execution, + headless Chromium, and service connectors. +- **Agent integration**: End-user OpenClaw-style agent product. An orchestrator + routes subtasks to specialist models and can run parallel subagents that + coordinate through a shared filesystem. Web UI and iMessage are primary + interaction surfaces. +- **Network/credentials**: Broad connectors are a product feature; the launch + does not document bot-bottle-style default-deny route policy, content DLP, + or credentials held outside the sandbox. +- **Competitive read**: Adjacent, not direct. Eve sells a managed colleague; + bot-bottle lets an operator run existing coding-agent CLIs under local + containment. Eve nevertheless demonstrates the appeal of background work, + live progress, browser capability, and mobile notification. +- **Maturity**: Commercial hosted product; HN launch received 71 points and + 39 comments. + +### CloudRouter + +- **Source**: https://github.com/manaflow-ai/manaflow/tree/main/packages/cloudrouter ; + HN launch https://news.ycombinator.com/item?id=47006393 +- **Isolation/locality**: Claude Code or Codex runs locally and provisions + remote cloud VMs/GPUs for execution. Project files are uploaded to the VM; + each machine exposes auth-protected VNC, VS Code, and Jupyter surfaces. +- **Agent integration**: A skill plus CLI lets the coding agent itself start, + command, inspect, and tear down machines. Browser automation is integrated, + including snapshots and screenshots. Parallel disposable compute is the + central workflow. +- **Network/credentials**: The launch emphasizes remote resource isolation and + authenticated UI endpoints, not default-deny guest egress, payload DLP, or + proxy-held application credentials. +- **Competitive read**: The closest recent workflow competitor. It directly + addresses parallel coding agents, environmental conflict, and closing the + browser/test loop, but trades local custody for elastic cloud compute. + Cloud VMs and GPUs could be a future bot-bottle backend; they do not replace + its manifest/policy layer. +- **Maturity**: Active open-source monorepo project; HN launch received + 138 points and 36 comments. + +### Nucleus + +- **Source**: https://github.com/coproduct-opensource/nucleus ; + HN launch https://news.ycombinator.com/item?id=46855770 +- **Isolation/locality**: Firecracker microVM with an enforcing MCP tool proxy. +- **Agent integration/config**: Compositional permission envelope for + read/write/run actions. The envelope is non-escalating and can tighten or + terminate, with scoped approval tokens for gated operations. +- **Network/credentials**: Default-deny egress, DNS allowlist, iptables drift + detection, time/budget caps, and hash-chained audit logging are claimed. + Remote append-only audit storage and attestation were roadmap items at + launch. +- **Competitive read**: Direct on security architecture, especially + non-escalating policy and tamper-evident audit. It is an early execution/tool + proxy rather than a provider-neutral, one-command coding-agent product. Its + tool-level action envelope is semantically finer than bot-bottle's network + boundary; bot-bottle is stronger on turnkey agent/provider integration, + credential custody, Git mediation, and long-running operator workflow. +- **Maturity**: Early OSS experiment; HN launch received 3 points. + +### yolo-cage + +- **Source**: https://github.com/borenstein/yolo-cage ; + HN launch https://news.ycombinator.com/item?id=46706796 +- **Isolation/locality**: Local sandbox for running multiple coding agents in + YOLO mode. The launch discussion describes a VM boundary. +- **Agent integration**: Built around the native Claude Code experience and + motivated by running many agents in parallel without permission-prompt + fatigue. +- **Network/Git/credentials**: Strict egress filtering, configurable HTTP + middleware, and mediated `git`/`gh` dispatch are the main value. The launch + discussion explicitly identifies provider credential handling as unfinished + and difficult because Claude state spans multiple host paths. +- **Competitive read**: The closest new threat-model competitor. It shares + bot-bottle's premise that filesystem isolation alone is insufficient and + that Git plus authorized HTTP channels need mediation. bot-bottle currently + leads on cross-provider support, proxy-held Claude/Codex/forge credentials, + typed per-role manifests, content DLP, and supervision. yolo-cage's simpler + pitch and narrower Claude-first setup may be easier to explain. +- **Maturity**: Early local tool; HN launch received 60 points and 76 comments. + +### Sandbox Agent SDK + +- **Source**: https://github.com/rivet-dev/sandbox-agent ; + HN launch https://news.ycombinator.com/item?id=46795584 +- **Isolation/locality**: Does not provide the isolation primitive. It runs + inside E2B, Daytona, Modal, Cloudflare Containers, Agent Computer, BoxLite, + Docker, or another sandbox provider. Embedded mode can also run locally + without a sandbox. +- **Agent integration**: Provider-neutral Rust server/SDK exposing a common + HTTP/SSE/OpenAPI interface across Claude Code, Codex, OpenCode, Cursor, Amp, + and Pi, plus a universal event/session schema for external storage and + replay. It also exposes filesystem, managed-process, terminal, MCP, skills, + custom-tool, and computer-use APIs. TypeScript is the primary SDK surface. +- **Network/credentials**: Delegated to the chosen sandbox provider. +- **Credential posture**: Its documented convenience command extracts real + OpenAI/Anthropic credentials from local agent configuration and passes them + as environment variables into the sandbox. That is materially weaker than + bot-bottle's host-side credential custody, but it is an integration choice, + not a structural limitation: a sandbox provider could put a credential + proxy underneath the same SDK. +- **Competitive read**: A serious architectural threat despite not supplying + isolation. Sandbox Agent is trying to standardize the boundary *above* the + sandbox: one client protocol, session model, and UI/control surface across + every coding agent and runtime. If that boundary becomes the ecosystem + standard, users and application builders may choose a sandbox provider plus + Sandbox Agent rather than a vertically integrated launcher. bot-bottle's + manifests would then be valuable chiefly as a local policy/backend + implementation unless they expose an equally usable control contract. +- **Maturity**: Apache 2.0, ~1.5k stars and 426 commits at the 2026-07-27 + check; HN launch received 41 points. + +#### Why the Sandbox Agent architecture is strategically different + +The manifest and the universal control protocol solve different layers: + +- A bot-bottle manifest is a **trusted launch-time policy composition**. It + selects the agent role, isolation backend, image, skills, egress routes, + credentials, Git mediation, and supervision policy. Crucially, identity and + secret references live on the host side of the trust boundary. +- Sandbox Agent is a **runtime control and observation protocol**. A remote + client creates sessions, sends messages, handles permissions, configures + skills/MCP, manipulates files/processes/desktops, and streams normalized + events. It deliberately delegates sandbox lifecycle, Git management, + storage, network policy, and credential security to other products. + +That makes it complementary in a component diagram but competitive in product +architecture. The layer that becomes the stable integration point tends to own +the ecosystem. Three plausible threat paths matter: + +1. **Standard control plane, interchangeable runtimes.** Applications integrate + once with Sandbox Agent and treat E2B, Daytona, BoxLite, Docker, or a future + local microVM as replaceable compute. A provider that bundles adequate + egress and credential custody makes bot-bottle's end-to-end launcher less + necessary. +2. **Policy grows upward.** Sandbox Agent already configures permissions, + skills, MCP, custom tools, filesystem/process access, and computer use. If + it adds a declarative, host-verifiable policy document, the overlap with + agent/bottle manifests becomes substantial even if enforcement remains + delegated. +3. **UI and session ownership.** Its universal transcript schema, Inspector, + React components, event replay, and remote terminal/computer APIs can become + the natural basis for desktop, web, and mobile agent managers. bot-bottle's + security layer could remain stronger while losing the operator surface and + distribution channel. + +The counter-position is not to claim that manifests and an API are mutually +exclusive. The defensible split is: + +- bot-bottle owns the trusted policy and enforcement plane outside the agent; +- a provider-neutral protocol owns agent process control and normalized + events; and +- the operator UI consumes both. + +This suggests an explicit compatibility decision rather than parallel, +accidental protocol design: evaluate running Sandbox Agent inside a bottle and +exposing it only through the authenticated bot-bottle control plane. If its +schema is suitable, adopting it could turn a threat into an integration while +keeping manifests as the higher-trust policy source. If it is unsuitable, +bot-bottle should still publish a stable provider-neutral session/event API so +frontends do not depend on Claude/Codex/Pi-specific process behavior. + ## Comparison table *Isolation/sandbox tools only. AGT and OAP are governance layers — see their per-project notes above.* @@ -616,6 +817,70 @@ 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. +**Recent entrants change two parts of this read.** yolo-cage is closer to the +actual threat model than agent-safehouse or litterbox: it combines a VM-style +boundary with mediated Git and filtered HTTP specifically for parallel coding +agents. Sandbox Agent SDK is the more important strategic entrant even though +it supplies no isolation. It can become the standard agent-control layer above +all of these runtimes, including a future bot-bottle backend. CloudRouter is +the clearest workflow challenge because its browser/desktop/GPU loop makes +parallel agents visibly more capable, not merely safer. + +## Gap evaluation after the 2026-07-27 entrant scan + +### Material gaps + +1. **A stable provider-neutral control and event protocol.** This is the + largest newly visible gap. bot-bottle normalizes launch/provisioning across + providers, but an external UI or orchestrator still lacks one documented + contract for creating a Claude/Codex/Pi session, sending input, handling + permission/supervision events, streaming normalized output, reconnecting, + and replaying history. Sandbox Agent SDK addresses exactly this layer and + is already portable across many sandbox providers. +2. **Browser/preview closure.** CloudRouter and Eve make a browser or desktop + part of the standard agent environment and expose screenshots/live viewing + to the operator. bot-bottle can run dev servers and supports nested + containers, but it does not present a first-class browser/computer-use + primitive or an auth-protected preview surface. For coding agents expected + to verify UI work, this is a real product gap. +3. **Unified parallel-session operator UX.** Named persistent bottles and + supervision provide the substrate, but the recent products make task + switching, live progress, notifications, terminal attach, diffs, and + session history the product. Security depth will not compensate for a + visibly rougher daily loop. +4. **Normalized transcript persistence and replay.** bot-bottle preserves + provider-specific state for resume; it does not expose a provider-neutral + event record suitable for audit, replay, analytics, or a web/mobile client. + This is both a UX gap and an audit gap. + +### Important, but not necessarily bot-bottle features + +- **Cloud VM/GPU provisioning.** Valuable for elastic workloads and could be a + backend, but it conflicts with the local-custody default and should not + displace core policy work. +- **Automatic model routing.** Black LLAB and Eve sell task-to-model routing. + bot-bottle's provider-template boundary can host that choice without making + it part of the trusted sandbox policy. +- **A thousand SaaS connectors.** This broadens capability and blast radius. + The bot-bottle-native answer should remain explicit, scoped forge/egress + associations rather than connector count as a goal. +- **SDK-driven sandbox lifecycle as the primary configuration model.** Useful + for platform builders, but not a replacement for reviewable, host-owned + manifests. A control API and a declarative policy source are compatible; + neither should silently become the other. + +### Areas where bot-bottle remains ahead + +- real provider and forge credentials remain outside the agent process rather + than being extracted into its environment; +- authorized HTTP payloads are scanned, not merely destination-filtered; +- Git writes traverse a distinct gate with secret scanning and host-held + upstream credentials; +- role policy is host-owned, composable, and separate from untrusted repo + content; and +- local Firecracker/Apple Container execution preserves operator custody + without requiring a hosted sandbox platform. + ## Borrowable ideas ### Already shipped or otherwise addressed @@ -642,6 +907,19 @@ capability passing rather than kernel boundaries. ### Still worth considering +- **Sandbox Agent compatibility or an equivalent stable protocol (highest + priority):** spike running its server inside a bottle behind bot-bottle's + authenticated control plane. Compare its session/event schema, permission + model, restore semantics, and provider coverage with current provider + adapters. Adopt compatibility if it preserves the host-owned trust boundary; + otherwise specify bot-bottle's own stable API before building another UI. +- **First-class browser/preview loop** (from CloudRouter and Eve): give a + bottle an optional browser/computer-use capability plus an operator-visible, + authenticated preview/screenshot surface. Treat its network access as part + of the bottle policy, not an implicit bypass. +- **Provider-neutral transcript/event persistence** (from Sandbox Agent SDK): + retain enough normalized structure for replay and audit while preserving the + provider-native state needed for exact resume. - **Live network activity in the supervisor TUI** (from Docker sbx): show allowed and blocked connections and let the operator propose policy changes from the existing supervision surface. @@ -652,10 +930,11 @@ capability passing rather than kernel boundaries. closer review. This needs a carefully specified trust model before it can be more than a heuristic. -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). +Not worth borrowing: SDK-first *policy configuration* as used by boxlite / +microsandbox (cuts against the reviewable declarative-manifest stance), and +the hosted-SaaS custody model of tilde.run (cuts against the "infrastructure I +control" goal). A provider-neutral runtime-control API is a separate concern +and is worth borrowing. ## Publishing and positioning verdict @@ -679,9 +958,15 @@ bot-bottle remains unusual in combining: The practical wedge is “as easy as native yolo, with declarative role policy and self-hosted custody,” including scoped access to private LAN/Tailnet services that cloud-first runtimes cannot provide without additional network -plumbing. The main competitive risks are a local wrapper such as claudebox or -Docker sbx growing a role-manifest layer, and GUI products such as SuperHQ -adding equivalent policy and audit depth. +plumbing. The main competitive risks are now: + +- a local wrapper such as yolo-cage, claudebox, or Docker sbx growing a + role-manifest and credential-custody layer; +- Sandbox Agent SDK becoming the standard control/session boundary and making + the runtime beneath it interchangeable; and +- GUI products such as SuperHQ or CloudRouter adding equivalent policy and + audit depth before bot-bottle closes the browser/preview and + parallel-session UX gaps. ## Caveats