Windows hasn't been the interesting part of the AI developer story for the past two years. At Build 2026, Microsoft made a serious case for why that changes now — and the core of the argument isn't dev tooling or on-device models. It's agent containment enforced at the operating system level.
The Problem Agents Actually Create
Agentic AI tools have been shipping fast and the security architecture around them has been improvised. Most agent runtimes run with whatever permissions the user has. They call APIs, write files, browse the web, and spawn subprocesses — all under the same identity as the human sitting at the keyboard. When something goes wrong, whether that's prompt injection, a compromised tool, or an agent doing exactly what it was told and not what was meant — there's no meaningful isolation layer between the agent's blast radius and the rest of the system.
For personal use, this is annoying. For enterprise environments, it's a compliance problem that IT and security teams have no good answer for right now. An agent with access to Outlook, GitHub, and internal file shares is a significant attack surface, and today's runtimes don't give you much to work with.
How MXC Actually Works
Microsoft Execution Containers (MXC) is Microsoft's answer: a cross-platform, policy-driven execution layer built into Windows and WSL that lets developers declare what an agent can access at definition time, with boundaries enforced at runtime by the OS. Files, network, clipboard, UI input devices — you define the policy, MXC enforces it.
The architecture is designed as a composable spectrum rather than a binary sandbox/no-sandbox choice. Process isolation separates the agent's execution from the user's desktop session and binds the agent to a strong user identity — which directly addresses UI spoofing and input injection attacks. Session isolation goes further, separating the agent from the user's clipboard and input devices entirely. Further along the spectrum, Micro-VMs and Linux containers (roadmap items) provide heavier isolation for higher-risk workloads.
The identity layer matters here too. Windows assigns each agent a local ID or Entra-backed cloud identity, so every file write, network call, and subprocess spawn is attributed to that agent specifically — not to the human user's account. Agent 365 layers Intune and Defender policy on top of this, giving IT teams the ability to gate what agents can do before they run, monitor what they're doing while they run, and audit what they did after.
Windows 365 for Agents — now generally available — takes containment off the local device entirely, giving computer-using agents their own managed Cloud PCs that are fully isolated from the developer's machine.
What Teams Are Actually Using This For
The early ecosystem signals are useful for understanding the intended use cases. OpenClaw runs its Windows node and gateway contained within MXC — the companion app handles setup, and the containment boundary means the host system is protected even if the agent misbehaves. GitHub Copilot CLI has adopted process isolation. NVIDIA is building OpenShell on MXC to deliver autonomous, always-on agents as an installable package.
The Hermes Agent team at Nous Research put it plainly: continuously-running local agents need intentional isolation. The ability to define what an agent can access and trust that those controls hold is the missing primitive. MXC provides it. The same logic applies to any organization deploying computer-using agents for enterprise workflows — filling out forms, navigating internal software, processing documents across applications. Without OS-level containment, those agents are running on trust.
Why This Is a Bigger Deal Than It Looks
The framing Microsoft is using — "containment, identity, and manageability as foundational primitives in the operating system" — is a deliberate play for where the governance layer of agentic AI ends up living.
Right now, every agent framework handles security differently, inconsistently, and mostly by convention. There's no standard identity model for agents. There's no standard way to declare what a tool can access. Prompt injection protections are bolted on at the application layer and easy to bypass. Microsoft is betting that the right place to solve this is not in the LLM, not in the framework, and not in the enterprise security product sitting outside the system — but in the OS itself, enforced below the application layer where agents can't override it.
That's the actual thesis. If it works, Windows becomes load-bearing infrastructure for enterprise agent deployment the same way it became load-bearing infrastructure for enterprise identity management in the 2000s. Whether the open-source ecosystem and cross-platform agent builders adopt MXC or route around it is the real question to watch.
Availability and Access
MXC is available now in early preview on GitHub. Process isolation and session isolation will roll out to Windows Insiders shortly after Build. WSL containers — which also use MXC as a foundation — are coming to public preview in the next few months. Micro-VM and Linux container containment modes are on the roadmap but not yet dated. Windows 365 for Agents is generally available today within Agent 365.
The new on-device models — Aion 1.0 Instruct and Aion 1.0 Plan — bring local reasoning and tool-calling without cloud dependency, and are coming in the months ahead. The Surface RTX Spark Dev Box (NVIDIA RTX Spark silicon, 128 GB unified memory, up to 1 petaflop of AI compute) is purpose-built for developers who want to run these workloads locally without unpredictable cloud bills.
The governance primitives are live. The hardware is shipping. Microsoft has made its argument — that OS-level containment is the missing layer in the enterprise agent stack. The more interesting signal will be whether the frameworks, the security teams, and eventually the auditors agree.
Follow for more coverage on MCP, agentic AI, and AI infrastructure.
Top comments (0)