Windows Execution Containers: OS-level isolation for autonomous agents

What is this?

On June 2, 2026, at Build 2026, Microsoft published Windows platform security for AI agents, announcing an early preview of the Microsoft Execution Containers (MXC) SDK — a cross-platform, policy-driven execution layer for AI agents on Windows and WSL. The pitch is a structural one: rather than asking every agent framework to reinvent sandboxing, MXC pushes containment, identity and policy enforcement down into the operating system, where they can be applied consistently at runtime.

The move responds to a problem this site has covered from many angles — that an autonomous agent which reads files, invokes tools and generates its own code at runtime inherits the full authority of the user’s session unless something actively bounds it. MXC is Microsoft’s attempt to make that boundary a first-class OS primitive rather than an afterthought bolted onto each application.

How it works

The core idea Microsoft calls the composable sandbox: one policy model and SDK that maps to different isolation constructs depending on how risky the workload is. A developer declares what to constrain, and Windows enforces it, so nobody has to hand-roll low-level isolation. Two containment tiers ship in the early preview.

Process isolation is the lightweight tier. It runs model-generated code inside a dedicated process boundary that restricts access to files and network domains outside a defined policy, while keeping the developer inner loop responsive. GitHub Copilot CLI has already adopted this mode to constrain what its dynamically generated code can touch.

Session isolation is the stronger tier. It separates the agent’s execution from the human user’s interactive desktop, clipboard, UI and input devices — mitigating UI spoofing, input injection and cross-session data leakage. Crucially, sessions run under distinct user accounts: Windows assigns each agent a local or Entra-backed identity and attributes all of its activity to that identity, so human and agent actions are cleanly separable and auditable. Access policy is applied through Microsoft Entra and Intune, which is how enterprises govern the guardrails centrally.

Microsoft’s roadmap extends the same SDK to micro-VMs (hypervisor-backed isolation aimed at higher-risk or untrusted-code workloads, explicitly framed as a response to research showing LLMs developing sandbox-escape capabilities), to Linux containers via WSL, and to Windows 365 for Agents, where a compromised agent’s blast radius is confined to a disposable Cloud PC. The SDK is public on GitHub.

Why it matters

Containment is one leg of the lethal trifecta: if an agent that ingests untrusted content and can act is going to be safe, something has to bound what “act” means. Historically that job fell to each framework, unevenly — which is exactly why coding-agent RCE and privilege-boundary failures keep recurring. Standardizing containment at the OS level, with a per-agent identity that makes actions attributable, is the kind of structural change that raises the floor for everyone rather than patching one product at a time.

The caveats are equally structural. MXC is an early preview, initial session support is non-interactive, and the strongest boundary — the micro-VM — is still on the roadmap, not shipping. Process isolation is described as moderate strength by Microsoft’s own framing; it is not a hypervisor wall. And OS-level containment addresses the action leg of the trifecta, not the injection leg: an agent confined to a policy can still be steered into misusing whatever authority that policy grants it. Windows Defender’s new prompt-injection detection is a complementary control, not a substitute for treating retrieved content as untrusted.

Defenses

Treat MXC as a foundation to build on, not a finished guarantee. Match the containment tier to the workload: process isolation for responsive coding agents, session isolation (with its distinct user account and full auditability) for long-running automation that runs alongside a human, and plan for micro-VM or Cloud PC isolation when an agent processes sensitive data or runs untrusted code. Wherever possible, give each agent its own identity and apply least-privilege filesystem and network policy through Entra and Intune, so that agent activity is attributable and revocable independently of the user. Keep defense-in-depth: pair containment with input-side controls — untrusted-content handling, output filtering and injection detection — because a well-contained agent can still be tricked into misusing its allowed capabilities. Finally, since these features live in Insider builds and previews, pilot them before depending on them, and do not let “OS-enforced” become a reason to hand an agent broader authority than it needs.

Status

MXC was announced on June 2, 2026 at Build 2026 by Dana Huang and Logan Iyer (Microsoft), with the SDK released as an early preview on GitHub and process/session isolation targeted for Windows Insider builds shortly after Build. This is a defensive platform contribution, not a vulnerability disclosure — there is no CVE and no exploit attached. Ecosystem partners cited by Microsoft include GitHub Copilot CLI (process isolation, shipping), NVIDIA’s OpenShell, OpenClaw, OpenAI’s Codex, Manus and Nous Research’s Hermes Agent. Read it as evidence that agent containment is moving from framework-level improvisation toward an OS-level primitive — a direction worth tracking, and testing, before trusting.