Microsoft Execution Containers (MXC) explained: how Windows is trying to keep AI agents on a leash
Posted on October 7, 2026 — my notes and thoughts on the announcement
Original source: Microsoft Windows Blogs, by Logan Iyer (Corporate Vice President, Windows Platform + Developer). Link at the bottom.
First, the honest part
I've been using AI coding agents for a while now. They're great. They also scare me a little.
Last month one of them decided the fastest way to fix a broken build was to edit a config file it had no business touching. Nothing blew up, but it could have. And that's the whole problem in a nutshell: the agent was doing what made sense to it. It just wasn't what made sense to me.
So when Microsoft announced Microsoft Execution Containers — MXC for short — was generally available, I read the whole post twice. Here's what it actually says, what it means, and where I think the interesting parts are.
The two bad options we've been stuck with
If you've tried to deploy agents inside a company, you know the drill. You basically get two choices:
- Give the agent full access to your machine and hope nothing goes wrong.
- Lock it down so hard it can't do anything useful.
Neither one works. The first one is a security incident waiting to happen. The second one means you're paying for an agent that can only open text files.
MXC is Microsoft's attempt at a third option. Instead of trusting the agent to behave, you draw a line around it — and the operating system enforces that line, not the agent.
Why this matters more than it sounds
The key sentence in the whole announcement, in my opinion, is this one: an agent cannot be its own security authority.
That sounds obvious until you realize how many setups currently work the other way. The agent decides what to do, the agent decides what it's allowed to do, and you're basically trusting a language model to have good judgment about permissions. That's not a security model. That's a hope.
The website example (this is the one that clicked for me)
Microsoft uses a coding agent as an example, and it's a good one. Say you ask an agent to update your website. It needs:
- Read and write access to the site's repository
- Access to build and test tools
- Read access to the production server config, just to understand how the site is deployed
What it should absolutely not have is write access to that production config. But here's the thing — from the agent's point of view, editing the config might look like the cleanest path to "task complete." It's not being malicious. It's just optimizing for the goal you gave it.
Without a managed boundary, that's exactly the kind of action that slips through. With MXC, the request gets blocked at the OS level. Not by the model, not by the plugin, not by the tool — by the container. Even if the agent insists, nothing happens.
What MXC actually is, without the marketing
Strip away the language and it's this: a policy layer that sits between your agent and your system, and enforces what the agent can touch.
You declare what a workload needs — files, network destinations, whatever. MXC takes that declaration and translates it into the right container for whatever platform you're on. Windows, macOS, Linux. Local machine or cloud. Same config.
A few things worth noting:
- The policy lives outside the agent. The agent can't grant itself more access. That's the whole point.
- You write it in a unified JSON schema, and there's a multi-language SDK.
- Windows 365 support is now generally available, so you can run agents on Cloud PCs alongside your regular work.
The four containment backends
Not every workload needs the same level of isolation. A coding agent that's just running tests doesn't need the same cage as something chewing through untrusted code. MXC gives you four options.
Process container
Windows 11, macOS, Linux. The lightweight one. Meant for responsive workloads like model-generated code and tool execution. It uses whatever the platform already has:
- AppContainer on Windows
- Seatbelt on macOS
- Bubblewrap on Linux
Session container
Windows 11 only. This one's interesting. The agent runs in a fully separate OS session with its own local agent identity, its own desktop, its own clipboard, its own UI and input boundaries. It's like giving the agent its own user account on the machine.
Best fit: long-running agents and automation that need a desktop or genuinely strong separation from the person using the computer.
WSL container (WSLc)
Windows 11 only. For agents that live in the Linux ecosystem. If your toolchain depends on Linux packages, this runs the workload through WSL.
MicroVM
Windows 11 and Linux, experimental. Hardware-enforced isolation. Full Linux compatibility. For the workloads you really don't want escaping — the ones where "probably fine" isn't good enough.
How a policy actually looks
Instead of giving an agent the full authority of whoever's logged in, you write a policy that says exactly what it can do. For the website scenario, that might be:
- Read and write the local repo
- Access Git
- No access to Documents or personal folders
- No inbound or outbound network
- No access to the interactive desktop
The policy breaks down into five areas:
| Area | What it controls |
|---|---|
| Containment | Which isolation environment the workload runs in (process, session, etc.) |
| Process | The command, arguments, working directory, environment, and startup settings |
| File system | What it can modify, what it can only read, what it can't touch at all |
| Network | Inbound and outbound connections, including whether it can reach the host's loopback |
| User interface | Whether it can see or interact with the desktop |
According to Microsoft, adding MXC support is straightforward — you can literally use your coding agent to integrate the SDK and draft a first policy, then review and refine it.
Developer policy vs. company policy
This part is smarter than it first looks. The agent developer declares what the workload needs. The organization can layer additional constraints on top — for example through Microsoft Intune.
So the same agent can run inside different companies with different rules, without the developer having to bake those rules into the app. The developer writes the "what the workload needs" part. IT writes the "what this company allows" part. They don't fight each other.
Intune support for MXC process containers on Windows 11 is coming, which means IT admins will get to control:
- How Windows evaluates container creation requests from agents
- What resource boundaries those containers actually enforce
And there's a design principle here that I think developers should pay attention to: if a company policy blocks a resource, the agent should say so. Explain that the task couldn't be completed within the available permissions, ask for approval if that's supported, or find a safe alternative. What it must not do is silently fail. Silent failure is how you end up debugging for three hours wondering why something didn't work.
Watch first, enforce later — the three modes
Writing a least-privilege policy is hard when you don't know what the workload actually needs yet. MXC handles this with three modes.
| Mode | Ungranted access | Activity report | What it's for |
|---|---|---|---|
| Enforcement | Blocked | No | Running with the production policy |
| Learning | Blocked and logged | Yes | Figuring out why something failed, tightening the policy |
| Permissive | Allowed and logged | Yes | Watching what the agent does without enforcing anything yet |
Enforcement
Production mode. The policy applies. Granted operations go through. Everything else is blocked. No reports.
Learning
The boundary is still enforced, but anything that gets denied is logged to a JSON report. You can replay the failures and see exactly which resources the workload tried to reach. This is how you turn a vague policy into a tight one.
Permissive
Nothing is blocked. Everything the policy would have denied gets recorded, but the workload keeps going. Good for the authoring phase — the task finishes, and you collect evidence about what it actually touched. Worth noting: permissive mode doesn't override other OS or org restrictions.
One thing Microsoft says that I appreciate: the first time you put an agent in a container, your policy will probably block something it legitimately needs. That's not a failure. That's the boundary showing you where it needs to move.
Identity: the other half of the problem
Containment answers "what can this agent do?" Identity answers "which agent did this?"
Coming soon: Microsoft Entra will separate agent activity from user activity inside Microsoft Agent 365. In plain terms, security teams will be able to look at what an agent is doing independently of the human on the machine.
Why that matters: if an agent gets compromised, you can cut off the agent's access to protected stuff without cutting off the employee. One misbehaving agent doesn't take down someone's workday.
Beyond that, you get real attribution. You can see which agents are running, tie activity to a specific one, investigate the risky ones, and apply policy to individual agents or groups — instead of only being able to say "something on this device did this."
Who's already using it
NVIDIA has integrated OpenShell into MXC, adding policy controls for file and inference service access, advanced network controls, credential management, and OCSF auditing for enterprises.
Already supporting MXC:
- GitHub Copilot
- OpenClaw
- OpenAI Codex
- Replit
- LM Studio
- Unsloth AI
Coming soon:
- Anthropic Claude Code
- Box
- Egnyte
- Heidi Health
- Hermes Agent (Nous Research)
- Manus
- Perplexity
- Raycast
- Simular
For people who use agents daily, this is mostly invisible — which is kind of the point. The protections are supposed to be part of the experience, not a separate thing you have to configure.
Getting started
If you want to try it:
- The MXC SDK is available now
- There's a configuration schema and documentation
- Samples are in the MXC repository
- Feedback goes through GitHub Issues
My take
I think this is one of the more important platform announcements Microsoft has made around AI in a while, and I don't think it'll get the attention it deserves because it's not flashy. There's no demo of an agent booking a flight or writing a novel. It's just plumbing.
But plumbing is what makes agents usable inside companies. Right now, most of the interesting agent use cases die in security review. Not because the tech doesn't work, but because there's no clean answer to "what stops this thing from doing something stupid?"
MXC is that answer, or at least the start of one. The policy-outside-the-agent part is the right design. The three modes — especially Learning — are practical. And the fact that it's cross-platform (Windows, macOS, Linux, local and cloud) means developers don't have to rewrite everything per environment.
The parts I'm less sure about: whether the four backends confuse people who just want "make it secure," and whether MicroVM being experimental means it'll sit in that state for a while. Also, "policy out of the agent's control" is easy to say and hard to verify — I'll be curious to see how that gets audited in practice.
Still, if you're building or deploying agents seriously, this is worth reading up on now rather than later.
Sources
- Microsoft Windows Blogs — Microsoft Execution Containers: Policy-driven containment for AI agents (Logan Iyer, October 7, 2026)
