Microsoft made Microsoft Execution Containers (MXC) generally available on October 7, 2026. For teams that run commands proposed by an AI agent, the practical question is which files and network connections the command needs, and which MXC backend can enforce those limits. Microsoft's launch post describes the containment goal; the repository's consumer documentation provides the authoring details. This guide follows those documents. BIG CHANGE did not install MXC or run a contained workload.

The big change

  • What changed: Developers can pass a command and its resource policy to one MXC SDK interface, which selects a supported host backend. The October 7 release makes this a documented integration path for agent tools rather than a policy a model must obey voluntarily.
  • Why it matters: A team can give a coding command access to its working directory while requesting that other file locations and outbound connections stay outside the workload's authority. The effect depends on the selected backend and host, so the team must check the backend's actual enforcement before trusting a restriction.
  • What to watch: Microsoft's policy-authoring modes help diagnose blocked operations on supported Windows ProcessContainer hosts. The next practical decision is whether a proposed grant is necessary, and whether the production run uses enforcement after the policy is narrowed.

Start with the host and the command

MXC is a library integrated into the application that launches the workload. Its README lists Rust, .NET and Node SDKs, plus native executor binaries for applications that cannot embed an SDK. The Node package includes native runtime assets and requires Node.js 24 or later; on Windows, the repository specifies Node 24.21.0 or later, or 26.8.0 or later, for native stdio transfer. Its public API is imported from @microsoft/mxc-sdk/v1, not the package root. The .NET package also includes native assets. The Rust crate builds the SDK, engine and selected backends into the consuming application. Native executors require a platform build of the repository.

Choose the backend before writing a policy. The repository lists processcontainer as the Windows 11 default, bubblewrap as the Linux default and seatbelt as the macOS default. Windows also offers wslc and isolation_session; windows_sandbox, microvm and hyperlight are marked experimental. Linux requires the selected runtime, such as Bubblewrap for its default backend. The Windows version table gives minimum builds for ProcessContainer and IsolationSession. Host availability and requested policy support still need validation on the machine that will execute the work.

Write down the actual command, working directory, files it must read, files it must change and network destinations it needs. Treat those as policy inputs supplied by the application or operator. Microsoft says the policy sits outside the agent workload, so generated code cannot enlarge its own permissions. The command's expected output is its normal stdout, stderr and exit status, plus warnings or optional metadata returned by the SDK. An activity report is available only in documented diagnostic modes on supported Windows ProcessContainer hosts.

Declare a small policy with the Node SDK

The Node SDK guide documents this V1 shape. Install the SDK into an application running a supported Node release:

Terminal
npm install @microsoft/mxc-sdk

This example adapts Microsoft's run-to-completion sample and requests read-only access to the application's current directory while denying egress. The command itself only prints a line, so it does not exercise either restriction. It is a documented starting point, not a BIG CHANGE test. Replace the command and paths with the workload being contained; use readwritePaths only for directories it must modify.

TypeScript
import { getPlatformSupport, run } from '@microsoft/mxc-sdk/v1';
import type { ContainerRequest } from '@microsoft/mxc-sdk/v1';

if (!getPlatformSupport().isSupported) {
  throw new Error('MXC is not available on this host');
}

const request: ContainerRequest = {
  command: 'node -e "console.log(\'hello from container\')"',
  filesystem: { readonlyPaths: [process.cwd()] },
  network: { egress: { default: 'deny' } },
  timeoutMs: 30_000,
};

const result = await run(request);
console.log(result.stdout, result.stderr, result.exitCode, result.warnings);

run returns captured stdout and stderr, exit code, timeout state and warnings. A blocked file access can appear to the workload as an ordinary access-denied error; a successful exit alone does not prove every intended restriction was exercised. For the assignment's success criterion, run a trusted workload that uses an allowed resource and a separate deliberate access probe against an ungranted resource on the chosen supported backend. Check the resulting operation and diagnostics before using the policy for agent-generated commands. The SDK samples cover filesystem grants, a network block, captured output and denial logging. They require a prepared host. None of these steps was executed by BIG CHANGE.

For native executor users, the stable JSON schema is 1.0.0, and a complete request needs a version, containment selection and process.commandLine. The current development schema is 1.1.0-alpha. The V1 SDK chooses its wire contract itself, so do not put a native schema version into the typed ContainerRequest. The schema guide also says old fields such as network.defaultPolicy and allowedHosts are retired. Current policy uses directional network.egress and network.ingress; direct rules and a runtime proxy have different behavior and backend support.

Diagnose denials, then enforce

Microsoft's October 7 mode table distinguishes three outcomes. Enforcement blocks ungranted access and produces no activity report. Learning blocks and records ungranted access. Permissive records the access that policy would deny but allows it to continue. Microsoft's denial-capture reference limits those learning capabilities to Windows AppContainer-based ProcessContainer paths. Other hosts do not gain equivalent reporting merely because they accept a shared policy field.

For a trusted tool during policy authoring, the Windows native executor supports an --audit flow that can produce policy artifacts. Microsoft warns that it turns off sandbox security for that analyzed workload, so it is unsuitable for untrusted commands. A deny-and-record capture is the safer diagnostic path when the host supports it: the attempted access stays blocked while the report identifies what was denied. Review each recorded path or capability against the task, grant only what the command needs, and run the final workload in enforcement mode. Reports can expose sensitive resource names; handle them accordingly.

Backend choice changes what the policy can promise. The schema guide says isolation_session cannot restrict networking and requires an explicitly unrestricted network posture. It also says UI restrictions are enforced by Windows ProcessContainer and macOS Seatbelt, while other backends do not implement them; WSLC and IsolationSession refuse supplied UI policy. The Seatbelt guide says macOS cannot filter individual remote hosts through its native profile, and the Bubblewrap guide describes its Linux runtime and network prerequisites. A JSON field being accepted across SDK types is therefore not evidence of equal enforcement everywhere. Check the selected backend guide and validate the request on the target host.

Microsoft's repository carries an MIT license, but its consumer documentation does not list an MXC package price. The host, compute and any model provider still have their own costs. The Windows announcement calls MXC generally available, while several backend options remain experimental and the native development schema is alpha. Keep those release stages separate when deciding where to run a workload.

Sources & further reading

  • Microsoft Windows Developer Blog, October 7, 2026 establishes the launch claim, intended agent use and three mode definitions. It is Microsoft's description of its product, not a BIG CHANGE security test.
  • MXC repository README lists SDKs, host defaults, experimental backends, build prerequisites and native executor route. It changes with the repository; details were checked October 8, 2026.
  • Node SDK consumer guide specifies Node prerequisites, the V1 import, typed request and captured output. The code above is adapted from its sample; it was not run here.
  • Configuration schema guide distinguishes current stable 1.0.0 native JSON from mutable 1.1.0-alpha and documents policy fields and backend-specific limits.
  • Learning-mode and denial-capture reference documents Windows ProcessContainer diagnostics and warns about permissive audit. Its reports are host and mode dependent.
  • Backend guides and the Windows version table are the checks to use for a particular host; this article does not certify any configuration on a reader's machine.