Microsoft Execution Containers (MXC) Is Now GA: Sandbox AI Agents

Microsoft Execution Containers (MXC) went generally available on October 7. It is an OS-enforced sandbox for AI agents: you declare which files, network endpoints, and system resources your agent can access, and the Windows kernel holds that line no matter what the agent decides to do. GitHub Copilot CLI, OpenAI Codex, Replit, LM Studio, Unsloth, and OpenClaw are already integrated. The enterprise management layer — Intune policy, Entra agent identity — is not ready yet, which is worth understanding before you build on it.

Why This Exists Now

The timing is not accidental. The last two weeks have surfaced a steady stream of rogue-agent incidents: agents leaking credentials, executing unintended commands, and in at least one documented case, returning content no sandbox would have allowed out. Satya Nadella called for an AI emergency brake last week. MXC is the technical implementation of that instinct — not a policy document, an actual enforcement layer.

Logan Iyer, Microsoft’s CVP of Windows Platform and Developer, framed it directly in the official announcement: “An agent cannot be its own security authority and must run in a boundary enforced independently of the agent.” That sentence is the whole product. Every existing approach — system prompts, guardrails, app-level restrictions — relies on the agent or the app itself to honor limits. MXC removes that dependency. The OS kernel enforces the policy. The agent’s opinions about it are irrelevant.

What MXC Actually Controls

The containment policy covers three resource types:

• Filesystem — readonlyPaths, readwritePaths, and deniedPaths. The agent can only touch what you explicitly permit.
• Network — outbound traffic restricted to a domain allowlist. Default: deny all outbound.
• Processes — whether the agent can spawn child processes.

On Windows, enforcement uses AppContainer capability SIDs and Hyper-V micro-VMs depending on isolation level. On macOS it uses Seatbelt profiles; on Linux, native process sandboxing. The TypeScript SDK and JSON config are identical across all three platforms. That unified API is genuinely new — before MXC, achieving equivalent cross-platform containment meant gluing together three different native security primitives.

How to Use It

Install the SDK:

npm install @microsoft/mxc-sdk

A minimal sandbox that locks the agent to read-only tool access, a temp write directory, and no outbound network:

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

if (!getPlatformSupport().isSupported) {
  throw new Error('MXC not available on this host');
}

const tools = getAvailableToolsPolicy(process.env);
const temp  = getTemporaryFilesPolicy();

const config = createConfigFromPolicy({
  version: '0.6.0-alpha',
  filesystem: {
    readonlyPaths:  tools.readonlyPaths,
    readwritePaths: temp.readwritePaths,
  },
  network: { allowOutbound: false },
  timeoutMs: 30_000,
});
config.process!.commandLine = 'python agent.py';

const child = spawnSandboxFromConfig(config, { usePty: false });
child.stdout!.on('data', (d) => process.stdout.write(d));

MXC ships with three operating modes. Enforcement blocks anything not in the policy. Learning mode blocks and records denied operations to a JSON activity report — use this to understand what an existing agent actually needs without breaking it. Permissive allows everything but records ungranted access — useful during initial policy authoring when you want the agent to run to completion while you build the minimal policy. The recommended workflow: start permissive, run the agent through real tasks, review the report, trim to exactly what is needed, then switch to enforcement.

The Part That Is Not Ready

MXC shipped GA before its enterprise management layer was built. Centralized Intune policy for MXC process containers on Windows 11, Entra agent identity (separating agent activity from user activity in audit logs), and Agent 365 controls for local agents are all listed as “coming soon” with no dates attached. Until those ship, the developer writes the containment boundary. An organization deploying agents across a Windows fleet today cannot centrally mandate or audit MXC policies — they have to trust each tool’s implementation.

That is a real limitation. But it does not make MXC useless now. If you build an agent tool that ships to Windows, integrating MXC today means your users get containment immediately and will automatically fall under enterprise management policy the moment Microsoft ships Intune support. You are ahead of the compliance requirement rather than scrambling to meet it later.

A Note on the Skepticism

The Hacker News thread when MXC landed had a predictable shape: roughly 60% of comments pointed out that AppContainer, bubblewrap, and SELinux have existed for years. That is technically correct. MXC’s value is not novel isolation primitives — it is the policy abstraction layer that works across Windows, macOS, and Linux without requiring developers to learn three different security APIs. Whether that abstraction is worth a Microsoft dependency is a fair question. For shops already deep in the Windows ecosystem, the answer is probably yes.

Bottom Line

If you ship agent tooling on Windows, add MXC now. The SDK is stable, major tools have already integrated it, and getting containment right before the Intune policy layer ships puts you ahead rather than scrambling to retrofit it later. The enterprise story has gaps, but those gaps are Microsoft’s to close. The design principle — enforcement independent of the agent — is correct regardless of who implements it.