MXC Policy Sandboxes for Agents

AI agents are becoming operational actors. They read files, call tools, run commands, and chain actions together faster than a human reviewer can follow every step. That is why Microsoft MXC is worth tracking for platform teams that need safer agent execution patterns.

What Is MXC?

MXC, short for Microsoft Execution Containers, is an early preview sandboxed code execution system for untrusted code such as model output, plugins, and tools. The project exposes a TypeScript SDK and a versioned JSON policy schema that maps to different containment backends across Windows, Linux, and macOS.

The important idea is one policy model for filesystem, network, UI, timeout, and lifecycle constraints, with the platform choosing an appropriate backend.

Microsoft is clear that this is preview software. Current profiles should not be treated as production security boundaries yet, and some generated policies may be overly permissive.

Key Features

• Cross-platform policy model for Windows, Linux, and macOS agent workloads.
• Multiple backends including Windows ProcessContainer, Linux Bubblewrap, LXC, macOS Seatbelt, and experimental VM-style options.
• Filesystem rules for read-only and read-write path lists.
• Network controls for outbound access and proxy-based constraints, with platform-specific limitations.
• State-aware lifecycle APIs for provision, start, exec, stop, and deprovision flows.

Installation

For SDK experiments, install the npm package:

npm install @microsoft/mxc-sdk

On Linux, the default backend is Bubblewrap, so the host also needs bwrap. LXC is available when its toolset is installed. Windows support targets Windows 11 24H2 or later for ProcessContainer, while macOS uses Seatbelt.

Usage

A simple evaluation starts with a narrow policy: allow the runtime tools the agent needs, provide a writable temporary directory, block outbound network access, and set a timeout.

import {
  createConfigFromPolicy,
  getAvailableToolsPolicy,
  getTemporaryFilesPolicy,
  spawnSandboxFromConfig,
} from "@microsoft/mxc-sdk";

const tools = getAvailableToolsPolicy(process.env);
const temp = getTemporaryFilesPolicy();

const config = createConfigFromPolicy({
  version: "0.6.0-alpha",
  filesystem: {
    readonlyPaths: tools.readonlyPaths,
    readwritePaths: temp.readwritePaths,
  },
  network: { allowOutbound: false },
  timeoutMs: 30000,
});

config.process!.commandLine = "python -c \"print('hello from sandbox')\"";

const child = spawnSandboxFromConfig(config, { usePty: false });
child.stdout!.on("data", (data) => process.stdout.write(data));

For SRE teams, the first useful test is not a flashy demo. Run a real internal agent task with no network, a read-only repository mount, and one scoped output directory. The failures show which permissions your agent actually needs.

Operational Tips

Keep policies task-specific. A code review agent, a build helper, and an incident investigation agent should not share the same filesystem or egress rules.

Log every sandbox spawn, command, exit code, and policy version. If agent output influences infrastructure, the sandbox trail belongs beside CI and break-glass audit data.

Pay attention to platform differences. The SDK notes that host allow and block lists are not enforced on Windows today, so teams should use default network policy or proxy controls there.

Conclusion

MXC is another signal that agent execution is becoming platform infrastructure. The strongest teams will make every tool call constrained, observable, and reversible.

At Akmatori, we think this is the right direction for SRE automation: agents should help operators move faster while staying inside clear guardrails. With infrastructure from Gcore, teams can build reliable automation layers close to production without giving up control.