Microsoft Execution Containers make agent containment an operating system job, with separate agent identity and enforced least privilege. What it changes, what it doesn't, and where to start.
Most of the conversation about AI agents in the enterprise has been about capability: what they can do, how fast, and how cheaply. The harder question has always been control. Once you give an agent the ability to read files, run code and click around a desktop, what stops it doing something you didn't intend?
Until now the honest answer has been "whatever the agent vendor built". Every agent shipped its own sandbox, its own permission prompts and its own idea of what "safe" means. On 7 October 2026, Microsoft made Microsoft Execution Containers (MXC) generally available on Windows 11, and that changes the answer. For the first time, agent containment is something the operating system does, not something each app improvises.
MXC is a policy-driven sandbox for AI agents and the code they run. It works in three steps:
The isolation isn't one-size-fits-all. At the lightweight end, the agent runs in the user's own session but inside a restricted container. On Windows this builds on AppContainer, the same technology that sandboxes Store apps. At the heavy end, the agent runs fully separated from the user's desktop, clipboard and input devices, up to and including a dedicated virtual machine. MXC chooses the appropriate isolation for the job based on the policy and what the host supports.
It is also open source and cross-platform. The runtime and its TypeScript SDK are on GitHub under the MIT licence and run on Windows, Linux and macOS. GitHub Copilot's local sandbox is already built on it. OpenAI Codex, OpenClaw, Replit and LM Studio support it, and Anthropic's Claude Code is among those planning support.
Governance frameworks for AI tend to stall at the same point. You can write a policy saying agents must operate with least privilege, but you can't enforce a sentence in a PDF. MXC matters because it turns several governance principles into enforceable technical controls.
This is arguably the most important shift. Under MXC an agent is identified by the operating system as itself, separate from the person it's working for. Today, when an agent acts on a user's behalf, the logs usually show the user doing it. That makes it almost impossible to answer the first question in any incident review: was that a person or the agent?
Separate identity makes attribution possible, and attribution is the foundation of accountability. Without it you can't audit, investigate or meaningfully assign responsibility.
Most agents today inherit everything the user can do. If you can read the finance share, so can your coding assistant. MXC inverts that. The agent gets only what its policy grants, and the boundary is enforced by the OS at runtime.
The useful way to think about this is blast radius. The question is no longer only "will the agent make a mistake?" It is "when it does, or when it's manipulated by a malicious web page or prompt injection, how much damage can it do?" Containment doesn't make agents smarter, but it does make their failures smaller.
Microsoft is connecting MXC to its existing enterprise stack through Agent 365: Intune, Entra, Defender and Purview. For endpoint and identity teams, that is the difference between agent governance being a new discipline with new tooling and being an extension of what they already run.
If agent containment policies can be deployed, monitored and reported on through the same management plane as device compliance and conditional access, governance stops being a project and becomes an operational process.
The alternative to an OS-level layer is evaluating every agent's homegrown sandbox individually, with no consistent way to express or verify policy across them. A shared, open containment layer that multiple vendors adopt gives organisations a single policy model to reason about, and gives auditors something consistent to inspect.
It's worth being clear-eyed about the limits.
It's still maturing. MXC's own repository has carried a warning that some generated policies are too permissive and that its profiles shouldn't yet be treated as hard security boundaries. That caveat may have been addressed alongside GA, but check the current state before treating MXC as a guaranteed boundary in a threat model.
It governs access, not judgement. MXC limits what an agent can touch. It says nothing about whether the agent should take a given action within those limits. An agent with permission to send email can still send the wrong email. Human-in-the-loop approvals, output review and clear accountability for agent decisions remain necessary.
It covers the endpoint, not the whole estate. Many agents run in the cloud and act through APIs and connectors. Governing those requires identity, API permissions and data controls elsewhere in the stack. MXC is one important layer, not the whole picture.
Containment and capability pull in opposite directions. The strongest isolation modes separate the agent from the desktop and input devices. That's excellent for safety, but it conflicts with computer-use agents that need to see the screen and drive the mouse and keyboard. For those workloads, the practical pattern is likely to be a fully isolated VM or Cloud PC that the agent controls end to end, with MXC policy constraining its file and network reach.
If you're responsible for endpoint management or AI governance, there are a few sensible first steps:
For the past few years, agentic AI has moved faster than the controls around it. Organisations have been forced to choose between blocking agents and accepting risks they couldn't measure. MXC doesn't remove that tension entirely, but it gives governance something it has badly lacked: an enforcement point in the operating system, with identity, policy and audit built in.
That's not the end of the governance conversation. It's what makes the conversation practical.
Containment doesn't make agents smarter, but it does make their failures smaller.
Jannik, a Microsoft MVP, treats every agent like a new hire, with a CV, onboarding and permissions. We talk model choice, Copilot, Foundry and governing agents with Agent 365.
Nathan Foreman on writing only a fraction of his code by hand, what went wrong when an agent swarm approved its own PRs, and why written-down decisions matter more than ever.