Microsoft announced on 7 October 2026 that Microsoft Execution Containers (MXC) is generally available: an OS-enforced boundary you wrap around an agent so the policy about what it can read, write and reach lives outside the agent's control. That matters because until now the only enforcement most teams had for a local coding agent was the agent's own prompt and an approval dialog, and neither of those survives a model that decides the fastest route to a green build is editing the production config.
Microsoft's framing in the announcement is that an agent cannot be its own security authority. The example they use is exactly the one that keeps IT leaders up. A coding agent needs read and write on the repo, it needs to read production server configuration to understand the deployment, and it absolutely must not be able to change it. Approval prompts handle the case where a human is watching. MXC handles the case where nobody is.
What MXC actually is
The design choice worth pausing on is the separation between what you want and how it's enforced. You declare the resources a workload needs. MXC maps that to a platform-appropriate backend, so you get AppContainer on Windows, Seatbelt on macOS, and Bubblewrap on Linux for the lightweight process container. Microsoft says developers can apply the same containment model wherever an agent needs to run, from a local device to the cloud, and Windows 365 support for MXC is generally available, so agents can run on Cloud PCs alongside existing work.
The backends vary in strength, and the announcement names four: the process container (Windows 11, macOS, Linux, lightweight, for responsive workloads); the session container (Windows 11 only, runs the agent under a distinct Windows account and session with its own desktop, clipboard, UI and input boundaries); WSLc (Windows 11 only, for Linux-first toolchains); and MicroVM (Windows 11 and Linux, experimental, hardware-backed isolation), while the repository lists further backends including Windows Sandbox, LXC, Hyperlight and IsolationSession.
The clipboard and input isolation is the part people underestimate: The session container separates the agent's desktop, clipboard, UI, input and active session from the user, which the process container's lighter-weight containment leaves alone.
The policy, in the syntax you'll actually write
Five policy areas: containment, process, file system, network and user interface.
{
"version": "1.0.0",
"containment": "processcontainer",
"process": {
"commandLine": "python -c \"open('C:\\\\temp\\\\output.txt', 'w').write('test')\""
},
"filesystem": {
"readwritePaths": ["C:\\temp"],
"deniedPaths": ["C:\\Windows\\System32"]
}
}
There are three path lists, readwritePaths, readonlyPaths and deniedPaths. Omitted means most restrictive, so adding a field opts in to a capability instead of carving an exception out of a permissive default. That is the right default and it is also why your first run will fail in ways that look like bugs.
Networking is directional and it is strict. Egress rules take CIDR, protocol and port, with no hostnames:
{
"version": "1.0.0",
"containment": "processcontainer",
"network": {
"egress": {
"default": "deny",
"allow": [{
"to": [{ "cidr": "140.82.114.6/32" }],
"ports": [{ "protocol": "tcp", "port": 443 }]
}]
},
"ingress": { "default": "deny", "hostLoopback": "deny" }
}
}
No hostnames means no *.githubusercontent.com in your allow list. For anything with rotating IPs you point runtimeConfig.networkProxy at a caller-managed HTTP/S endpoint on loopback and let the proxy own destination filtering; direct egress rules and a runtime proxy cannot be combined. The identity-less variant that opens both loopback directions is documented as a development and testing deployment, and the schema doc is blunt that it does not verify which process owns the endpoint.
Its policy must declare all three directional values as allow explicitly, and an absent or mixed network object is rejected. The strongest desktop isolation on offer comes with the weakest network posture.
From Node, you skip the JSON. The SDK README shows the typed path, and the SDK picks the contract version for you:
import { run, getPlatformSupport } from '@microsoft/mxc-sdk/v1';
if (!getPlatformSupport().isSupported) {
throw new Error('MXC is not available on this host');
}
const output = await run({
filesystem: { readonlyPaths: [process.cwd()] },
network: { egress: { default: 'deny' } },
timeoutMs: 30_000,
command: 'node -e "console.log(1)"',
});
Build the policy by watching, not by guessing
The honest problem with least privilege is that nobody knows the full resource list for an agent workload before it runs. MXC answers that with three modes. Permissive allows it and records it, so you can finish the task while collecting evidence about what it touched.
Audit mode is a separate executor flag and sits outside the three operating modes, and the README warns that --audit turns off all sandbox security for the workload being analysed, so it is for tightening the policy around a tool you already trust, never for running untrusted code.
Run permissive on real tasks, diff the activity reports, promote the paths that show up every time, then move to learning so the gaps become visible failures instead of silent grants.
What it costs and what it requires
There is no MXC licence line. On Windows the cost is Windows 11: GitHub documents local sandboxing as requiring Windows 11 version 25H2 with update KB5124010 or later, or version 26H1 with update KB5124006 or later, with support for the BaseContainer tier of the ProcessContainer backend. GitHub documents that local sandboxing on Linux requires Bubblewrap (bwrap) version 0.5.0 or later and slirp4netns installed and available on PATH. If your Windows fleet is below the versions GitHub lists for local sandboxing, Windows 11 25H2 with KB5124010 or 26H1 with KB5124006, the containment story starts with a fleet upgrade.
Central management is still unfinished. Today you get a boundary each agent developer declares; the organisational overlay that makes it consistent across a company is still ahead.
The edges of what MXC covers
MXC contains a process. It does not contain a model's judgement about data it has already been given, and it does not reach the parts of your agent that are running outside contained child processes. The built-in tools check the policy themselves on a best-effort basis. Any agent you contain will have the same shape of hole wherever it does work in its own process without spawning a child.
If your agent calls a hosted tool that queries a warehouse, the containment boundary stops at the network call and whatever that tool is authorised to do is what gets done. For agents working over company data, the authorisation that matters is in the data platform.
Third: this is local execution containment. An agent architecture where the model and tools run in a managed cloud service gets nothing from MXC. It's for the laptop, the build agent, the Cloud PC.
Microsoft says GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio and Unsloth AI already support MXC, with Anthropic Claude Code, Box, Egnyte, Heidi Health, Hermes Agent by Nous Research, Manus, Perplexity, Raycast and Simular among those releasing support.
Turn on local sandboxing in Copilot CLI this week
You'll find out which of your build steps reach outside the working directory, and that list is the first draft of the policy you'd write for any agent you build yourself.
Frequently asked questions
Is Microsoft Execution Containers free?
What operating systems does MXC support?
How is MXC different from running an agent in Docker?
MXC declares a resource policy covering files, network destinations and UI access, which the OS enforces outside the workload's control, and then picks a backend ranging from a lightweight process sandbox to a MicroVM, so you can contain an agent that still needs to work in your actual working directory instead of a copied-in image.
Can MXC control what an agent reads from a database or warehouse?
No, MXC cannot control which rows an agent reads from a database or warehouse. Its network policy can block or allow a destination by CIDR, protocol and port, but once a connection is permitted the rows returned are decided by the credentials and the data platform's own authorisation.