Announced 7 Oct 2026 · Sources checked
What became generally available on 7 October?
Logan Iyer, Corporate Vice President for Windows Platform + Developer, published “Microsoft Execution Containers: Policy-driven containment for AI agents” on the Windows Developer Blog on 7 October 2026. The post’s lead claim is that MXC is now generally available as the containment layer in a broader Windows program that also names identity and manageability. Developers and IT administrators declare resources—files and network destinations—and MXC selects a backend to enforce those limits at runtime outside the agent’s own control.
The same calendar day, the microsoft/mxc GitHub repository published release tag v1.0.0 (“MXC SDK v1.0.0”) with published_at 2026-10-07T05:54:01Z. The repository’s LICENSE.md is an MIT License copyright Microsoft Corporation. The README we hashed presents MXC as a sandboxed code-execution system for untrusted code—model output, plugins, and tools—on Windows, Linux, and macOS, with Rust, .NET, and Node SDKs.
A parallel Windows Experience Blog post the same day, “Building Windows for hybrid intelligence,” repeats the GA framing and lists agents that already support MXC. For adjacent sandbox coverage already on this site, see GitHub Copilot’s local sandboxing GA (which names MXC as the powering layer) and our AI agent sandboxing explainer.
How does MXC draw the boundary?
The blog’s core security claim is that an agent cannot be its own security authority. Containment is meant to stop a coding agent that “reasonably” wants to rewrite production server configuration from doing so when that path was never granted. Policy stays outside the workload, so generated code cannot grant itself additional access.
Policy areas listed in the GA post cover containment backend choice, process launch settings, filesystem read/write/deny lists, network inbound/outbound rules (including loopback), and whether the workload may interact with the desktop UI. On Windows only, process containers can emit an agent activity report. Three operating modes are described: Enforcement (deny ungranted access), Learning (deny and record), and Permissive (allow and record)—the last intended for policy authoring, not production trust.
The README’s feature list matches that story with more engineering detail: JSON configuration, platform-appropriate backends (ProcessContainer, Windows Sandbox, LXC, Bubblewrap, Seatbelt, MicroVM, Hyperlight, IsolationSession, WSLC), and diagnostics for access-denied failures. We did not execute a create-and-run sample.
| Backend | Availability (blog) | Notes from the post |
|---|---|---|
| Process container | Windows 11, macOS, Linux | AppContainer / Seatbelt / Bubblewrap for lighter workloads |
| Session container | Windows 11 only | Separate account/session; isolated desktop, clipboard, UI, input |
| WSL container (WSLc) | Windows 11 only | Linux toolchain via WSL |
| MicroVM | Windows 11 and Linux, experimental | Hardware-backed isolation; still experimental in the table |
What ships today versus what is still coming?
GA language in the posts applies to MXC containment and to Windows 365 support for MXC. That is distinct from the manageability and identity layers the same posts advertise. Iyer writes that Windows will soon enable Microsoft Entra to distinguish agent activity from user activity and extend Microsoft Agent 365 controls to local on-device agents. Intune policy will soon manage MXC process containers on Windows 11.
Readers should keep those “soon” clauses out of any checklist that claims enterprise rollout completeness on 7 October. The open SDK and JSON schema are the verified developer surface; org-wide policy injection through Intune is promised, not demonstrated in the GA posts we opened.
If you are comparing open agent sandboxes rather than Windows platform controls, our notes on NVIDIA OpenShell and AWS Strands Box on Dogwood sit in the same design space—runtime fences outside the model—with different host matrices and licenses.
Which agents does Microsoft say already use MXC?
The Windows Developer Blog lists current support for GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio, and Unsloth AI, and says NVIDIA integrated OpenShell into MXC. A longer “coming” list includes Anthropic Claude Code, Box, Egnyte, Heidi Health, Hermes Agent by Nous Research, Manus, Perplexity, Raycast, and Simular. The hybrid-intelligence post also says Meta’s Muse for Windows is coming as a native app with MXC integration.
Those names are Microsoft’s partnership and roadmap statements. They are not independent audits that each product’s default install enables MXC on every OS. For Copilot specifically, GitHub’s earlier local-sandboxing documentation (covered separately here) already described MXC as the enforcement engine and noted that local sandboxing can be off until enabled.
If you evaluate an agent that claims MXC support, verify the backend matrix on your host OS, whether Learning/Permissive modes are exposed, and whether organizational policy can tighten the agent’s declared needs. Silent failure when Intune later denies a path is exactly the failure mode the blog warns developers to design for.
How should builders try MXC without overclaiming?
The README points installers at crates.io/crates/mxc-sdk, the NuGet package Microsoft.Mxc.Sdk, and npm package @microsoft/mxc-sdk. Node and .NET packages include native runtime assets; the Rust crate builds selected backends into the consuming application. Non-SDK consumption via platform executor binaries accepting JSON from schemas/stable/ is documented for testing.
A practical first pass is to wrap a single tool-using agent path—not your whole IDE—in a process container with a deny-by-default filesystem list limited to the repo and toolchain, network limited to required package and model endpoints, and UI access denied. Run once in Learning mode on Windows to capture denials, then move to Enforcement. On macOS or Linux, confirm the Seatbelt or Bubblewrap backend matches the README host table before you promise parity with Windows session isolation.
Limitations to keep explicit: MicroVM is experimental; session containers are Windows-only; Intune and Entra pieces are not GA in the posts we reviewed; and Ai Lookout did not measure latency overhead or breakout resistance. Vendor lists of supporting agents can change faster than documentation.
Common questions
Is MXC only for Windows?
No. The 7 October blog and README both describe process-container backends on Windows 11, macOS (Seatbelt), and Linux (Bubblewrap). Session containers and WSLc are Windows 11-only in the table we opened.
Does GA include Intune controls?
Not according to the GA posts. Iyer writes that Intune policy will soon manage MXC process containers on Windows 11. Entra distinguishing agent activity from user activity is also framed as coming soon.
How does MXC relate to NVIDIA OpenShell?
The Windows blog says NVIDIA has integrated OpenShell into MXC, adding controls for files, inference services, advanced networking, credentials, and enterprise OCSF auditing. That is Microsoft’s partnership claim; we did not verify a joint binary.
What to remember
MXC’s useful 7 October signal is a cross-platform SDK and GA wording for OS-enforced agent boundaries—while session isolation stays Windows-centric and org-wide management knobs are still pending.
Sources & further reading
How this story was made
Written by Kristian Kostov with AI assistance and checked against the linked sources. Company performance claims are attributed to the company. Analysis reflects AiLookout’s interpretation; we have not independently tested the products discussed. Cover photography is illustrative and does not depict the specific announcement or product.
Our editorial standards
