Microsoft Execution Containers Bring OS-Level Sandboxing to AI Agents on Windows and Linux

Microsoft released an early preview of Microsoft Execution Containers (MXC), a cross-platform SDK that lets developers define what AI agents can access and do while Windows enforces those constraints at runtime. The open-source project, announced at Build 2026 in June and now available on GitHub, supports Windows, Linux, and macOS with multiple containment backends ranging from lightweight process sandboxes to full virtual machines.

The release addresses a problem that has grown alongside agent adoption: AI agents generate and execute code at runtime, often chaining multiple operations together, and they typically do so with the same permissions as the user who launched them. “Agent behavior is dynamic and often generated at runtime,” wrote Dana Huang, Corporate VP of Windows Security, and Logan Iyer, Corporate VP of Windows Platform and Developer, in the Windows Developer Blog. “Containment bounds what agents can access and do, so non-deterministic behavior doesn’t translate into uncontrollable risk.”

The Containment Spectrum

MXC’s core design principle is composability. Rather than offering a single sandbox model, the SDK exposes a unified JSON configuration schema that maps to different isolation mechanisms depending on the workload. A coding agent running quick iterations needs different guardrails than an enterprise data-processing agent handling sensitive records. MXC abstracts that difference behind one policy model.

The early preview ships with two containment options ready for production use, according to Help Net Security.

Process isolation runs AI-generated code in a separate environment with restricted access to files and network resources. The approach is fast and lightweight, designed for development workflows where responsiveness matters. GitHub Copilot CLI already uses MXC process isolation to constrain what dynamically generated code can access and execute.

Session isolation goes further, separating the agent’s execution from the user’s desktop, clipboard, input devices, and active sessions. Each session runs under its own identity, backed by either a local account or a cloud-provisioned identity through Microsoft Entra. This enables least-privilege access, full auditability, and policy enforcement through Intune. The initial release supports non-interactive sessions.

Two additional containment modes are on the roadmap. Micro-VM support will use hardware-backed virtualization through the hypervisor to provide stronger isolation for high-risk workloads like processing sensitive data or running untrusted external code. Linux container support through WSL will extend the same containment model to Linux-based AI development environments, covering the ML frameworks and package ecosystems that most agent toolchains depend on.

The GitHub repository lists additional backends: Windows Sandbox, LXC, Bubblewrap, Seatbelt (macOS), Hyperlight, and a NanVix micro-VM implementation. The SDK provides filesystem policies (read-only and read-write path lists), network policies (proxy support, outbound filtering), and UI policies (clipboard, display, and GUI access controls).

Where Agent 365 Fits

MXC is the enforcement layer. Agent 365 is the management and observability layer that sits on top of it.

Microsoft’s security blog post from Build 2026, authored by Aleš Holeček, President and Chief Architect of Microsoft Security, positioned MXC within a broader security stack: MDASH for vulnerability discovery, Defender and GitHub Code Security integration for risk-based prioritization, and Agent 365 for agent governance. The Agent 365 SDK provides observability, access control, and compliance features. MXC provides the OS-level isolation that Agent 365 policies reference.

The Windows Developer Blog noted that Agent 365 can already “discover and manage local agents on Windows, starting with OpenClaw agents and expanding soon to other widely used agents like GitHub Copilot CLI and Claude Code.” With MXC, those discovered agents can be assigned specific containment profiles through Entra and Intune. An IT team could require, for example, that all OpenClaw agents on corporate devices run inside session isolation with filesystem restrictions and no clipboard access.

Partner Integrations

Five companies are named as MXC launch partners: OpenClaw, NVIDIA, OpenAI, Hermes, and Manus.

OpenClaw now uses MXC to secure its node and gateway, alongside a Windows companion app for deploying and managing agents. NVIDIA has integrated MXC into OpenShell for secure deployment of autonomous AI agents on Windows. Hermes Agent plans to add OpenShell and MXC support to its Windows application.

David Wiesen, Member of Technical Staff at OpenAI, said in a statement to Help Net Security: “Working with Microsoft on Microsoft Execution Containers (MXC) allows us to explore new patterns for AI agents to safely and efficiently generate and execute code. By combining Codex’s capabilities with MXC’s execution environment, we aim to help developers move from intent to reliable execution faster while maintaining the security and control enterprises need.”

The Structural Problem MXC Targets

The timing is not accidental. Over the past three months, the agent security surface has expanded rapidly. SkillCloak researchers demonstrated that malicious agent skills can evade automated scanners at rates above 90%. North Korea’s Sapphire Sleet compromised the Mastra AI npm supply chain. The T3MP3ST framework showed how general-purpose coding agents can be repurposed as autonomous red-teaming operators. Palisade Research documented frontier models resisting shutdown at rates up to 97%.

Each of these attack vectors exploits the same structural gap: agents run code with user-level permissions and no containment boundary between the model’s output and the operating system’s resources.

MXC’s approach treats this as an OS-level problem rather than an application-level one. Instead of asking every agent framework to implement its own sandbox (with the inconsistencies and escape paths that implies), Microsoft is providing containment primitives that Windows itself enforces. The agent framework declares what it needs. The OS constrains everything else.

The GitHub README carries a warning that reflects the project’s maturity: “There are known cases where the current policies generated by the MXC SDK in this repository are overly permissive and will be addressed before this is made more generally available. No MXC profiles should be treated as security boundaries currently.”

Cross-Platform Coverage and Limitations

The SDK supports Windows 11 24H2 and later, Linux x64 and ARM64, and macOS ARM64 and x64 (as of schema version 0.7.0-alpha). On Windows, the default backend is ProcessContainer. On Linux, it defaults to Bubblewrap. On macOS, it uses Seatbelt.

Not all policy aspects work on all platforms yet. Network filtering is not yet supported on the Windows ProcessContainer backend. Filesystem deny-path lists are not yet supported on Windows. Proxy support is not available on macOS. The experimental backends (Windows Sandbox, WSLC, micro-VM, Hyperlight, isolation session) require an explicit experimental flag.

The project is built in Rust (version 1.93, pinned via toolchain file) with a TypeScript SDK published as @microsoft/mxc-sdk on npm. The state-aware lifecycle model (provision, start, exec, stop, deprovision) supports long-running session sandboxes, while a simpler one-shot API handles ephemeral execution.

The Enterprise Calculus

For enterprise teams evaluating agent deployments, MXC changes the procurement conversation. Previously, agent containment was a feature of specific agent frameworks. OpenClaw had its own sandbox. Claude Code had its own isolation. Copilot had its own boundaries. Each was implemented differently, audited separately, and governed through different policy mechanisms.

MXC proposes a single policy surface that IT teams already know how to manage (Entra, Intune, Group Policy) applied uniformly to any agent that integrates with the SDK. Whether the agent is OpenClaw, Copilot CLI, Codex, or a custom internal tool, the containment rules come from the same place and the audit logs go to the same destination.

Windows 365 for Agents extends this further into the cloud, running agents in Intune-managed Cloud PCs that are fully separate from the user’s machine. If an agent is compromised, the blast radius is contained to a disposable cloud instance.

The question is adoption speed. MXC requires agent frameworks to integrate the SDK. The five launch partners represent major players, but the long tail of agent tools, internal scripts, and custom harnesses will take longer to reach. Until then, the containment is only as broad as the integration list.

Microsoft’s bet is that making containment an OS primitive, rather than an application feature, will create enough gravitational pull to bring the ecosystem along. The early-preview caveats and known-permissive policies suggest the engineering is not finished. But the architecture, a composable sandbox with policy-driven isolation that the OS enforces regardless of what the agent framework does, addresses the right structural gap at the right time.