On October 7, Microsoft held what Ars Technica says was its first live event in two years. It announced new Surface hardware, a rebuilt Copilot and changes to Windows 11. The two new machines are built for developers. The piece that matters to anyone who manages Windows PCs is Microsoft Execution Containers, or MXC, a way to limit what an AI agent can touch on a computer. Microsoft says MXC is generally available. The tools to manage it across a company are still on the way.
What MXC does
MXC is a policy layer in Windows. A policy lists the files and network destinations an agent’s work may use, and Windows enforces the list. In Microsoft’s words, “the policy remains outside the agent workload’s control, so the agent or generated code cannot grant itself additional access.”
Microsoft’s own example is a coding agent asked to update a website. It can read and write the site’s files and read the server configuration, but it may not change that configuration. If the agent decides that editing the configuration is the fastest fix, the container is designed to stop it, whatever the model decides.
MXC offers four levels of isolation:
- Process container. The lightest option. It runs on Windows 11, macOS and Linux.
- Session container. Runs the agent under its own Windows account and session, with a separate desktop, clipboard and input. Windows 11 only.
- WSL container. Runs the agent in a Linux environment through WSL. Windows 11 only.
- MicroVM. Puts the agent in a hardware-isolated virtual machine. It is still experimental.
A policy covers files, network access and whether the agent can reach the desktop. The code and documentation are on GitHub under the MIT license.
What is ready and what is not
Ars describes MXC as something that lets admins monitor active agents and set guardrails for each one. Microsoft’s own developer post puts those management pieces in the future tense. Here is how I read it:
- Ready now: MXC, its SDK and its policy format. On Windows, a learning mode blocks anything the policy doesn’t allow and records it in a report for process containers, so you can tighten a policy before you enforce it.
- Coming soon, Intune. Microsoft says Intune policy for MXC process containers on Windows 11 will “soon” be available. It is meant to let administrators control how Windows handles container requests from agents and what boundaries those containers enforce.
- Coming soon, Entra and Agent 365. Windows will let Entra separate an agent’s activity from the user’s in Agent 365, and Microsoft says Agent 365 controls will extend to local agents on the device.
- Up to the agent’s maker. MXC works with agents whose developers have added support. Microsoft lists GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio and Unsloth AI as supporting it today, and says Claude Code, Perplexity and others will follow.
Plan for a license question, too. Agent 365 is licensed per user. Microsoft’s Entra licensing page says it is included in Microsoft 365 E7 and sold as an add-on for E5 and Business Premium, among others. Microsoft’s announcement carries a footnote that “governance at scale may require additional services.” Check the current terms before you budget for it. I recommend consulting with your Microsoft representative to clarify any uncertainties.
What I would do now
None of this needs a purchase today. It is mostly homework.
- Find out which agents are already on your PCs. Ask your developers and power users which AI coding and automation tools they run. You can’t contain what you haven’t counted.
- Look at what your tenant already shows you. In the Microsoft 365 admin center, go to Agents, then All agents, then Registry. Microsoft’s documentation says viewing the agent inventory needs a role such as AI Reader, not a special license. That list covers agents available in your tenant. It is not a list of agents running on individual PCs. Microsoft says that coverage is coming.
- Write the rules before the tools arrive. Decide which agents are allowed, who approves a new one, and which folders and systems an agent must never touch. A written rule is easy to turn into an Intune policy later. My post on agents trusting each other too much has questions you can start from.
- Ask each vendor whether their agent supports MXC. “No” is a useful answer. So is “What is MXC?”
A sandbox limits the damage when something goes wrong. It does not make an agent trustworthy, and Microsoft doesn’t claim it does. Their post describes the aim as “containing the scope of the impact if something goes wrong.” That is a sound design, and it is unfinished. Start on your policy now and let the management tools catch up.
