The short answer: A microVM gives each run of untrusted code its own kernel — the strongest, most defensible boundary — but you rent it per run and pay per second. MXC (Microsoft's newly open-sourced Execution Containers) gives a process an OS-enforced policy — allowed syscalls, files, and network, everything else denied — for free, on a machine you already control, with an identity stamped on every action. Pick by answering one question: where does the untrusted code run? Rented cloud that a customer's security review will scrutinize → microVM. Infrastructure you own, and you want a zero-cost floor → MXC. The best real setups use both.

Why this is a new decision#

For most of 2026 the sandbox conversation had two answers: a plain container (fast, cheap, and not actually a security boundary) or a microVM you rented from E2B, Fly, Modal, or Vercel — the field we mapped in which agent sandbox to pick in 2026. Microsoft open-sourcing MXC under MIT adds a genuinely different third answer, and it's not a new vendor — it's a new paradigm: enforce a policy on a process instead of virtualizing a machine around it. (For what MXC is and how to wire it, see the MXC tool highlight.)

The two paradigms optimize for different things, and conflating them is how teams overspend or under-protect.

The two boundaries, honestly#

A microVM boots a real, tiny virtual machine — its own kernel — for each run. Firecracker (the primitive under AWS Lambda, E2B, Fly, and Vercel) is the reference implementation. The value is a boundary you can point to: when a customer's security review asks "what stops the agent's generated code from touching the host?", "a hardware-virtualized VM with a separate kernel" is a complete answer. The cost is that you rent it — a per-second CPU-and-memory line item — and the code runs in the vendor's region, not yours.

MXC enforces a policy on an ordinary process. No VM boots; instead the OS constrains which syscalls the process may make, which filesystem paths it may read or write, and which network destinations it may reach — denying everything else by default. The boundary is a policy, not a separate kernel, so it's weaker against a true kernel-level exploit. In exchange it's free, MIT-licensed, runs where your code already runs (Windows, Linux, macOS, WSL), and attributes every action to a Microsoft Entra identity so an audit can separate human activity from agent activity.

Neither is strictly "better." A separate kernel is a stronger wall; a policy on a process is a cheaper, closer one that still stops the common agent failure — a tool reading ~/.ssh/id_rsa or opening a socket it was never meant to — without a VM per call.

The one axis that decides it#

Everything reduces to where the untrusted code executes:

A second axis breaks ties when the first is ambiguous: do you need a boundary you can point to in a compliance artifact? If yes, that pulls toward the microVM regardless of where the code runs, because "separate kernel" is easier to defend on paper than "syscall policy."

Use both — it's a placement decision#

The strongest architecture isn't one or the other. Make MXC the default — the local-first jail every tool call runs inside, at zero marginal cost, with identity attribution feeding your zero-trust posture. Then graduate the highest-risk tier to a microVM where the code runs in your cloud and the threat model — or a customer — demands a separate kernel. That two-tier shape gives you a free floor everywhere and a hardware wall exactly where it earns its cost, instead of paying microVM prices to sandbox code that never left your laptop.

Whatever you pick, the deprecated option is the same: do not run model-generated code in a bare container and call it isolated. The real choice in late 2026 is a policy or a kernel — and now that MXC is open source, the policy option is free.