Autonomous agents execute code they wrote seconds ago. That is the point — and the problem. You would not run untrusted code next to your other workloads behind nothing but a kernel namespace, so we don't either.
The boundary is hardware, not convention
Containers isolate by agreement: every tenant shares one kernel, and the namespace promises to keep them apart. A microVM isolates by construction — its own guest kernel, its own memory, a boundary enforced by the hypervisor. One agent, one VM — an escape has to defeat that boundary, not talk a namespace into sharing.
The boundary is sealed before the agent executes its first instruction. The filesystem policy and the syscall surface are locked when the sandbox is created — not applied afterwards, and not widenable from inside the guest.
Egress is a decision, not a default
Inside the wall the agent has everything it needs: the repo, its model, scoped secrets. What it doesn't have is the internet. A session starts with no route out, and what it may reach is resolved when the session is created — the repository host, the model endpoint, any configured MCP endpoint. Everything else is dropped, and the set closes again with the session.
That control is its own layer. The hypervisor gives you the wall; it does not filter packets. Deny-by-default egress is enforced separately, on the host datapath outside the guest, which is why it holds even when the workload inside is the thing you distrust.
A running session streams a structured event feed you can watch — boundary state, the destinations resolved for it, when the session closed. "Trust us" is not an architecture; read the feed instead. The events are kept rather than only shown: each one is stored in the open OCSF schema as it was recorded. What is not delivered is an export you can hand to a reviewer, a retention window set per customer, and anything cryptographically anchored.
This is the difference between a sandbox you hope holds and one you can point at. A shared-kernel container asks you to trust the namespace, the seccomp profile, and every CVE that hasn't been found yet. A microVM asks you to trust the hardware boundary — the same one your cloud provider already bets its multi-tenancy on.
A small number of teams with real workloads. Honest answers, no newsletter.
Why this beats hardened Docker
Rootless mode, user namespaces, gVisor and a maintained seccomp allowlist can harden Docker for agent workloads. The workload still shares a kernel with its host.
Our Docker sandboxing and microVM comparison covers that threat model in detail.
microVM isolation moves the boundary down a layer, so a kernel bug in the guest stays contained. Teams have fewer controls to maintain and a clearer boundary to show a security reviewer.
For agents that write and run their own code, that trade is not close. The wall is the product.
The layer-by-layer architecture — filesystem policy, syscall surface, network boundary, credential handling — is written up on the microVM isolation page. What that boundary means for a running agent session is on the agent sandbox page.
A public CLI and the agent skill that wraps it are on the roadmap, not yet generally available. Persistent sessions, resume and fork are planned too — none of it is live, and we are not going to describe it as if it were.