Microsoft's MXC agent sandbox reaches 1.0, and the warning not to treat it as a security boundary is gone

Microsoft tagged v1.0.0 of MXC, its open-source sandbox for agent-generated code, on October 7. The same day, at the Windows and Surface event in San Francisco, NVIDIA's account of the keynote reports that "Microsoft announced general availability of Microsoft Execution Containers (MXC), the OS-level infrastructure that lets agents run safely and persistently in the background, under operating system control."

The day before, a three-line warning came out of the project README. That warning is the part worth reading.

What 1.0 ships

The release notes describe it as "the first stable release of the MXC SDK surface for Rust, .NET, and Node.js." The stable API lives behind explicit versioned entrypoints: mxc_sdk::v1 in Rust, Microsoft.Mxc.Sdk.V1 in .NET, and @microsoft/mxc-sdk/v1 in Node. "V1 is the stable compatibility boundary for the 1.x release line," the notes say, and MXC will follow semver 2.0 from here.

Callers pick one of three execution models: run to completion with captured output, spawn with pipes, or spawn with a PTY. A lifecycle API provisions a container, returns an opaque ContainerId, and starts, stops and deprovisions it. Migration is not optional for preview users: legacy request types are replaced by ContainerRequest, ProvisionRequest and ExecutionRequest, and applications must be rebuilt against the 1.0 packages.

The README's backend table shows what "cross-platform" means in practice:

On Windows, windows_sandbox, microvm and hyperlight are still marked experimental.

The warning that came out

Pull request #1388, merged October 6, deleted this block from the README:

There are known cases where the current policies generated by the MXC SDK in this repository are overly permissive and will be addressed before this is made more generally available. Security researcher partnership while MXC matures is welcome, however no MXC profiles should be treated as security boundaries currently.

MXC README, removed in PR #1388

The pull request's own description says only: "Removes the early-preview warning disclaimer from the main README." Neither it nor the v1.0.0 release notes say which overly permissive cases were found or confirm that each one was fixed. The 1.0 changelog does contain hardening work, including "Document and pin the default-deny ingress controls" (#1363), "Refuse process.env without inheritDefaultEnv" (#1339) and "Reject a blank ProcessContainer proxy peer" (#1348), but nothing in the release ties those entries to the cases the warning described. Readers who relied on that warning should treat its removal as a change in Microsoft's stated position, not as a published audit.

Where the docs still draw lines

The design documents shipped in the 1.0 tag are more candid than the announcement. Three examples:

• Windows Sandbox and denied paths. The container-lifecycle doc says the backend "honors deniedPaths only as a best-effort provision-time rejection (a .wsb mapped share cannot express a Deny ACE), not as a hardened security boundary."
• IsolationSession has no network policy. "The backend cannot filter or deny networking, so the caller must supply network.egress/network.ingress all-allow posture in the provision payload instead of requesting a network policy."
• Private networking on the default Windows backend is two-way. "Windows exposes privateNetworkClientServer as one bidirectional AppContainer capability. ProcessContainer therefore requires ingress.default: "allow" before the container can communicate with private-network addresses. Enabling it also permits private-network server traffic."

That last one matters for anyone sandboxing an agent that needs to reach a database on the LAN: granting outbound access to private addresses also opens inbound private-network traffic to the container. Egress rules can narrow where it connects; the capability itself is bidirectional.

What to check before you depend on it

The README's audit mode is useful for building a policy from what a trusted tool actually touches, but it carries its own warning: "--audit turns off all sandbox security for the workload being analyzed. Never use it to run untrusted code."

For a team evaluating MXC this week, the practical list is short. Import only from the v1 entrypoints, since that is the compatibility promise. Check which backend your request actually lands on, because the guarantees differ by backend and three Windows backends are still experimental. And if your threat model includes the network, read the per-backend networking doc rather than the summary: the default Windows backend's private-network behavior is not what a "deny inbound" mental model assumes.

Telemetry, for the record, is Windows-only and opt-in: per the README it stays off unless the run opts in, the user has consented, and administrative policy permits it.

Primary sources: MXC v1.0.0 release notes, PR #1388, MXC README, container lifecycle design doc, ProcessContainer networking doc, NVIDIA Blog: NVIDIA, Microsoft Kick Off a New Beginning for Windows PCs, read 2026-10-09.