Docker Sandboxes — microVM Isolation for Coding and Personal Agents

Source: raw/Docker_Sandboxes_-_Building_Safe_Agents.md

URL: https://www.youtube.com/watch?v=erQnRkMrpls | Platform: YouTube

Sponsorship disclosed

The source video states plainly that Docker sponsored it. The mechanism description and CLI walkthrough are verifiable and are what this article records; the comparative framing (“really good solution”) is vendor-adjacent and should not be read as an independent evaluation. No competing sandbox product was tested in the source.

Docker Sandboxes gives each agent a microVM — a small, fast virtual machine with its own Linux kernel — rather than a container, and wraps it in declarative policy covering network access, filesystem read/write scope, model access, and credential handling. It targets the specific bind that makes agent autonomy expensive: either you babysit a permission prompt for three hours, or you pass --dangerously-skip-permissions and hope.

Key Takeaways

• It is a microVM, not a container, and the distinction is the product. Isolation is enforced by the hypervisor at the hardware level, not by kernel namespaces. Full VMs isolate well but are slow to spin up and tear down; containers are fast but share your kernel. The microVM sits between: VM-grade isolation with fast boot and teardown, which is the profile agent workloads actually need.
• Each sandbox runs its own Docker engine. You can install packages, run builds, and make a mess inside, then discard the whole VM with nothing having touched the host.
• Network policy has three modes — open, balanced, closed — chosen at first setup and resettable. balanced is the practical default and ships with roughly 192 approved hosts covering common agent destinations. closed blocks all network traffic; open applies no restriction.
• Filesystem scope is per-sandbox and it holds. In the demo, an agent asked to write a README one directory up from its sandbox folder was blocked, while writes inside its own folder succeeded normally.
• The blocked write failed silently from the agent’s point of view — it reported success. The source’s words: “it thinks that it’s actually done it, but it’s actually been blocked.” This is the wiki’s fabrication failure family reproduced by a sandbox boundary rather than by model behavior: a hard boundary that denies without erroring teaches the agent it succeeded. Verify artifacts on the host, not from the agent’s own report.
• Credential isolation is a first-class goal, framed against prompt injection. The stated aim is that a compromised or injected agent cannot exfiltrate credentials, with a proxy sitting between the agent and its secrets rather than the secrets living in the agent’s environment.
• Running Claude Code with bypass permissions becomes defensible inside it. The demo runs Claude Code in bypass mode within the sandbox — the permission prompt is redundant when the blast radius is already a disposable VM. That is the actual workflow unlock.
• It is free and requires a linked Docker account (sbx login). The source speculates the account requirement is enterprise-seat groundwork rather than a paywall — that is the creator’s guess, not a Docker statement.
• It is agent-agnostic. Demonstrated with Codex and Claude Code; the source names Hermes, OpenClaw, and custom agents as intended targets, and calls out cheap evaluation of unfamiliar agents (point one at a local model on LM Studio, let it run for hours, judge the result) as the everyday use.

Implementation

• Tool/Service: Docker Sandboxes, CLI sbx.
• Setup:

  sbx login                      # link a Docker account and authorize the machine
  sbx run codex                  # create + run a sandbox with an agent in the cwd
  sbx run claude --name testing-cc
  sbx ls                         # list sandboxes and what is running in each
  sbx policy reset               # re-choose open | balanced | closed (stops running sandboxes first)
  sbx policy ls testing-cc       # inspect that sandbox's policy, incl. network hosts

• Cost: Free. Docker account required.
• Integration notes: Sandbox images are downloaded on first use and cached. sbx run creates and starts in one step (create exists separately). The agent’s own auth (e.g. Claude Code web login) happens inside the sandbox. Network policy is inspectable per-sandbox after the fact, which is the useful audit surface — you can ask what a run actually tried to reach.

Try It

• Put your next unattended coding run inside sbx run and drop the permission prompting rather than the safety.
• Use it to evaluate an agent you do not trust yet. This is the strongest everyday case: a disposable VM plus a local model costs nothing to be wrong about.
• Start on balanced, then sbx policy ls <name> after a real run to see what it actually reached. Tighten from evidence rather than guessing up front.
• Check the host filesystem for the artifacts you expected — do not take the agent’s completion report as proof, given the silent-block behavior above.
• If you run agents with credentials, test the proxy path deliberately before trusting it with anything live.

Open Questions

• What are the exact policy primitives? The source demonstrates network modes and filesystem scoping but does not show the policy file format, the model-access controls it mentions, or how the credential proxy is configured.
• Is the ~192-host balanced allowlist published, and can it be edited? The source inspects it but does not show editing or its source of truth.
• What is the platform support and host overhead? “Instructions are pretty easy on the different platforms” is the only statement; macOS/Linux/Windows behavior and per-sandbox memory cost are unaddressed.
• How does it compare to the alternatives? Claude Code ships its own sandboxing, and the wiki records microVM use elsewhere (Replit). No comparison was run in a sponsored source, so none is recorded here.
• Does the silent-block behavior have a configurable alternative? A boundary that returns an error the agent can see would be strictly better than one it misreads as success. Not addressed.

Related

• Agent Lying and RLVR — why an agent reports success on a blocked action, and why tool calls beat conclusions as evidence.
• Cairn — Multisig Spend Gate — the same principle one layer up: put the boundary outside the prompt, where instructions cannot argue with it.
• Agent Guardrails — the prompt-and-policy side of the same problem.
• Replit — Self-Driving Company — microVMs in a production agent platform.
• What’s New — Week 34 — Claude Code’s own sandbox and permission changes landing the same week.
• Should You Build a Loop? — the security tax that isolation is paying down.