Microsoft Introduces Execution Containers to Keep AI Agents in Check

AI agents are getting more capable by the month. They can write code, read files, call APIs, and automate multi-step workflows with little human oversight. That capability is exactly what enterprises want — and exactly what keeps security teams up at night.

Microsoft addressed that tension directly at Build 2026, announcing Microsoft Execution Containers (MXC), a policy-driven execution layer built into Windows and the Windows Subsystem for Linux (WSL). The goal is straightforward: Give developers and IT administrators a way to define what an agent can and cannot access, with the operating system itself enforcing those boundaries at runtime.

What MXC Actually Does

MXC is not a product you buy. It is an SDK and a policy model — a foundational primitive embedded in Windows and WSL. Think of it as a declarative boundary system for agents. Developers specify what an agent needs access to — specific files, network resources, system calls — and the OS kernel enforces those limits. Developers and IT administrators describe agent containment requirements once and rely on Windows to enforce them using native operating system primitives, so you can run code more safely without a lot of complicated setup.

MXC is a lightweight virtualization layer purpose-built for agent execution. While Docker containers share the host kernel, MXC provides a hypervisor-backed isolation boundary closer to a mini virtual machine, but with near-native startup times measured in single-digit milliseconds. Each container carries a declarative manifest that specifies the agent’s required permissions.

That’s a meaningful distinction from traditional containers. MXC isn’t trying to compete with Kubernetes or Azure Container Apps. It’s designed specifically for the agentic workload problem — autonomous software that operates on behalf of users and needs firm guardrails.

Enterprise Security Integration

Agent 365 native integration with MXC enables agents running on Windows to start secure and stay secure. Integration will deliver Defender, Entra, Intune, and Purview protections, so security and IT teams can constrain and secure local agents to prevent enterprise risk, with availability in preview in July.

That integration matters. Most enterprises already manage endpoint security through some combination of those tools. Plugging MXC into that existing stack means security teams don’t have to build new workflows from scratch. They can apply familiar policy frameworks to AI agents running locally on Windows devices.

MXC will ship first in Windows 11 version 24H2 (Enterprise and Pro editions), with Windows Server 2027 following later in 2026. A preview is available immediately for Windows Insiders in the Dev Channel. The hardware requirements — a CPU with virtualization-based security (VBS) and second-level address translation (SLAT) — are standard on most modern business machines, so adoption shouldn’t require a hardware refresh for most organizations.

Why This Matters Now

The timing isn’t accidental. Agentic AI has moved from proof-of-concept to production pipelines faster than most security frameworks have been able to keep up. Agents are becoming useful enough to run code, read files, call networks, and automate workflows, but most companies still do not want them operating with the full authority of a logged-in employee.

That gap — between what agents can do and what companies are comfortable letting them do — is where MXC is designed to operate. The most important thing Microsoft said at Build is not that Windows can make agents trustworthy; it is that agents need containment, identity, and manageability before trust is even a serious conversation.

The ecosystem backing is also worth noting. OpenClaw is running securely on Windows with MXC. NVIDIA is bringing OpenShell to Windows through MXC. Hermes, Manus, and OpenAI are listed as ecosystem partners. Early partner depth at this stage signals that Microsoft isn’t positioning MXC as a proprietary lock-in play — it’s designed to work with agents built on any model or runtime.

Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at The Futurum Group, sees identity as the critical piece. “Microsoft Execution Containers (MXC) is strategically important as it moves agent containment into the operating system as a runtime primitive, making Windows the enforcement layer for agents,” Ashley said. “Identity attribution is the load-bearing element that binds every agent action to a scoped, auditable identity. Agent builders and platform teams now design against an OS-enforced permission and identity model, declaring capability scope at build time. With preview containment not yet a security boundary, the binding question becomes which identity an agent acts under and what it is provably scoped to access.”

Still Early

MXC is in preview, and the full picture will take time to develop. Future updates will bring deeper integration with Microsoft’s AI toolchain. A Copilot Runtime SDK update will allow developers to annotate functions with required MXC capabilities, so that container policy is automatically generated at build time. There are also plans to support nested containers, allowing an agent to spin up its own isolated sub-agents within a parent MXC enclosure.

The direction is clear, even if the details are still filling in. Microsoft is making a deliberate bet that Windows becomes the preferred runtime for enterprise AI agents — not just a platform where agents happen to run, but one that actively enforces the security policies organizations require.

For security and platform teams evaluating where to deploy local AI agents, MXC is worth a close look. The preview is now available to Windows Insiders in the Dev Channel.