Agent sandbox

An agent sandbox is a hard-isolated execution environment for untrusted AI-agent work: the agent’s shell, code, and tool calls run inside a VM boundary, not just a container namespace, so a prompt injection or a buggy command cannot reach the host. The sandbox is where “the agent might get tricked” stops being a hope and becomes a containment property — the outer layer of the stack whose inner layers are interception (PII redaction) and testing (Agent tests).

Why VMs and not containers: containers share the host kernel — a container escape is a kernel exploit away, and agent workloads invite weird inputs (fetched web pages, dependency installs, attacker-controlled tickets). MicroVMs (Firecracker-class, or KVM with tiny guests) give hardware isolation with near-container ergonomics: sub-100 ms boot, snapshot/fork, OCI images, Docker-like workflows. The trade: nested-virtualization requirements, per-VM memory overhead, and another layer to debug.

The field:

• microsandbox (OSS) — the Rust entry (8.4k★, Apache-2.0): local microVMs for “AI agents, user code, plugins, CI jobs, dev environments, scrapers” — instant startup, branch & snapshot live sandboxes, OCI-compatible, embeddable as a library, detached long-running mode, agent skills + MCP server so agents create their own sandboxes, and the clever bit: “unexploitable secret keys that never enter the VM” (host-side secret brokering instead of env-var injection).
• monty (OSS) — the pydantic entry (8.4k★, MIT, Rust): a library, not a VM — a Python 3.14 interpreter sandbox you uv add into your process, for exactly the “run LLM-generated code” case. No filesystem, no env vars, no network inside — the sandbox reaches the host only through functions and mounts you pass in. New sandbox from a running pool: <1 ms (Full Monty commercial server: ~2 ms over WebSocket) vs ~1500 ms for container/sandbox services — the answer to the auchenberg objection that agent-first compute can’t afford a VM per agent (“25M live VMs = 75PB DRAM”; Colvin’s reply: “Solved”). Ships Python/JS/Rust bindings. The latency/efficiency pole of the spectrum: in-process interpreter isolation vs microsandbox’s hardware isolation.
• The incumbents: E2B (cloud sandboxes for agents, Firecracker-based), Daytona, Modal. The patterns converge: SDK-spawned VMs, per-task lifetime, snapshot restore.
• gVisor as the middle layer (user-space kernel, lighter than VM, stronger than containers) — the same spectrum as the homelab notes’ container/VM discussion.

Agent-specific requirements beyond generic sandboxing:

• Session lifetime — agents work in hours-long sessions; snapshot/fork (microsandbox’s branch feature) matters for “try, inspect, roll back”.
• Egress control — an infected sandbox with network access is an exfiltration node; default-deny egress with an allowlist is the guardrail that makes sandboxing meaningful for the PII redaction threat model.
• Secrets architecture — secrets-in-env is the classic leak; host-brokered secrets (microsandbox’s approach, vault-injected short-lived creds per the Homelab’s vault) keep the boundary real.
• Self-provisioning — agents creating their own sandboxes via MCP turns containment into a tool the harness calls before risky work, instead of a platform decision.

Open questions: does it earn a slot on the doombox (Podman rootless + systemd is the current containment; a microVM layer would be for genuinely untrusted agent code paths)? Nested virt on the homelab hypervisors? Overhead vs. just running agents in a dedicated VM the coarse way?

Sources (captured 2026-09-27): microsandbox (OSS) README · note: the @tobi tweet in the same capture window (x-2103251521223921739) is his disktree announcement, not a microsandbox reference — captured anyway as a bookmark of the timeline context.

The Microsoft entries: MXC + Quicksand (2026-10-08, simonw)

simonw (60❤, quoting kdaigle): Microsoft open-sourced two sandbox layers for agents — captured both.

