The Agent Sandbox Moved Out of the Model and Into the Operating System

Every agent framework has been building its own sandbox. Windows just took that job, and the policy that decides what an agent may touch now lives outside the agent.

Microsoft published the general availability release on 7 October, at a Windows and Surface event in San Francisco.

The policy is enforced outside the agent

That placement is the design. A framework that contains its own agent enforces the limit from inside the process it is limiting, so an overreaching agent sits inside the trust boundary it was meant to respect. Microsoft Execution Containers move the decision into the operating system instead. Microsoft’s security team frames the same problem as a new risk surface in local agents and open runtimes. An administrator names the resources an agent may use, the files and the network destinations, and the platform picks an isolation primitive and applies the policy at runtime.

Microsoft describes the intent as containing model-generated code, plugins, tools, an agent harness or the entire agent under one policy. That matters for how enterprises buy. When containment is a framework feature, every team evaluates it separately and the answer depends on which tool that team happens to run. When it is a platform feature, the answer is a policy that follows the agent onto the machine.

Four backends, and the trade is isolation against overhead

MXC does not treat every workload as if it needs a virtual machine. The lightest option is a process container, which uses AppContainer on Windows, Seatbelt on macOS and Bubblewrap on Linux, and suits generated code and tool calls where latency is visible to the user. A WSL container gives an agent that depends on Linux packages a Linux execution environment, on Windows 11 only. A session container runs the agent under a separate Windows account and session, so its desktop, clipboard, input and active session sit apart from the person using the machine. The heaviest is a MicroVM, experimental and offered on Windows 11 and Linux, for workloads that justify a hardware-enforced boundary.

The backends are not interchangeable. Each one trades startup cost and compatibility for the strength of the boundary, and the interesting engineering sits in letting a support agent and a coding agent run on the same laptop under different policies without the developer managing isolation primitives directly. The MXC source and schema are public.

The support list is the part to watch

Containment only helps when the agent people actually run respects it. Codex, GitHub Copilot, OpenClaw, Replit, LM Studio and Unsloth AI already support MXC, and NVIDIA arrives through an OpenShell integration. Microsoft lists Claude Code, Box, Egnyte, Manus, Perplexity, Raycast and Simular as coming. Hermes Agent, from Nous Research, appears on that coming list too.

The gaps are operational. Intune management of MXC process containers on Windows 11, including control over container creation requests and the boundaries they enforce, is listed as coming rather than shipped, and so is Microsoft Entra support for telling agent activity apart from user activity in Agent 365. Microsoft set the direction out earlier in a post on Windows platform security for agents. Until that identity layer lands, an audit trail shows what a container permitted more reliably than it shows who the agent was acting for.

Three questions for anyone running agents on managed Windows fleets. Which of your agents can live in a process container and which need a session boundary. What a least privilege policy for a coding agent looks like once somebody writes it down. And whether your evidence survives a review that asks an agent to prove what it was allowed to do.

Related reading. Prompt injection in MCP is a trust problem between agents, and rogue AI agents cost Wikimedia real money without ever breaking in.