If you run a coding agent on Windows today, its shell commands usually run with your full user rights: your SSH keys, your browser profile, your whole home folder. Microsoft is now putting OS-level boundaries around agents, and a lot of it lands on the developer side first.
We spent some time reading the official docs, the SDK repo and the Microsoft blog posts behind this. Below is our take on what it means if you build or run agents on Windows.
TL;DR
- Microsoft Execution Containers (MXC) is an open-source SDK (Rust, .NET, Node) that runs agent workloads inside a policy you define: files, network, UI and the process itself. Microsoft announced it as generally available on 7 October 2026.
- Backends differ. Process containers are lightweight. Session containers run the agent under a separate Windows account and session. There are also WSL containers and an experimental MicroVM.
-
Some agents already use it. GitHub Copilot sandboxes shell commands and local MCP servers with MXC, and you can configure it with
/sandboxin the Copilot CLI. - The agent workspace (Settings > System > AI Components > Experimental agentic features) is a separate preview feature that gives agents like Copilot Actions their own account and desktop.
-
MCP on Windows has an on-device registry (
odr.exe) that runs packaged MCP servers in a contained agent session by default. This is still preview. - Still coming: Intune policy for MXC process containers, Entra-based agent identity and Agent 365 controls for local agents.
The problem in one example
Microsoft's own example is a good one. A coding agent is asked to update a website. It needs read and write access to the repo and your build tools. It may need to read the production server config to understand the deployment. It should never change that config.
Without a boundary, the agent may decide that editing the config is the fastest way to finish the task. From the model's point of view that is reasonable. From yours it is an outage.
The core idea in the MXC announcement is that "an agent cannot be its own security authority." The policy lives outside the agent, so neither the model nor the code it writes can grant itself more access.
What MXC actually is
MXC is a library you build into your app or agent harness. You describe the container and its rules, and MXC picks a backend and launches the workload inside it. It covers Windows, Linux and macOS. The microsoft/mxc repo is MIT licensed and publishes SDKs for Rust (mxc-sdk on crates.io), .NET (Microsoft.Mxc.Sdk on NuGet) and Node (@microsoft/mxc-sdk on npm).
The policy has five areas:
| Policy area | What it controls |
|---|---|
| Containment | Which backend runs the workload |
| Process | Command, arguments, working directory, environment |
| File system | Read-write paths, read-only paths, denied paths |
| Network | Inbound and outbound access, including loopback to local services |
| User interface | Access to the desktop, clipboard and display |
This is the Node sample from the repo README. It runs a command with outbound network denied by default:
import { spawn, type ContainerRequest } from '@microsoft/mxc-sdk/v1';
const request: ContainerRequest = {
command: 'node -e "console.log(\'hello from container\')"',
network: { egress: { default: 'deny' } },
timeoutMs: 30_000,
};
const child = await spawn(request);
Picking a backend
On Windows, the main options are:
- Process container. This is the default and the fast one. On Windows it uses AppContainer. It suits coding agents and model-generated scripts where the inner loop needs to stay quick.
-
Session container (
isolation_sessionin the SDK). This runs the agent under a separate Windows account and session, with its own desktop, clipboard, UI and input. It is Windows only. It fits long-running agents and UI automation, and it is the backend that gives you a distinct identity to audit. -
WSL container (
wslc). This is for Linux-first toolchains that need Linux packages. - MicroVM. This uses hardware-backed isolation for higher-risk work like running untrusted code. It is marked experimental, as are the Windows Sandbox and Hyperlight backends in the repo.
There is a minimum Windows build. Per the repo's OS version table, process containers need Windows 11 24H2/25H2 build 26100.9278/26200.9278 (August 2026 update) or later. Session containers need 26100.9550/26200.9550 (September 2026 update). On 26H2, both need 26300.9550. If your CI runners or test VMs lag on updates, check this first.
Writing a policy without guessing
This is the part we found most useful. Nobody knows every path an agent will touch before running it, so MXC has three modes:
- Enforcement: blocks anything not granted. This is for production.
- Learning: still blocks, but records each denial in a JSON activity report.
- Permissive: allows everything and records what would have been blocked.
The activity report only works with process containers on Windows. Microsoft's guidance matches what we would do anyway: run in Learning mode, read the denials, and grant only what the workload really needs.
Two things to watch. First, the README warns that the --audit flag on the wxc-exec.exe test executor "turns off all sandbox security" for that run, so never use it on untrusted code. Second, the README says it plainly: "Your application will hit access issues when running in a sandbox, until you've had time to tune your containment rules." Expect a few rounds of tuning.
Microsoft also asks agent developers to plan for organisation policy that is stricter than yours. If a resource is blocked, the agent should explain that and ask for the right access, not fail silently. That is a UX requirement worth building in now.
If you already use GitHub Copilot
The GitHub and Windows post explains how Copilot uses MXC. On Windows it uses the BaseContainer tier of the ProcessContainer backend. With sandboxing on, shell commands, local MCP servers and language servers run inside the process boundary by default.
Two caveats matter for threat modelling:
- Copilot's built-in file tools run inside Copilot itself. They are checked against the policy by the agent harness, not by OS process isolation.
- Remote MCP servers sit outside the local sandbox.
To check or change your settings, run /sandbox in the Copilot CLI. In the Copilot app, open settings with the gear icon, pick your project and turn on Sandbox new sessions. By default the working directory is read-write and most of the rest of the system is read-only or blocked.
Microsoft lists OpenClaw, OpenAI Codex, Replit, LM Studio and Unsloth AI as also supporting MXC. Claude Code, Manus, Perplexity, Raycast and others "will be releasing support", with no dates given.
The agent workspace is a different thing
It is easy to mix these up. The agent workspace comes from the Experimental agentic features setting, which is used by Copilot Actions. According to Microsoft Support:
- It is off by default. Only an admin can turn it on, and then it is on for every user on the device.
- It creates separate agent accounts and an agent workspace with its own desktop, apart from the user's session.
- Agents can request access to six known folders: Documents, Downloads, Desktop, Music, Pictures and Videos. Agent accounts can also access any folder that all authenticated users can access, such as public user profiles.
- On preview builds 26100.7344 and later, you can set file access per agent under Settings > System > AI Components > Agents, with the options Allow always, Ask every time or Never allow.
One small trap: the Windows security book shows the toggle under an extra Agent tools level. Microsoft's own pages show both paths, so search Settings for "agentic" if you cannot find it on your build.
MCP servers and the on-device registry
If you ship an MCP server, this part is for you. MCP on Windows adds the Windows On-Device Agent Registry (ODR). Agents use it to discover MCP servers, and you can inspect it from a terminal on build 26220.7262 or later:
odr mcp list
odr mcp add <path-to-mcpb-manifest-json>
odr mcp remove <server-id>
The containment docs have details that are easy to miss:
- Packaged servers registered through ODR run in a separate agent session under a separate agent account. They have no access to your files, settings, credentials or windows unless you grant it.
- To run contained, a server must be a binary
.exewith package identity (MSIX) and a valid manifest. MCP bundles (.mcpb) currently cannot run contained. - A contained server can still reach the internet. Containment here limits local access, not network access.
- File permissions are granted per host app, not per server. If one server used by a host gets access to your files, every server used by that host gets it too.
- The "Reduce protections for agent connectors" setting (Settings > System > Advanced > AI components) exists for testing. It does what the name says.
Like the agent workspace, all of this is labelled pre-release.
What is still missing
To be fair about the gaps: per Microsoft, Intune policy for MXC process containers is "soon". Entra support for telling agent activity apart from user activity is "coming soon", and so are Agent 365 controls for on-device agents. If you run agents across a fleet today, you can contain them, but central governance is not fully there yet. For now, plan a pilot rather than a full rollout.
Over to you
How are you sandboxing agents on Windows today: a VM, WSL, Windows Sandbox, a separate user account, or nothing at all? And would you add MXC to your own agent harness, or wait until Intune and Entra support land? Tell us what your setup looks like in the comments.
We first wrote about this on Windows Mode.
Top comments (2)
Interesting and well-structured analysis! 👏
MXC looks promising, especially for enforcing security boundaries independently of AI agents.
One concern I have is policy consistency across OS-level isolation, application tools, and MCP servers. What happens when different execution paths provide access to the same resource?
I believe this deserves particular attention in enterprise environments.
Thanks for sharing these insights! 🔐
Thanks, glad it was useful! That's the right question to ask. The way I'd think about it is that the OS-level boundary should be the outer limit: whatever path the agent takes, it shouldn't be able to reach more than the container allows. App tools and MCP servers can then narrow access further, but never widen it. Where it gets messy is when an MCP server runs outside the agent's boundary with its own broader permissions, because then it becomes a side door. For enterprise setups I'd run MCP servers inside the same contained context as the agent where possible, keep their permissions scoped per tool, and log access at the OS layer so every path shows up in one place. Curious whether you've hit this in practice?