• mxc (OSS) (1.6k★; “Microsoft eXecution Container”) — policy-driven, layered isolation behind one unified model across Windows/macOS/Linux: containment backends per platform — ProcessContainer, Windows Sandbox, LXC, Bubblewrap, Seatbelt, MicroVM (Nanvix), Hyperlight, IsolationSession, WSLC — with JSON-configured security policies (filesystem read-only/read-write/denied paths, network proxy/egress controls, UI/clipboard policy), state-aware lifecycle (provision→start→execute→stop→deprovision), Rust/.NET/Node SDKs, diagnostics for access-denied failures. kdaigle’s framing: “a real platform opportunity — process, session, micro VM, and deep integration into agent ID on Windows.” For this note’s spectrum: MXC is the unification layer — instead of choosing a point on the container→gVisor→microVM axis, policy selects the backend and the SDK boundary stays constant.
• quicksand (OSS) (74★) — “quickly sandbox your AI agent”: async Python API over bundled QEMU — launch/control/snapshot VMs (Ubuntu/Alpine images, x86_64+ARM64, macOS/Linux/Windows), no root, no Docker; pip install 'quick-sandbox[qemu,alpine]'. Willison: “really neat, I’ve tried it on macOS and Windows and Linux.” The library-shaped microVM pole — microsandbox’s ergonomics without the daemon, and the snapshot feature is exactly the session-lifetime requirement above.

Strands Box: kernel isolation in service of semantic policy (2026-10-08, Brooker)

MarcJBrooker (334❤; 5-tweet thread) + the big-picture post + box (OSS) (210★ Rust; all captured): AWS’s open agent sandbox, and the architecture argument is the keepable part — a walk of the isolation levels from the policy perspective: MicroVMs (Firecracker/Lambda/AgentCore — great TCB and perf, but “down at the network card all you see is TLS ciphertexts… device emulation is an awkward place for rich policy”) → syscall level (containers/SECCOMP — richer semantics, but allowlists rot as the kernel grows, TOCTOU traps) → gVisor (emulate the kernel — effective, “still doesn’t get up to a high enough semantic level to implement policy on MCP calls”). Strands Box’s two-pronged answer: kernel mechanisms don’t apply policy — they funnel everything through the policy layer (Strands Shell for shell, Pydantic Monty for Python, MCP broker, network gateway), where Dogwood policies are semantic and temporal: e.g. git push forbidden unless npm test succeeded within 15 min since the last git add; or ≤60 calls/hour to the AWS MCP server — “temporal” logic over the action history, not path rules. Honest box: bigger TCB (“more code means more opportunity for bugs, and bugs could mean bypassed policy”) → recommendation is Box inside a per-session MicroVM (AgentCore) — semantic policy locally, hardware boundary between sessions. The convergence this note tracks is now explicit across vendors: secrets brokered outside (Agent sandbox requirements), policy above the isolation layer, and MXC’s unified backends + Box’s policy-funnel + uniTerm’s credential vault are the same three-part pattern from three directions.

Brooker’s follow-up: the VMM-lover’s case against VMs for local agents (2026-10-08)

MarcJBrooker (7-tweet thread, 71❤; answering “why didn’t Strands Box use a cross-platform VMM?”): “I love virtualization. You can see my name on the Firecracker paper. I’ve written a bare metal VMM using the CPU manuals… We picked it for AgentCore Runtime. So why didn’t we pick virtualization for Strands Box?” The answers: (1) policy placement — “super hard to apply the kind of semantic policy we want at the syscall level, nearly impossible at the virtual device level” (the blog post’s isolation-level walk, restated); (2) in-VM policy layers weaken the threat model; a sidecar-VM policy layer via wire protocol is “complex and a nasty compat treadmill”; (3) local-agent VM costs — density, memory consumption, IO performance, setup complexity: “all surmountable, but none entirely solved… for local agents. The cloud is a different story: VMs are a slam-dunk there.” The honest close: “a space still full of trade-offs, and we chose the ones that let us innovate on… policy. Powerful policy. Common-sense policy. (Starting to sound like I’m running for office here.)” This sharpens the Box section above with the split verdict: local = policy-funnel sandbox (+ MicroVM per session when cloud-deployed), cloud = MicroVMs as the slam-dunk — the same spectrum this note maps, with the deployment context as the axis that decides it.