Microsoft Execution Containers (MXC) became generally available on Windows 11 on 7 October 2026, the same day GitHub switched on local sandboxing for Copilot CLI, the Copilot app and VS Code. An agent on a Windows laptop can now be told, by the operating system rather than by its own prompt, which folders it may write, which hosts it may reach and whether it may touch the desktop. Two things an IT department in Sweden would reasonably expect to ship alongside that did not: the Intune policy that lets you set those boundaries fleet-wide, and the Entra separation that makes an agent's file access show up under the agent's identity instead of the employee's. Both are "coming soon" in Microsoft's own wording, with no date. Until they land, the developer who built the agent writes the boundary, and your audit log still says the human did it.
What went GA on 7 October
MXC is a policy layer, not a product you install. A developer declares what a workload needs, as a JSON document or through an SDK call, and the operating system picks an isolation mechanism and enforces the declaration at runtime. The policy lives outside the workload, so model-generated code cannot grant itself more access. Microsoft first showed it as an early preview at Build on 2 June 2026; the Windows Developer Blog post of 7 October moves it to GA on Windows 11 and in Windows 365.
Four containment backends exist, and only three of them are GA.
| Backend | Platforms | Status | Intended for |
|---|---|---|---|
| Process container | Windows 11 (AppContainer), macOS (Seatbelt), Linux (bubblewrap) | GA | Model-generated code and tool execution inside the user's session |
| Session container | Windows 11 only | GA | Long-running agents that need a desktop; runs under a distinct Windows account with its own desktop, clipboard and input |
| WSL container (WSLc) | Windows 11 only | GA | Linux-first agent toolchains |
| MicroVM | Windows 11 and Linux | Experimental | Higher-risk workloads that need a hardware-backed boundary |
| Windows 365 for Agents | Cloud PC | GA since 1 June 2026 | Agents that should never run on an employee device at all |
A policy covers five areas: which backend to use, the process (command, arguments, working directory, environment), the file system (paths the workload may modify, paths it may only read, paths it cannot see), the network (inbound, outbound, and whether loopback to services on the host is allowed) and the user interface (whether the workload may touch the desktop). SDKs ship for Rust, .NET and Node, and the repository on GitHub is MIT-licensed. Microsoft describes three operating modes: Enforcement blocks what the policy denies, Learning blocks and records, Permissive allows and records. The recording only exists on Windows, only for process containers, and it is the part that matters most for an auditor, as we get to below.
Agents already running under MXC, per Microsoft: GitHub Copilot, OpenAI Codex, OpenClaw, Replit, LM Studio, Unsloth AI and NVIDIA's OpenShell. Named as adding support later: Anthropic Claude Code, Box, Egnyte, Heidi Health, Hermes Agent by Nous Research, Manus, Perplexity, Raycast and Simular. If your developers run Claude Code on Windows today, nothing changes for them yet.
The GitHub Copilot sandbox, and its defaults
GitHub's changelog of the same day makes local sandboxing GA for Copilot CLI, the Copilot app and VS Code sessions that use Agent Host, at no extra cost. Copilot declares the policy it wants, and MXC maps it to AppContainer on Windows, Seatbelt on macOS 15 or later, and bubblewrap 0.5.0 or later on Linux. GitHub's own documentation is candid about what this is: the lighter end of the isolation spectrum, which "restricts what a process can read, write, and reach on the network, but it does not run your commands inside a separate virtual machine or container".
Three defaults deserve a line each in your rollout plan.
- Sandboxing is off until someone turns it on. GitHub's docs state that local sandboxing is turned off by default, and commands run with the full rights of the developer's account until it is enabled. Enterprises can require it with the
sandbox.enabledmanaged setting and make it fail closed withsandbox.failIfUnavailable, delivered through server-managed, MDM-managed or file-based settings. Without that, each developer decides. - Outbound internet is on by default once the sandbox is on. Sensible for a coding agent that needs npm. Wrong for a machine that holds customer data, where a prompt-injected tool call can exfiltrate to any host. Set egress to deny and allowlist the registries and Git remotes you actually use.
- The CLI's own file tools bypass the OS boundary. First-party commands run in-process, and GitHub says they are coded to honour the sandbox policy "on a best-effort basis". The hard boundary applies to shell commands and spawned tools, not to everything the agent does.
GitHub's changelog also makes a point worth repeating to anyone who thinks a safer model solves this: "Model execution and tool isolation are separate concerns." The same sandbox policy applies whether Copilot is calling GPT-6 Astra or Claude Haiku 5.5. Choosing the model with the better safety numbers does not shrink what a compromised tool call can reach. The policy does.
What "coming soon" leaves on your desk
Three gaps, in the order an auditor will find them.
1. No Intune policy yet
Microsoft's post says that "Intune policy will soon be available to manage MXC process containers used by MXC-integrated agents on Windows 11". Today, the containment policy is whatever the agent's developer declared. Copilot's defaults are GitHub's choices; OpenClaw's are the OpenClaw project's. You can enforce Copilot's sandbox through GitHub's managed settings because GitHub built that lever, but there is no single Windows-side control that says "every MXC-integrated agent on this device denies egress except to these hosts". When the Intune policy arrives it should apply to process containers first, which still leaves session and WSL containers to the developer.
2. The agent still acts as the employee
Pavan Davuluri, Microsoft's EVP for Windows and Devices, told CRN that "every action it takes should be attributed to the agent, not to you". The blog post is more careful: "Windows will allow Microsoft Entra to distinguish agent activity from user activity in Microsoft Agent 365", future tense, no date. At Build in June, session isolation already assigned a local ID or an Entra-backed identity to an agent session. For the process container, which is the backend Copilot uses and the only one with activity reports, the agent runs inside the user's session under the user's token. In Microsoft 365 audit logs, Defender timelines and SharePoint access reports, a file an agent read is a file the employee read. We covered the same problem for cloud-side agents last week in OpenAI Dots and the audit log: whose action was that?. The desktop version is worse because the identity in question has a Windows Hello PIN and a payroll record.
3. Enforcement mode writes no report
The agent activity report, which lists the resources a workload tried to use, is produced in Learning and Permissive modes on Windows. Microsoft's post does not describe an equivalent for Enforcement mode. So the mode you want in production is the mode that does not tell you what it blocked. A denied exfiltration attempt is exactly the event a security team wants to see, and unless your EDR catches the attempt at the process level, or you are using a vendor layer like OpenShell's OCSF auditing, it is silent. Plan on running Learning mode on pilot machines to establish a baseline, and treat the move to Enforcement as the point where you lose that visibility rather than gain it.
Cost math: where should the agent run?
MXC on the workstation is free, which is why it will be the default. The question is which workloads it is enough for. Microsoft's own Defender Security Research Team answered part of that on 19 February 2026, writing that OpenClaw "is not appropriate to run on a standard personal or enterprise workstation" and that if it must be evaluated, "it should be deployed only in a fully isolated environment such as a dedicated virtual machine or separate physical system". OpenClaw now ships MXC support, and MXC's VM-grade backend is the one marked experimental. Nothing in the 7 October post retracts the February guidance. A process container on a laptop is not a dedicated virtual machine.
For agents in that category, Microsoft's answer is Windows 365 for Agents, GA since 1 June. Pricing on Learn, for the US geography: $0.40 per hour of task runtime on on-demand Cloud PCs, rounded up to the next full hour, plus $5 per Cloud PC per month if you want an always-available instance for latency-sensitive work. Learn states that pricing varies by the geography where Cloud PCs are provisioned, so treat the numbers below as a US-priced illustration until you have the Sweden figure in the Intune admin center.
| Monthly, one agent | Isolation | Cost (US list) | Who sets the policy |
|---|---|---|---|
| MXC process container on the laptop | AppContainer, user's session | $0 | Agent developer (Intune later) |
| MXC session container on the laptop | Separate Windows account and desktop | $0 | Agent developer |
| Windows 365 for Agents, on-demand, 2 h per working day (42 h) | Intune-managed Cloud PC, agent identity | $16.80 | IT, via provisioning policy and Intune baseline |
| Windows 365 for Agents, on-demand, 8 h per working day (168 h) | Intune-managed Cloud PC, agent identity | $67.20 | IT |
| Windows 365 for Agents, always-available, 8 h per working day | As above, instant start | $72.20 | IT |
The 21-working-day month is an assumption, and the hourly rounding means short bursty tasks cost more than the arithmetic suggests. Even so, the full-time row is cheaper than the hour of incident response a prompt-injected agent on a finance laptop would consume. For a background agent that processes supplier invoices or triages tickets, the Cloud PC also gives you the thing MXC on the desktop cannot yet: an agent identity in Entra, device compliance enforced through Conditional Access for agent users, and a Microsoft-published Intune security baseline for agent Cloud PCs, which went GA the week of 24 August.
// MXC Node SDK: the shape Microsoft's README shows, with egress denied by default.
// File-system and UI rules go in the same request object; see the JSON schema in microsoft/mxc.
import { ContainerRequest } from "@microsoft/mxc-sdk";
const request: ContainerRequest = {
command: 'node -e "console.log(\'hello from container\')"',
network: { egress: { default: "deny" } }, // allowlist registries and Git remotes explicitly
timeoutMs: 30_000,
};
// GitHub Copilot managed settings (server, MDM or file based): require the sandbox and fail closed.
// Keys as documented by GitHub; check the managed-settings reference for your MDM's file format.
{
"sandbox.enabled": true,
"sandbox.failIfUnavailable": true
}
// Never ship this one. From the microsoft/mxc README:
// "--audit turns off all sandbox security for the workload being analyzed. Never use it to run untrusted code."
// wxc-exec.exe --audit policy.json
The Swedish and EU angle
Attribution is a GDPR accountability problem before it is a security one. Article 5(2) makes you able to demonstrate compliance, and Article 32 asks for measures appropriate to the risk. If an agent running as an employee reads a folder of HR documents, your access logs record a human who did not do it. That is both a false record about the employee and a missing record about the agent. Until Entra can separate the two, the fix is architectural: run agents that touch personal data in a session container with its own Windows account, or on a Cloud PC with its own identity, and keep process containers for coding agents working on repositories.
Egress deny is the Schrems-era control. An agent with outbound internet on by default can post a document to any endpoint a hidden instruction names. Allowlisting egress to your Azure region, your tenant's Microsoft 365 endpoints and the package registries you mirror turns a transfer-impact assessment from "any country" into a list you can defend. GitHub's default is the open one. Change it in the managed settings before enabling the sandbox for anyone outside engineering.
Check the Cloud PC geography before trusting the price. Learn only prints US pricing for Windows 365 for Agents and says geography changes it. Cloud PCs for agents are provisioned through an Intune provisioning policy with a region, so the data stays where you put it, but the invoice does not have to match the US sheet. Get the Sweden Central or West Europe rate from the admin center before you present the table above to a budget owner.
Hybrid intelligence on Copilot+ PCs is opt-in, later, and in select markets. The Windows Experience blog says Copilot access to local files and recent activity will begin rolling out on Copilot+ PCs "in the coming months", that the Copilot and Search integration is opt-in, and that it will "first start rolling out to select markets later this year". Sweden is not named either way. Autopilot, the persistent agent that would act on those files, remains in private preview. There is no admin action to take on that this week beyond confirming the Copilot settings your tenant already enforces.
NIS2 and the AI Act reward the same thing. Both regimes expect you to be able to say which system did what and to show the control that constrained it. An MXC policy in version control plus a Learning-mode activity report per agent is evidence. "The developer enabled the sandbox" is not.
Decision guide
- Developers on GitHub Copilot CLI, app or VS Code? Require the sandbox now through managed settings, set it to fail closed, and switch outbound internet to an allowlist. Do this this week; it is GA, free and independent of Intune.
- Agents other than Copilot on employee Windows 11 devices? Confirm each one is MXC-integrated and read its declared policy. Pilot in Learning mode on scratch devices and keep the JSON activity reports as the baseline. Hold fleet-wide approval until Intune policy for MXC ships.
- OpenClaw, Hermes Agent or anything that holds persistent credentials? Follow Microsoft's February guidance, which still stands: a dedicated VM, a separate machine or a Windows 365 for Agents Cloud PC. MXC's process container does not meet that bar, and its MicroVM backend is experimental. Our Muse vs Hermes Agent vs OpenClaw comparison covers which of those fits which team.
- Agents that touch personal data? Session container or Cloud PC, so the identity in the log is the agent's. Document the choice in the DPIA as the compensating control until Entra separation lands.
- Running Claude Code on Windows? Not MXC-integrated yet. Use the cloud-side sandbox pattern from our Azure agent sandbox audit in the meantime, and watch the GitHub repository for the integration.
- Writing the Microsoft account-team question? Ask for dated commitments on three items: Intune policy for MXC process containers, Entra agent-versus-user separation on Windows, and an Enforcement-mode activity report. Ignite 2026 is the obvious moment for all three.
The boundary moved into the operating system on 7 October, which is where it belongs. Who gets to draw it, and whose name is on the actions inside it, are still the agent developer's and the employee's. Plan the next two months around that.
subscribe # the AI news that matters, minus the noise
Sources
- Windows Developer Blog: Microsoft Execution Containers, policy-driven containment for AI agents (GA, backends, modes, supported agents, Intune and Entra "soon")
- Windows Experience Blog: Building Windows for hybrid intelligence (Copilot local context, Autopilot, rollout wording)
- Windows Developer Blog: Windows platform security for AI agents (Build 2026 preview, session identity)
- GitHub: microsoft/mxc (SDKs, backends per platform, --audit warning)
- GitHub Changelog: Local sandboxing for GitHub Copilot now generally available
- GitHub Docs: About cloud and local sandboxes for GitHub Copilot (defaults, managed settings, OS requirements, in-process tools)
- Microsoft Security Blog: Running OpenClaw safely (Defender Security Research Team, 19 February 2026)
- Microsoft Learn: Pricing for Windows 365 for Agents (US geography rates, geographic variation)
- Microsoft Learn: What's new in Windows 365 for Agents (GA 1 June, Conditional Access, Intune security baseline)
- Microsoft Learn: What is Windows 365 for Agents? (provisioning policies, Intune management)
- CRN: Microsoft touts hybrid intelligence, agent security push and new AI PCs (Pavan Davuluri quotes)
- Computerworld: Microsoft will let Copilot act on local files on Windows PCs (Autopilot private preview)