Microsoft Execution Containers: Sandbox AI Agents at the OS Level

Microsoft Execution Containers (MXC) went generally available on October 7. If you’re building or running AI agents on Windows and you’re not familiar with it, now is the time. MXC is an OS-level sandboxing layer designed specifically for agents — not applications, not containers in the Docker sense. The distinction is architectural. Docker shares a kernel with the host. MXC doesn’t trust the agent enough to let it anywhere near the kernel directly. GitHub Copilot, OpenAI Codex, Replit, LM Studio, Unsloth AI, OpenClaw, and NVIDIA OpenShell already ship with MXC integration. Claude Code is listed as coming. The repository is on GitHub under an MIT license, and the Node, Rust, and .NET SDKs are all available today.

Why Docker Isn’t Enough for Agents

The problem with standard Docker containers for agent workloads is kernel sharing. A Docker container gives you filesystem and process isolation, but the agent still runs against the same OS kernel as the host. That’s a reasonable tradeoff for trusted application code. It’s a poor tradeoff when the thing running inside can generate its own scripts, install packages, and execute arbitrary commands — which is exactly what most AI agents do.

MXC’s design principle is blunt about this: “an agent cannot be its own security authority.” The policy that defines what the agent may access lives outside the agent process and is enforced by the OS kernel. The agent cannot reason, persuade, or prompt-inject its way past it. That’s a meaningful security primitive that Docker containers don’t provide for agent workloads.

Four Isolation Tiers

MXC offers a tiered isolation model. Which tier you choose depends on how much you trust the code being executed and how much startup latency you can tolerate:

• ProcessContainer (AppContainer) — The default and fastest option. Uses Windows AppContainer for kernel-enforced process isolation. Good for development environments and low-risk agent tasks.
• Session Container / IsolationSession — Full desktop session isolation. Designed for long-running agents that need persistent state across multiple operations.
• WSLC — Runs a Linux agent environment inside Windows with WSL-level isolation. Useful if your agent toolchain is Linux-native but your deployment target is Windows.
• MicroVM (Hyperlight/NanVix) — Still experimental. Full virtual machine isolation for high-risk or hostile code. The right choice for agents executing untrusted third-party plugins.

The default ProcessContainer backend works on all three supported platforms (Windows 11, Linux, macOS) via AppContainer, Bubblewrap, and Seatbelt respectively. The Windows-only options — WSLC, IsolationSession, MicroVM — require Windows 11 Build 26100 (24H2).

Getting Started: 10 Lines of TypeScript

The Node SDK is the most complete and best-documented. Install it from npm:

npm install @microsoft/mxc-sdk

For a one-shot agent command — run a script in a sandbox and get the output:

import { spawnSandboxFromConfig, createConfigFromPolicy } from '@microsoft/mxc-sdk';

const config = createConfigFromPolicy({
  version: '0.6.0-alpha',
  filesystem: { readwritePaths: ['/tmp/work'] },
  network: { allowOutbound: false },
  timeoutMs: 30_000,
});

const result = await spawnSandboxFromConfig(config, 'python analyze.py');
console.log(result.stdout);

The policy covers five domains: containment type, process parameters, filesystem access (deny-by-default — everything not listed is blocked), network access, and UI access (clipboard, display, input injection). Start restrictive and widen as needed. For multi-step agents that need to persist state, MXC provides a stateful lifecycle API: provisionSandbox(), execInSandboxAsync(), and deprovisionSandbox().

The Catch: Enforcement Mode Has No Logs

MXC’s production operating mode — Enforcement — generates zero activity reports. When the OS blocks an access attempt, nothing is logged by MXC. You’ll only catch it if your EDR picks it up. MXC does offer two other modes: Learning (blocks and records denials to a JSON report) and Permissive (allows but records what would have been blocked). Run in Learning or Permissive mode first to profile your agent’s actual resource needs. Lock down to Enforcement only after you’ve verified the policy against real workload behavior. Skipping that step and going straight to Enforcement is how you end up with a silently broken agent.

The Enterprise Gap

MXC shipped without the enterprise management layer it was supposed to include. Three features were announced and have no delivery dates: Intune policies for MXC process container management, Entra ID separation (distinguishing agent activity from user activity in audit logs), and Agent 365 on-device controls. Right now, only the agent developer can set container policy — not your IT department. For enterprises deploying third-party agents on employee machines, that’s a gap worth understanding before rolling out. Microsoft acknowledges it without a timeline.

Worth Using Today

The missing enterprise tooling is a real limitation. It doesn’t change the value for agent developers who want to do this responsibly. Seven agents already ship with MXC, nine more are adding support, and the official announcement positions MXC as a foundational primitive for other security tooling to build on — which is accurate. It’s not a complete solution today. It is a well-designed foundational layer that solves a real problem Docker-style containers don’t solve for agent workloads on the desktop.

For a broader look at where MXC fits in the 2026 agent sandboxing landscape — including cloud-native alternatives like Google Agent Sandbox and E2B — that guide is worth reading alongside the MXC docs.