Microsoft MXC Brings Policy Controls to AI Agents

A coding agent can have permission to edit a repository without permission to change production configuration or browse a user’s personal files. Microsoft Execution Containers (MXC), which Microsoft announced as generally available on October 7, 2026, provides an execution boundary intended to enforce those distinctions outside the agent itself.

The release gives developers a cross-platform SDK and JSON policy model for containing agent workloads. Windows adds platform-specific options, including a separate session with isolated desktop, clipboard and input boundaries. Developers can integrate through Node,.NET or Rust without waiting for the accompanying enterprise management roadmap.

According to Microsoft, MXC containment is shipping now. Entra-based attribution of agent activity, Intune policy management and expanded Agent 365 controls for local agents are still upcoming. The software also warrants attention independently of Microsoft’s accompanying Surface announcements: developers can consume the SDK through package managers, without treating containment as a feature of a particular new device.

The Agent Does Not Control Its Own Permissions

MXC is an execution layer for untrusted code and dynamically generated workloads. Developers can place model-generated code, plugins, tools, an agent harness or an entire agent inside its boundary.

The application or organization declares which resources the workload needs, and the selected containment backend enforces those permissions. Microsoft says the policy remains outside the workload’s control, so generated code cannot simply grant itself additional access.

Microsoft illustrates this with a website-maintenance task. An agent might receive read-write access to the source repository and read-only access to production configuration. Attempting to modify that configuration should then fail at the containment boundary, even if the model considers the modification necessary to finish its task.

Asking an agent not to touch a directory depends on its behavior. Withholding access makes that directory unavailable to the contained workload. That is the useful distinction between an instruction and a restriction.

The intended resource model is deny-by-default: access beyond the declared boundary must be granted rather than assumed. This does not guarantee that every backend implements every control identically, or that an incomplete policy is automatically suitable for production.

MXC policies cover filesystem access, inbound and outbound networking, host-loopback connectivity and UI resources. They also describe how the workload starts, including its command, arguments, working directory and environment. The containment choice determines which execution environment applies those controls.

An agent can still make a bad change inside a writable repository. Containment limits its authority; it does not determine whether an authorized action is correct.

Cross-Platform Policies Do Not Mean Identical Isolation

The MXC repository documents Windows, Linux and macOS support, with a common configuration model mapped to platform-specific backends. Developers specify the container type, containment rules and workload command; MXC validates the request and launches the workload through the selected backend.

Microsoft’s announcement describes four principal options:

The repository lists additional backends, including Windows Sandbox, LXC and Hyperlight, and marks several options experimental. General availability of MXC should therefore not be read as general availability of every backend.

Windows session containment is especially relevant to desktop automation. A separate account and session give an agent a place to operate without sharing the interactive user’s desktop and clipboard. That local agent identity is already part of the session design; the upcoming Entra attribution feature is separate.

WSLc serves workloads that depend on Linux tooling. Its presence in the same SDK does not make it interchangeable with either a process sandbox or a hardware-backed MicroVM.

Developers building AI products get a shared integration model, but backend prerequisites and security properties still need evaluation against the workload. There is no uniform security promise across operating systems. Microsoft also says Windows 365 support for MXC is generally available, extending the deployment options to Cloud PCs.

Start With the Node,.NET or Rust SDK

MXC is an SDK dependency incorporated into an application. Developers do not need to clone and build Microsoft’s repository; the documented packages can be added with the usual package-manager commands:

# Node
npm install @microsoft/mxc-sdk

# .NET
dotnet add package Microsoft.Mxc.Sdk

# Rust
cargo add mxc-sdk

The Node and.NET packages include native runtime assets. The Rust crate builds the SDK, engine and selected backends into the consuming application.

The repository’s SDK example shows a small Node workload with outbound network access denied:

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);

The example demonstrates the launch API and an explicit deny-by-default egress rule. It is not a complete coding-agent policy: it does not describe a repository’s read-write permissions, configuration files that should remain read-only, or all relevant UI and network restrictions.

A useful first integration would select the intended backend, launch a trusted workload and then add only the resources required for its task. For a coding agent, that means identifying the source directory, build tools, package caches and any necessary network destinations, instead of inheriting the signed-in user’s full access.

For agents running repeated tasks, the SDK also supports a state-aware lifecycle: provisioning, starting, executing, stopping and deprovisioning persistent containers. The integration can therefore manage more than a single process launch.

When embedding an SDK is impractical, the repository documents platform-specific executors that accept JSON container-creation requests. On Windows, wxc-exec.exe is one such option.

Policy Diagnostics Come With an Important Warning

Least-privilege policies are difficult to write when a workload’s dependencies are not yet known. A build tool may need files or capabilities that are not obvious from its command line. MXC’s repository explicitly warns that applications can encounter access failures until their containment rules are tuned.

Microsoft describes Windows process-container activity reporting to help developers understand attempted resource use. The repository also documents debugging and policy-authoring workflows, including audit mode:

wxc-exec.exe --audit policy.json

According to the repository, --audit turns off all sandbox security for the workload being analyzed. It must not be used to run untrusted code.

Audit mode can help discover the needs of a trusted workload, but it cannot keep an agent contained while observing it. Developers should distinguish that workflow from diagnostics that preserve enforcement and record denied access.

Observed access also needs judgment. A resource appearing in an activity report does not automatically mean it should be allowed. Otherwise, policy discovery risks reproducing an application’s broad existing permissions.

Entra, Intune and Agent 365 Remain on the Roadmap

Microsoft’s broader Windows messaging presents containment, identity and manageability as a combined security model. The developer announcement draws a narrower shipping boundary:

• Available now: MXC containment, SDK integration and the documented execution backends, subject to platform support and experimental status.
• Coming soon: Entra capabilities to distinguish agent activity from user activity.
• Coming soon: Intune policies for managing MXC process containers used by integrated agents on Windows 11.
• Coming soon: Agent 365 controls extended to local agents, including container management, policy application and activity monitoring.

The forthcoming Intune layer is intended to constrain container-creation requests and the resource boundaries Windows enforces. Microsoft says developers should expect organizational policy to be more restrictive than an application’s default configuration.

Even before centralized management arrives, agents need to handle denied access explicitly, explain which task could not be completed and offer an appropriate alternative or permission-request path when supported. Silent failures, or assumptions that the application’s preferred permissions will always be granted, will make enterprise deployment harder.

Listed Agent Support Is a Starting Point, Not a Guarantee

Microsoft’s Windows platform announcement lists OpenAI Codex, GitHub Copilot, Replit, LM Studio and Unsloth AI among products already supporting MXC. It also names OpenClaw and NVIDIA OpenShell. Claude Code and several other products are listed as forthcoming.

These are Microsoft’s integration claims. The announcement does not establish that every version, execution path or tool call in each named product is contained. Developers and administrators still need to check the integration they actually deploy, including the selected backend and effective policy.

Developers can start moving permissions out of the agent’s decision-making loop today, without waiting for new Surface hardware or the full enterprise identity and management stack.

The strongest deployment evidence will be more specific than an ecosystem logo list: which workload runs inside MXC, which resources it can reach, and what happens when it attempts a forbidden action. Those are the checks that turn an available SDK into a useful security boundary.