MicroVM and per-agent hard isolation

The push from containers to microVMs came from enterprise security teams refusing, uniformly, to sign off a shared kernel as an isolation boundary — roughly a dozen escapes over six to eight years is the record they were reading. The rebuilt shape runs the agent in a container inside a microVM with no host filesystem access by default and a network-proxy allowlist, with secrets injected as sentinel values: the proxy swaps real credentials into approved outbound requests outside the sandbox, so the agent never possesses the key it uses. The stated limit is worth carrying too — sandboxing bounds blast radius, not application-level abuse.

The team-scale corollary is blunt. Five agents on one working directory produced a stash that ate four agents’ work, and the next day an rm -rf of the checkout mid-demo-prep. “You wouldn’t hire a team of developers and ask them to share one computer.” Centralizing those environments server-side buys handoff across time zones as a side effect, with idle machines shutting themselves down.

For the sandbox to be the default rather than a ceremony, the environment definition has to become a versioned, declarative artifact shipped like any other dependency — that is what solves the empty-sandbox developer-experience problem. The other half is the rule for untrusted surfaces: any step that opens something unknown runs in a throwaway sandbox with only a verdict crossing back. One team was opening unknown preview URLs roughly a hundred times a month from a host holding source code, customer data and model credentials; the fix was an ephemeral sandbox per requirement that returns a verdict and nothing else.

Also: a microVM agent sandbox distributed as a Homebrew formula, and its devcontainer features; a Rust sandbox for agent-generated Python; a vendor-neutral reference set of roughly 35 agent controls.

Every worker and every desk boots into its own locked working copy off a fresh trunk, never mutating a shared checkout, with a dedicated supervisor owning creation, locking and pruning. That is the one-computer-per-developer rule, and the stash and rm -rf incidents above are the exact failures the rule was written against. Server-side rulesets and branch protection carry the write boundary the working copy itself cannot — isolation of the workspace does not bound what a credential can do.

Desks today run on the host, with real tokens in process, against a network with no allowlist. The isolation is organizational, not enforced, and that is the honest position: this concept is a gap, not a claim. The proposed experiment is narrow and unstarted — one desk, on one low-risk repository, inside a microVM with an egress allowlist, documenting exactly which desk verbs need an escape hatch. The vendor-neutral control set is a ready-made checklist to diff the guard layer against, and that diff has not been run.

One transferable rule needs no infrastructure and is currently only convention: a desk must never open an external URL from a credentialed session. Quarantined material should be opened in an ephemeral sandbox with a verdict-only return path — which is precisely the design one of the sources above arrived at after counting how often it was doing the opposite.

• Whether declarative sandbox definitions converge on a portable format, which would make sandbox-by-default cheap for a small team rather than a platform project.
• Whether anyone reports the operational cost of running desk-class long-lived agents under microVM isolation — the open question is how many escape hatches the verb set actually needs.
• Whether credential injection at the proxy shows up as an off-the-shelf component rather than in-house plumbing.