Microsoft's MXC Agent Containers Ship Before Intune Can Manage Them

Microsoft Execution Containers are generally available on Windows 11, and coding agents on your fleet may already be running inside them, but until Microsoft ships its Intune controls, the agent's developer writes the boundary. The Intune policy that lets an organization constrain those containers, the Entra separation of agent activity from user activity, and the Agent 365 controls for local agents are all described by Microsoft as coming soon. Until they ship, treat MXC as a useful developer-side sandbox you can pilot and observe, and keep fleet-wide approval of desktop agents on hold.

Microsoft announced general availability on October 7 at its Windows event in San Francisco. In the Windows Developer Blog post, Logan Iyer describes MXC as a "policy-driven execution layer for untrusted code or dynamically generated workloads." Satya Nadella's framing, quoted by NVIDIA, was that Microsoft "needed to make the desktop the most secure place for agents to execute." The timing matters: RTX Spark laptops built to run agents and large local models start shipping October 16, per Microsoft's Windows Experience Blog.

What MXC Actually Ships Today

MXC is an SDK and a JSON policy schema that put an agent, or the code it generates, inside an operating system container with declared limits on files, network, processes and desktop access. The policy sits outside the agent's control, so a model cannot grant itself more access mid-task.

The developer post lists four containment backends, and they are not equally mature:

Backend	Where it runs	Status
Process container (AppContainer on Windows)	Windows 11, macOS, Linux	GA
Session container (separate, OS-isolated session)	Windows 11 only	GA
WSL container (WSLc)	Windows 11 only	GA
MicroVM (hardware-enforced isolation)	Windows 11 and Linux	Experimental

The MXC repository on GitHub is MIT-licensed, ships Rust, .NET and Node SDKs, and also marks its windows_sandbox, microvm and hyperlight backends as experimental. So the backends that put a hypervisor between the agent and your laptop are the ones not yet production-grade.

Agents already integrated, per Microsoft: GitHub Copilot, OpenAI Codex, OpenClaw, Replit, LM Studio and Unsloth AI. NVIDIA OpenShell is integrated too, adding credential management and, for enterprises, OCSF auditing. Anthropic's Claude Code, Manus, Perplexity, Box, Egnyte, Raycast and others are listed as adding support later.

---

Who Writes the Policy Until Intune Ships?

The agent developer does. Microsoft's model is that the developer declares what the workload needs and the organization "can also apply additional constraints through management policy, like with Microsoft Intune management policy." But the same post says "Intune policy will soon be available to manage MXC process containers," that Windows "will also soon enable Microsoft Entra to help distinguish agent activity from user activity," and that Windows will "extend Microsoft Agent 365 controls to local agents on-device." None of the three has a date.

Pavan Davuluri's Windows Experience Blog post carries a footnote that governance at scale "may require additional services." Read that as a licensing signal. Agent 365 went GA on May 1, 2026 at $15 per user per month, and the on-device controls you would want for MXC are not in it yet. We covered how that bill stacks up in Microsoft Agent 365 Pricing: $15 Standalone vs $99 E7 Bundle.

What a developer-declared default looks like in practice is visible in GitHub's documentation. Copilot's local sandboxing limits writes to the working directory and temp folders, but "Outbound internet access is on by default." That is a reasonable default for a coding tool and a poor one for a device holding regulated data. The useful part: an enterprise can already require sandboxing through Copilot's managed settings, so --no-sandbox cannot turn it off. On Windows it needs 25H2 with KB5124010 or 26H1 with KB5124006 or later.

This mirrors what happened with coding-agent permissions over the summer. The control that held up was the one an administrator set centrally, as we argued in Claude Code Stops Asking Aug 14. Prompts Aren't Policy. and in MCP Server Governance: Enforce at the Client, Not the Registry.

Enforcement Mode Leaves No Record of What It Blocked

In production mode, MXC writes no activity report. Microsoft's mode table is explicit: enforcement blocks ungranted access with no report; learning mode blocks and records to a JSON activity report; permissive mode allows and records. And "Only on Windows, MXC process containers can produce an agent activity report." Session containers, WSLc and microVMs do not produce one.

For a security team, an agent that tried to read ~/.ssh and was stopped is a signal worth seeing. In enforcement mode MXC does not hand you that signal; you depend on your EDR, or on a vendor layer such as OpenShell's OCSF auditing. If you need to reconstruct what an agent did, the gap is the same one we described in Agent Audit Logging: Platform Logs Miss the Decision You Must Prove.

