Microsoft Execution Containers for AI Agents Explained: Shipping Features vs. Roadmap

During a pre-briefing the night before Build 2026, a Microsoft developer instructed an AI agent to delete all the files on his desktop. The agent appeared to comply. The desktop looked clean. "That's a lie," the developer said the files were fine because, as he explained, "the container won't allow it," according to VentureBeat, which attended the briefing. That demonstration captures the promise of Microsoft Execution Containers for AI agents in one clean image. It also raises the question worth answering precisely: how much of that protection is real and available today, and how much is still coming?

The short answer is that the SDK is in early preview, the two lightest isolation modes are shipping, and Microsoft's own README states plainly that "no MXC profiles should be treated as security boundaries currently," according to Origin's code-level analysis published days after the announcement. That caveat runs through everything that follows.

For developers, MXC offers a usable policy model for least-privilege agent execution right now. For enterprise security teams, it offers identity binding and governance hooks that are real but preview-grade not certified boundaries for regulated or high-assurance workloads. The heavier isolation tiers that would change that calculus are experimental or still on the roadmap.

What Microsoft Execution Containers for AI agents actually do on Windows

The problem MXC addresses is structural. When an AI agent executes model-generated code, it typically does so with the same OS-level permissions as the user who launched it full access to files, the clipboard, the network, everything the user can reach. MXC is Microsoft's answer. Developers write a policy file declaring what the agent is permitted to touch; Windows selects and enforces the appropriate containment boundary at runtime.

The Windows Developer Blog described the SDK at launch as "an abstraction layer across isolation primitives, so developers do not have to manage low-level isolation details" introduced at Build as "a cross-platform, policy-driven execution layer for agents on Windows and WSL." Policy is written in JSON or YAML. Enforcement is handled by the OS. Sensitive capabilities clipboard access, audio, webcam are blocked by default unless explicitly enabled, and individual file paths and network domains can be permitted or denied, according to Joche Ojeda's technical breakdown published last month.

At the code level, MXC ships as a single native binary paired with a TypeScript SDK (@microsoft/mxc-sdk) that builds policy configs and calls the binary. A single field in the config selects the isolation backend the same policy definition maps to different underlying primitives depending on workload and what the host OS can support, per Origin's code analysis from early June. The codebase includes Linux and macOS backends, but that is engineering work visible in the repository; the shipping story is Windows and WSL. Cross-platform parity is direction, not current capability.

Two specific threat classes are in scope. Session isolation cuts off agent access to the user's interactive desktop, clipboard, UI, and input devices removing the surface for UI spoofing and input injection. Prompt injection monitoring hooks Defender before tool use, after tool use, and at prompt submission, with detections flowing into the Defender portal for security operations response, as demonstrated at the Build 2026 session. Cross-session data leakage is addressed by running agents under distinct Windows user accounts, with containers that, according to Ojeda, "share no kernel objects with the host."

The isolation ladder: what's shipping, what's experimental, what's roadmap

MXC is not a single isolation mode. Ojeda describes it as a ladder developers climb based on how much they trust a given workload. The maturity of each rung varies considerably, and that variation is where Microsoft's own "not a security boundary" disclaimer becomes concrete.

The current status of each tier, drawing on both Microsoft's documentation and Origin's code review:

• Process isolation lightweight containment within the user's session, restricting file and network access. Shipping. Ojeda notes that GitHub Copilot CLI already uses this mode, though that claim comes from Ojeda's analysis rather than a primary Microsoft source.
• Session isolation separates the agent from the interactive desktop, clipboard, UI, and input devices; runs under a distinct Windows user account. Microsoft's documentation describes it as part of the initial early preview release shortly after Build. Origin's code review labels the underlying isolation_session backend experimental. The safest read: announced, demoed, and available in preview, but not a stable boundary.
• Windows Sandbox, WSL2 micro-VM (wslc), Hyperlight micro-VM stronger VM-backed isolation tiers. Experimental, per Origin's analysis.
• Micro-VM and Linux container tiers higher-assurance hardware-backed separation for higher-risk workloads. Roadmap, per both Ojeda and the Windows Developer Blog. Not production-available.

The processcontainer default backend resolves at runtime to the strongest tier the host can satisfy, falling back through three tiers BaseContainer, AppContainer with block-filter policy, AppContainer with DACL based on available OS APIs, per Origin's code review.

