Microsoft Execution Containers (MXC): Build 2026's Answer to the Shared-Kernel Problem

A couple of days ago I wrote a post
arguing that namespaces are the operating-system feature AI agents were always waiting for: the
kernel primitive that lets you box an untrusted, unpredictable agent into its own private little
world, cheaply, by the hundred. I also flagged the one honest catch. Containers share the host's
single kernel — so a clever enough exploit, a prompt-injection plus a kernel bug, can in principle
break out of the box.

Then I went and looked at what Microsoft announced at Build 2026, and I had to laugh a little,
because they spent a good chunk of the conference answering exactly that catch. The answer is called
Microsoft Execution Containers — MXC — and it's interesting enough that it earns its own post. Call
this part two.

If you haven't read the namespaces piece,
the one sentence you need is: a container is a normal process boxed in by namespaces (what it can
see) and cgroups (what it can use), all running on the host's one shared kernel. That shared
kernel is fast — and it's the weak point.

The pitch: keep the speed, lose the shared kernel

Here's the line from Microsoft's own framing that made me sit up, because it could have been lifted
straight from my last post:

Unlike traditional Docker containers that rely on namespaces and cgroups, MXC taps directly
into the Windows Hypervisor Platform and kernel to create hard boundaries.

That's the whole idea in one sentence. Instead of isolating agents with namespaces on a shared kernel,
MXC puts each agent behind a hypervisor-enforced boundary — the containers "share no kernel objects
with the host." It's closer in spirit to a virtual machine than to a Docker container. Which, if you
read part one, should make you immediately suspicious: isn't that the heavy, slow option I said agents
can't afford by the hundred?

That's the clever part, and it's why the numbers matter.

The numbers that make it real

A hypervisor boundary that performs like a container is the entire trick. Microsoft's early figures:

Metric	MXC
CPU overhead vs. running outside a container	under 5%
Memory per container	40–60 MB
Launch time	under 200 ms
Concurrent agents on one dev workstation	dozens

If those hold up, that's remarkable. It means you get VM-grade isolation — the thing I said you'd
normally reach for gVisor, Kata, or Firecracker to approximate — at container-grade cost. Forty to
sixty megabytes and a sub-200ms start is light enough to run a whole swarm of agents on a laptop, each
one in its own hardware-backed cell, each one destroyed when it's done.

That last bit is straight out of the "one agent, one disposable sandbox" model: MXC containers are
ephemeral by default, torn down when the task completes or times out, wiping all temporary state.
The blast radius of a misbehaving agent is, again, the container — except now the container walls are
made of hypervisor, not namespace.

It's not one thing — it's a tiered "composable sandbox"

MXC isn't a single isolation mode; it's a ladder you climb based on how much you trust the workload.
The SDK is explicitly "an abstraction layer across isolation primitives, so developers don't have to
manage low-level isolation details." The tiers:

Tier	What it isolates	Status
Process isolation	Lightweight containment inside your session — restricts what model-generated code can touch (files, network domains)	Shipping — GitHub Copilot CLI already uses this
Session isolation	Separates the agent from your interactive desktop, clipboard, UI, and input devices; runs under a distinct user account tied to an identity	Shipping
Micro-VM	Hardware-backed hypervisor isolation with lightweight images, for higher-risk workloads	Roadmap
Linux containers	Brings the same containment model to Linux-first agent toolchains via WSL	Roadmap

The session isolation tier is the one I find most thoughtful, because it targets a class of attack
namespaces alone don't address. Plain containers isolate processes. They don't inherently stop an
agent from spoofing your UI, injecting synthetic input, or reading across sessions. By running the
agent under its own user account — bound to a strong identity — MXC mitigates UI spoofing, input
injection, and cross-session data leakage. That's an agent-specific threat model, not a
rehash of generic container security, and it shows someone thought hard about how agents actually
go wrong.

The manifest: declare what it can touch, the kernel enforces it

This is the part that maps cleanly onto the advice from part one ("the network namespace is your best
secret-safety control"). In MXC you write a policy — JSON or YAML — declaring the agent's
capabilities, and Windows enforces it at the kernel level:

Files — specific directory paths the agent may read or write (e.g. C:\workspace\)
Network — an allow-list of approved API endpoints, plus an internet on/off toggle
Processes — whether it can spawn child processes
Resources — memory caps in MB, timeouts in seconds, GPU allocation
Default-deny on the dangerous stuff — clipboard, audio, and webcam are blocked unless you
explicitly enable them

That default-deny posture is the right instinct. An agent shouldn't have your clipboard or your webcam
unless you said so, out loud, in a manifest. And because these policies can be pushed centrally through
Entra and Intune (MDM/GPO-style), this isn't just a local-dev toy — it's something an org can govern
across a fleet of machines. Define the boundary once; the kernel makes it true everywhere.

The cloud half: Foundry Hosted Agents

The same philosophy shows up server-side in Foundry Hosted Agents. Each session gets its own
VM-isolated sandbox with a persistent filesystem that survives scale-to-zero — the agent
resumes "exactly where it left off," files and disk state intact, while costing nothing when idle.
OpenTelemetry traces flow into Application Insights with no extra wiring. It pairs with Agent
Harness (automatic context compaction and built-in providers) and CodeAct (optimized multi-step
tool calling). So the on-device story and the cloud story are the same story: per-agent, VM-isolated,
ephemeral-but-resumable, observable by default.

And the partner list tells you this isn't a Microsoft-only bet — OpenAI, NVIDIA (OpenShell on
Windows), Manus, Nous Research (the Hermes agent), and the OpenClaw open-source project are all
building on it.

My honest take, as the resident Windows person

Regular readers know I'm a Windows person at heart,
so I'll admit some bias here — but I think MXC is genuinely well-aimed. It takes the exact weakness I
called out in the namespaces post and fixes it the right way: not by going back to heavyweight VMs, but
by making hypervisor isolation cheap enough to use like a container. The manifest model is sane, the
default-deny on clipboard/camera is correct, and the session-isolation tier shows real thought about
agent-specific attacks rather than generic sandboxing.

Two caveats keep me honest:

It's Windows- and WSL-first. Today it needs Windows 11 build 26100+ and WSL2 kernel
5.15.167.1+, with the SDK in early preview on GitHub, NuGet, and PyPI. The Linux-native and
roadmap tiers are coming, but if you're on a Mac like I sometimes am, this isn't your tool yet —
you're still in namespaces-and-microVMs land, which is fine, just different.
"Early preview" means early. The numbers are early benchmarks and the roadmap tiers (Micro-VM,
Linux containers) aren't here. I'd build with it and watch it; I wouldn't bet a production fleet on
the preview's figures without measuring them myself.

But the direction is exactly right. The story arc from part one to part two is, I think, the story arc
of the whole field this year: agents made us care about isolation again, the old shared-kernel
primitive got us most of the way, and now the OS vendors are racing to close the last gap — the kernel
everybody shares. MXC is Microsoft's swing at it, and it's a good one.

If you've kicked the tires on the MXC preview — or you have opinions on what the Mac and Linux-native
answer should look like — I'd love to hear them. The links are on the about page.