Every AI coding agent has the same dirty secret: when it executes code, you’re trusting guardrails written in the same application you’re trying to protect. Microsoft’s answer isn’t another library or middleware — it’s the OS itself. Microsoft Execution Containers (MXC), now in public preview with SDK 0.7.0, puts a policy-driven sandbox between your AI agent and your system, declared in JSON and enforced at the kernel level before any agent code runs.
Application Guardrails Are the Wrong Layer #
The problem with catching agent mistakes at the application layer is that you’re trusting the same code that made the mistake. Application-layer guardrails live in the same process as the agent. They can be bypassed, misconfigured, or simply absent when a new edge case surfaces at 2 AM.
OWASP’s Agentic AI Top 10 (December 2025) put Unexpected Code Execution at the top of its risk list, with a blunt recommendation: “Never execute agent-generated code without strict sandboxing, input validation, and allowlisting.” That’s easy to say. MXC is the first tool that makes it practical at the OS level without requiring every developer to become a kernel engineer.
The shift MXC makes is conceptual as much as technical. Instead of “the application decides what the agent can do,” you get “the developer declares what the agent can do, and the OS enforces it.” That’s a different contract — and a much harder one to accidentally violate.
Four Tiers of Containment (and What’s Actually Usable Today) #
MXC isn’t one sandbox — it’s a dispatch layer that routes to the right isolation primitive based on how much containment you need. There are four tiers:
Process Isolation is the baseline and the only tier ready for real use today. It runs the agent in a restricted process using Windows AppContainer, locking down filesystem access and network to explicitly declared domains. Overhead is minimal, and it’s already what GitHub Copilot CLI uses in production when executing shell commands on your machine.
Session Isolation gives the agent its own Windows user identity and isolated desktop. This stops clipboard snooping, UI injection attacks, and input hijacking — the class of attacks where a compromised agent reads what you’re typing in another window. It’s in preview, so treat it as preview-grade.
Micro-VM backends (Hyperlight and NanVix) add hardware-backed isolation via Hyper-V — a meaningfully stronger boundary than a process sandbox. This tier is on the roadmap. WSL containers and Windows 365 for Agents (also roadmap) extend the same model to Linux environments and enterprise-managed disposable cloud PCs.
Getting Started: JSON Policy and the TypeScript SDK #
The SDK is one install away:
npm install @microsoft/mxc-sdk
From there, define a policy and hand it to the sandbox:
import {
createConfigFromPolicy,
getTemporaryFilesPolicy,
spawnSandboxFromConfig
} from '@microsoft/mxc-sdk';
const policy = getTemporaryFilesPolicy();
const config = createConfigFromPolicy(policy);
const result = await spawnSandboxFromConfig(config, agentGeneratedCode);
The SDK ships preset policies for common cases: getTemporaryFilesPolicy()
for agents that only need scratch space, getAvailableToolsPolicy()
for agents running declared tool calls. For more control, write the JSON policy directly — specifying filesystem paths, network allowlists, and a timeout. The versioned schema lives in schemas/stable/
in the MXC GitHub repository. MXC runs on Windows 11 24H2 and later, Linux (x64 and ARM64), and macOS (ARM64 and x64). The full API reference is in the @microsoft/mxc-sdk package on npm.
It’s Already Shipping in Copilot CLI #
If you want to see MXC in action without writing any code, open a GitHub Copilot CLI session and run /sandbox enable
. That session’s shell command execution now runs inside an MXC process container — the agent can suggest rm -rf ./dist
and execute it, but it can’t touch your home directory or reach the network unless the policy says so. This is process isolation tier in production, running across millions of Copilot sessions. OpenAI and NVIDIA are also named launch partners. The cloud and local sandboxes for GitHub Copilot changelog covers what’s enabled and what’s still preview.
The Enterprise Layer: Agent 365 #
MXC handles OS-level containment. Agent 365 — which went generally available in May — handles governance above that. It connects MXC to Entra (agent identity and least-privilege access), Defender (threat detection if an agent tries to escape its container), Purview (data governance for what agents can read and write), and Intune (pushing sandbox policies to developer machines across a fleet). The full Defender/Entra/Intune/Purview integration for MXC ships in July 2026, giving enterprise IT teams a centralized way to define what any AI agent is allowed to do on a developer’s machine.
The Honest Verdict #
Don’t treat any MXC policy as a production security boundary today — Microsoft’s own documentation says so explicitly, and there are known cases where current SDK-generated policies are overly permissive. Wait for 1.0 before building real security requirements on top of it.
That said, process isolation is solid enough for development workflows right now. The JSON policy model is clear, the TypeScript SDK is usable, and the direction is unambiguous: agent security infrastructure is moving to the OS layer. Google took the cloud-side approach with Cloud Run Sandboxes. MXC covers the local and OS-level half of the same problem. Both are worth understanding. The Windows platform security for AI agents post is the best starting point for the full architecture picture, and Help Net Security’s analysis of MXC’s constraints is worth reading before you ship anything agent-facing to users.