One more trap sits in the repository README: the executor's --audit flag "turns off all sandbox security for the workload being analyzed," with the warning "Never use it to run untrusted code." Learning mode keeps enforcement on. The two names are close enough that someone on your team will mix them up during a pilot.

---

Microsoft Said OpenClaw Needed a Separate Machine in February

The strongest case against a fast rollout comes from Microsoft itself. On February 19, the Defender Security Research Team wrote in Running OpenClaw safely that OpenClaw "is not appropriate to run on a standard personal or enterprise workstation" and should be deployed "only in a fully isolated environment such as a dedicated virtual machine or separate physical system."

MXC's VM-grade backend is the experimental one. The GA process container runs the agent in the user's own session with policy restrictions, which Petri describes as suited to low-risk tasks. Microsoft has not said that a process container meets the bar its own researchers set eight months ago, and you should not assume it does.

There is also the speed of the move. At Build in June, Microsoft's security blog grouped the MXC SDK with capabilities it described as "now in early preview," and in July Help Net Security reported Microsoft's statement that the initial release would support non-interactive sessions, with more capabilities planned. Four months later it is GA.

The steel-man is fair and you should weigh it. A coding agent in a process container with a deny-by-default file policy is safer than the same agent running with the user's full rights. Windows 365 for Agents, which runs an agent on a separate Cloud PC, is already GA, and Microsoft says Windows 365 support for MXC is GA too. That option matches the February guidance today. The Build post also says Intune policies "can be used to block common execution methods for OpenClaw agents" and that the Agent 365 registry "surfaces unmanaged local agents discovered by Microsoft Defender, Microsoft Entra, and Microsoft Intune," both in a section the post labels as preview. You have tools to find and block. What you lack is the tool to constrain an approved agent centrally.

What to Do Before Intune Policy Ships

Observe and approve narrowly now; make fleet-wide decisions once you can set the policy yourself.

This Week:

1. Inventory which MXC-integrated agents are on managed devices: Copilot CLI, Codex, OpenClaw, Replit, LM Studio, Unsloth. Use Defender or your EDR, not a survey.
2. If Copilot is approved, set enterprise managed settings to require the sandbox, and confirm the Windows builds that support it (25H2 with KB5124010 or 26H1 with KB5124006).
3. Tell the pilot team in writing that --audit disables all sandboxing, and that learning mode is the one to use.

This Month:

1. Run a pilot on a handful of scratch devices in learning mode, collect the JSON activity reports, and write your own baseline of the files and network destinations each agent actually needs.
2. Ask each agent vendor for the MXC policy their product ships with. Compare it with your baseline; outbound network defaults are where you will disagree.
3. Route any OpenClaw use to Windows 365 for Agents or a dedicated VM, per Microsoft's February guidance, until a VM backend is GA.

Before Ignite in November:

1. Ask your Microsoft account team for dated commitments on Intune MXC policy, Entra agent attribution, and Agent 365 on-device controls, and which licence each will require.
2. Hold any purchase of RTX Spark or Copilot+ hardware justified by local agents until those dates are in writing.

The Bottom Line

The pattern is familiar from mobile device management: the operating system shipped app sandboxes first, and enterprise control over them came later through management profiles. MXC follows that order. Its architecture is sound, because the policy lives outside the agent and the agent cannot raise its own limits. Two things are missing today: an administrator's hand on that policy, and a record of what enforcement stopped. Microsoft says Agent 365 will let IT teams "manage MXC containers, apply policies, and monitor agent activity" on the device, without a date. Meanwhile the Davuluri post notes that over 40% of business laptops now being built are Copilot+ PCs, so local agents will reach your fleet on hardware refresh, before the controls do.

Pilot in learning mode now, and approve fleet-wide when Intune can set the policy.

Continue Reading

• OpenAI's Agent Kill Switch Failed for 2.5 Hours After a DNS Escape
• Okta vs Entra Agent ID vs SailPoint: Two Issue, One Governs
• Defender for AI Agents Hunts $670K Shadow Agent Tax
• Microsoft's New Copilot Bills Autopilot Outside the $30 Seat
• The Pinned Commit Was a Branch. Check Your Git Host.
• Agent Audit Logging: Platform Logs Miss the Decision You Must Prove