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's coverage of 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, process isolation is usable in the current SDK, while session isolation remains preview-grade and partly experimental, 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, such as clipboard access, audio, and 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. Microsoft's launch story is Windows and WSL, while the public repo also describes Linux and macOS backends in the early-preview codebase. Cross-platform parity is a direction, not a 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. Defender provides real-time protection against prompt injection and other emerging agent threats, with detections available to security teams. 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 is 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 and 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_sessionbackend 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.Micro-VM support remains on the roadmap.
Linux support is split: the public repo lists Linux
bubblewrap/lxcbackends, while Microsoft's Windows launch blog describes Linux containers via WSL as roadmap work."
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, and 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, and 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.
Microsoft says Agent 365 now provides native integration with observability, governance, and security capabilities for agents running on Windows, including MXC and Windows 365 for Agents. 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 public repo lists Windows processcontainer support at Windows 11 24H2 build 26100+, with isolation_session requiring build 26300.8553 Insider Preview; the SDK is available as the @microsoft/mxc-sdk npm package.
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.
Comments
Be the first, drop a comment!