For two decades I’ve been firm about what software could touch the machines I was responsible for. The model was simple: an app ran with the user’s permissions, and if it misbehaved, it misbehaved with all the authority that user had. We tolerated it because applications were mostly deterministic — you could reason about what they were going to do. AI agents break that assumption. An agent generates new code on each prompt, reads files, calls services, and chains operations at a speed no review process was designed for. So the question Microsoft is answering now at the operating system level is the same one that kept me up at night more than once: how do you let an agent do useful work without handing over the complete keys to the user’s session?
At Build 2026, on June 2, Microsoft introduced Microsoft Execution Containers (MXC) — a policy-based execution layer built into Windows (and WSL) that lets developers and IT declare exactly what an agent can read, write, and reach, and then enforce those restrictions at runtime. The framing matters: this isn’t a cloud container service. It’s containment pushed inside the operating system itself, closer to how a mobile OS regulates what an app can do than how we’ve been sandboxing code in a Python process or a cloud VM.
What MXC really is
The core idea is containment as a fundamental primitive. Microsoft’s argument is that agent behavior is dynamic and generated at runtime, so the old security assumptions — trust the binary, trust the user session — no longer hold. MXC gives the developer an abstraction layer over the underlying isolation mechanisms, so you declare intent (“this agent can read these directories and reach these domains, nothing else”) and Windows handles the low-level enforcement.
Microsoft frames it as a “composable sandbox” with a spectrum of containment levels:
- Process isolation — lightweight and fast containment to run model-generated code within a dedicated process boundary that restricts file and network access. This is for the developer’s inner loop, where you can’t afford latency. GitHub Copilot CLI is the first adopter, using MXC process isolation to restrict what its dynamically generated code can execute.
- Session isolation — separates agent execution from the desktop, clipboard, input devices, and active human sessions, running it under a different identity, local or backed by Entra. This mitigates UI spoofing, input injection, and data leakage between sessions, and is designed for long-running agents working alongside you.
The enterprise hook is Agent 365, which stacks Microsoft Entra (identity), Intune (device policies), Defender (threat protection), and Purview (data governance) on top of MXC — scheduled for preview in July. That’s what lets IT manage agent containment centrally across a fleet, rather than relying on each developer to configure it correctly.
Where this is a real benefit — if it works as described
I want to be precise about that conditional, because the MXC repository on GitHub itself warns that current profiles shouldn’t yet be treated as security boundaries. This is early preview software. So everything that follows is the promise, not yet the proven product. With that caveat stated upfront, here’s where this kind of containment genuinely changes the calculus:
- Coding agents on real repos. You let an agent refactor a service or expand test coverage, but its process can only touch the project directory and reach your package registry — not your SSH keys, not your
.envwith production credentials, not arbitrary outbound domains. If a prompt injection tries to get the agent to exfiltrate a secret, the policy is what says no, regardless of what the model “decided” to do. - Long-running automation alongside the user. A data processing agent runs for hours under its own session identity, isolated from your interactive desktop. It can’t read your clipboard, can’t inject keystrokes into your open apps, and every action it takes is attributed to its identity in the audit log — so when something goes wrong, you can distinguish agent activity from human activity. For anyone who’s ever tried to reconstruct the timeline of an incident, that attribution alone is worth a lot.
- Fleet governance. Through Entra and Intune, IT defines a single policy envelope — “agents in the finance group can’t reach the internet” — and it’s enforced on every machine, centrally, instead of living in scattered config files. This is the part that, in my CIO years, would have been the difference between “we allow agents” and “we ban agents because we can’t control them”.
- Containment of third-party and open source agents. Microsoft is using OpenClaw, an open source agent framework, as a test bed: the logic is that if a fully open agent can be contained within MXC boundaries, the containment is robust enough for anything. The company also says agent discovery and management is expanding to GitHub Copilot CLI and Claude Code.
The part worth reading twice
What sets this apart from the typical aspirational platform announcement is the partner list. Microsoft named five companies already building on MXC: OpenAI (exploring patterns for agents to safely generate and run code), NVIDIA (bringing its OpenShell agent framework to Windows on MXC), Manus, Nous Research (creator of the Hermes agent), and the OpenClaw project. Tao Zhang, Chief Product Officer of Manus, described MXC as a policy-based way to define and enforce an agent’s access boundaries at runtime. Dillon Rolnick, CEO of Nous Research, put it most concisely: continuous-execution local agents need intentional isolation, and developers need to trust that those controls will hold.
That OpenAI and NVIDIA — competitors at the model and silicon layers — are building on Microsoft’s containment plane tells you what Microsoft is really doing. It’s not trying to win the agent. It’s trying to be the trust layer underneath everyone’s agent. Worth noting in passing: Manus is a Chinese-origin startup, which makes its presence in a Microsoft enterprise security primitive its own small signal of how borderless the agent ecosystem has become.
And here’s the strategic tension I’d want every technical leader to sit with for a while. The browser sandbox was never charity — it was the precondition for running untrusted web code at global scale. Mobile permissions made app stores viable. Agent containment could be the equivalent deal for AI automation. But the concern is lock-in dressed up as security: if the best-governed agents are the ones running on Microsoft’s SDK, Microsoft’s identities, Microsoft’s policy plane, and Microsoft’s Cloud PCs, enterprises already standardized on Microsoft 365 and Intune may find themselves pushed toward a vertically integrated agent stack — and those that aren’t will be asking themselves hard questions about open interfaces and third-party parity.
My reading: the primitive is the right idea. Containment should live in the OS — that’s where it’s enforceable and where it survives even if the agent itself is compromised. What you need to watch isn’t whether MXC works. It’s whether the governance layer stays open enough that “secure” and “Microsoft-only” don’t quietly become the same word. For now it’s early preview, the security boundaries are explicitly not guaranteed, and the real test comes when someone runs a fleet of these on a production network. But the direction is set, and it’s the right one.