The short version: MXC — Microsoft Execution Containers — is an OS-level sandbox for untrusted code: model output, plugins, and agent tool calls. Instead of renting a heavier isolation boundary per run, you wrap the code in a policy the operating system enforces — allowed syscalls, filesystem paths, and network egress, everything else denied — and every action inside gets stamped with a Microsoft Entra identity so an audit can tell a human from an agent. It runs on Windows, Linux, and macOS, it's MIT-licensed open source at github.com/microsoft/mxc, the TypeScript SDK is on npm as @microsoft/mxc-sdk, and GitHub Copilot CLI already ships on it. If your agent runs code it wrote itself and that code runs on a machine you control, this is the free floor you've been wiring by hand.
What it is#
An agent that writes and runs its own code is running untrusted code by definition. The failure modes are well known — prompt injection that turns a helpful tool call into an exfiltration attempt, a hallucinated shell command that reads a secret it shouldn't, a plugin that reaches a network endpoint you never approved. The usual answer is to reach for a container, but a container is not a sandbox: it shares the host kernel and was designed to package software, not to defend against hostile software.
MXC comes at the problem from the operating system rather than from the vendor cloud. It's a policy-driven execution layer — an SDK plus a policy model — embedded as a primitive in Windows and WSL, and shipped cross-platform for Linux and macOS. You describe what a piece of code is allowed to do; the OS enforces the rest. Microsoft announced it at Build 2026 (June 2, 2026) as part of turning Windows into a platform that can host agents safely, and — the part that matters for a founder — open-sourced it under MIT.
Two properties make it more than "another sandbox":
- The boundary is a policy, not a rented machine. You constrain syscalls, filesystem access, and egress on a process you already run. There's no per-second sandbox bill and no round trip to a vendor's region.
- Identity is built in. Each container carries a local or Entra-backed identity, and Windows attributes every action inside it to that identity. That's the missing half of most homegrown sandboxes: not just what ran, but whose agent ran it — the same problem we covered in how to authenticate an AI agent identity.
Who it's for#
MXC is aimed at the founder or small team whose agent executes untrusted code on infrastructure they own — a developer laptop, a CI runner, a self-hosted worker, an on-prem box. If that's you, the appeal is blunt: a defensible, OS-enforced boundary at zero marginal cost, with audit-grade attribution, instead of standing up a microVM vendor before you've shipped.
It's a weaker fit if your untrusted code runs in a cloud you rent and you need a hardware-virtualized wall you can point to in a SOC 2 or a customer security review. That's still microVM territory — see which agent sandbox to pick in 2026 for the E2B / Fly / Modal / Cloud Run landscape. MXC and a microVM are not mutually exclusive: the honest architecture is often MXC as the local-first default and a microVM for the cloud tier where the threat model demands a separate kernel.
How to start#
The SDK is on npm, so first contact is one install:
npm install @microsoft/mxc-sdkThen wrap the untrusted call in a policy — deny by default, allow the narrow set the tool actually needs:
import { ExecutionContainer } from "@microsoft/mxc-sdk";
// One policy per tool: allow only what this tool legitimately needs.
const box = new ExecutionContainer({
identity: "agent://billing-reconciler", // attributed to an Entra-backed agent identity
policy: {
filesystem: { read: ["/workspace"], write: ["/workspace/out"] },
network: { egress: ["api.stripe.com:443"] }, // nothing else resolves
syscalls: "default-deny",
},
});
const result = await box.run(async () => {
// model-generated / tool-call code executes here, under the policy above
return await runAgentTool(input);
});The shape is the lesson even if you never touch MXC specifically: the unit of isolation is one tool, and the default is deny. A reconciliation tool that only ever needs /workspace and one API host should not be able to read ~/.aws/credentials or open an arbitrary socket, and the policy is where you say so.
What it costs#
Nothing to adopt. MXC is MIT-licensed, the repo is public, and the SDK is free on npm; your only cost is the compute you were already going to run. The version embedded in the OS ships broadly with Windows 11 26H2 (slated for Q4 2026), but the cross-platform SDK works today. Compare that to a dedicated microVM vendor, where isolation is a per-second line item — a real trade, but one you make on purpose rather than by default.
The founder read#
Treat MXC as the local-first floor of your agent's security posture, not a replacement for the cloud sandbox market. It answers the question every team hits the first time an agent runs generated code on a laptop or a CI box: how do I keep this from touching what it shouldn't, and prove who ran it, without buying a runtime? That it's MIT and already carrying GitHub Copilot CLI's process isolation means it's a floor you can stand on now — and it pushes the whole zero-trust-for-agents posture down into the OS, where boundaries are cheapest to enforce. When the untrusted code moves to your cloud, graduate the risky tier to a microVM; until then, stop hand-rolling the jail.