Two execution models coexist in the codebase. A one-shot model provisions, executes, and tears down a container on every invocation. A stateful lifecycle model exposes five phases provision, start, exec, stop, deprovision for long-running agent sessions. Only Isolation Session implements the stateful model today, according to Origin. For most current backends, agent state does not persist between executions.

Early internal benchmarks under 5% CPU overhead, 40–60 MB memory per container, sub-200ms launch time were cited by Ojeda and echoed directionally by the Build session, which described sub-second startup. These are not independently verified numbers. Ojeda frames them as evidence of a core architectural goal: making hypervisor-grade isolation cheap enough to use like a container. That goal has not yet been validated in production.

The Windows Sandbox backend is worth specific attention. It uses a full, throwaway Windows VM the strongest currently experimental tier on Windows. But Origin's analysis flags two preview-grade rough edges: teardown uses taskkill /F /IM, a system-wide process kill, and the VM is reused across executions, meaning side effects from one agent run can persist into the next. The VM boundary exists; the implementation around it is unfinished.

The enterprise layer: identity, governance, and what's actually live

Containment determines what an agent can touch. Governance determines who authorized it, what it did, and whether those actions can be reviewed. Microsoft's enterprise pitch is that both are connected through the same MXC policy model. The two layers have different maturity timelines, and that distinction matters.

Session isolation assigns each agent either a local Windows ID or a cloud-provisioned identity backed by Microsoft Entra. Every file access and process action is attributed to that agent identity rather than to the human user, as the Windows Developer Blog explained at launch. The Build 2026 demo showed this in practice: an agent running under its own Entra account, visible as a distinct user in Windows Task Manager, with Defender threat detections tied to that agent identity in the portal. That capability is demonstrated and available in preview; Microsoft describes it as part of the initial release.

Fleet-level controls are also available. IT teams can use Intune policies to mandate MXC isolation across devices and enforce filesystem access rules, making containment a managed enterprise control rather than a per-developer choice, according to the Windows Developer Blog. Windows 365 for Agents, which reached general availability at Build, extends this further: agents run in fully isolated Intune-managed Cloud PCs, so a compromised agent is contained to a disposable cloud instance with no direct path back to the user's local device, per the Microsoft Security Blog.

The broader Agent 365 integration connecting Defender runtime protection, Entra identity management, Intune device policy, and Purview data governance under a unified MXC policy model was scheduled for July preview, as reported at Build. That integration is arriving this month. Its governance claims remain forward-facing until the preview ships and can be independently evaluated.

Partner endorsements from OpenAI, Nvidia, Manus, and Nous Research confirm that the ecosystem is building toward MXC. They do not validate it as a hardened security boundary. "Developers need control over what an agent can access and trust that those controls will hold," said Dillon Rolnick, CEO of Nous Research, quoted in the Windows Developer Blog. The controls exist. Whether they hold at the level regulated workloads require is a question the current preview cannot answer.

What works now, what to wait on, and what to watch

The SDK is accessible on Windows 11 build 26100 or later with WSL2 kernel 5.15.167.1 or later, distributed via GitHub, NuGet, and PyPI, per Ojeda. Process isolation is stable. Session isolation is in preview, with the maturity caveat noted above. Identity attribution through Entra is demonstrated and available. Windows 365 for Agents is generally available. For developers building agent workflows, that is a real and usable foundation for least-privilege execution meaningfully better than running agents with unrestricted user-level access.

What to wait on: the micro-VM and Linux container tiers that deliver hardware-backed hypervisor separation are not yet production-available. The Windows Sandbox backend's rough edges are unresolved. None of the sources reviewed here cite third-party security audits or independent red-team results. Enterprise security teams should not treat current MXC profiles as hardened boundaries for regulated or high-assurance workloads a position Microsoft's own README supports.

Two milestones will be worth watching. The Agent 365 preview integrating Defender, Entra, Intune, and Purview under a unified MXC policy model is the next concrete marker, as reported at Build. The more telling signal will come when Microsoft removes the security-boundary disclaimer from its README, or when independent researchers publish attempts to validate or break the isolation claims. Until one of those happens, MXC is in an honest position for a preview: the architecture is coherent, the lightest tiers are usable, and the stronger guarantees are still being built.