Skip to content

Back to the catalog

microsoft/mxc
github.comrepo

microsoft/mxc

MXC is Microsoft's cross-platform sandboxed code execution system for running untrusted code such as LLM/agent output, plugins, and tools, offering containment backends ranging from OS-native process sandboxes (Windows Sandbox, LXC, Bubblewrap, Seatbelt) to full VMs (Nanvix MicroVM, Hyperlight). It exposes a unified JSON-based policy model for filesystem, network, and UI access controls, with Rust, .NET, and Node SDKs plus diagnostic tooling (audit mode, access-denied logging) to help developers tune containment rules for agentic workloads.

TL;DR Microsoft's cross-platform sandbox (MXC) for safely executing untrusted model/agent/plugin output via pluggable containment backends and policy-driven filesystem/network/UI controls.
Open original ↗
Also seen from another angle🧠 AI →
Document

What it is

MXC is Microsoft's cross-platform SDK (Rust, .NET, Node) that applications embed directly to launch untrusted code inside containment backends — ProcessContainer, Windows Sandbox, LXC, Bubblewrap, Seatbelt, Nanvix MicroVM, Hyperlight, IsolationSession, and WSLC. It ships as a library dependency, not a standalone service: the app links the SDK in-process, which selects and drives the backend.

How it works

flowchart LR
    App["Your application"] --> SDK["MXC SDK (in process)"]
    SDK --> Backend["Selected backend (in process)"]
    Backend --> Container["Isolated workload"]

The application supplies a JSON container-creation request specifying the container type, containment rules (filesystem/network/UI policy), and workload command; MXC validates it, picks the backend, and launches the workload. A separate non-SDK path exists: platform executor binaries (e.g. wxc-exec.exe) accept the same JSON schema directly, for testing or when the SDK can't be embedded.

Preconditions / Affected

Build requires Rust pinned to version 1.93 (src/rust-toolchain.toml) and Node.js 24+/npm, plus the toolchain for whichever backend is selected. All listed containment backends are explicitly marked experimental. Telemetry (Windows-only, no-op elsewhere) is off by default and requires four conditions to align: per-run opt-in, Windows user consent, admin policy permitting it, and the app enabling the option — an admin can block but not grant consent.

What to do

A minimal Node usage example from the page:

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

To debug access-denied failures while tuning policy:

wxc-exec.exe --debug config.json

To auto-generate a working policy from a trusted tool's actual access pattern:

wxc-exec.exe --audit policy.json

Caveats

The page's own warning: --audit disables all sandbox security for the workload being analyzed and must never be used on untrusted code — it's for policy authoring against trusted tools only. Build-from-source is only needed for development, native-runtime changes, or standalone executors; SDK consumers install via package manager and don't need to clone the repo.

Technologies named here

Techniques named here

  • Policy-driven sandboxing
  • Containment/isolation of untrusted code
  • Access-denied diagnostics
  • Audit mode policy authoring

Related in AI Security