Microsoft ships Execution Containers 1.0 to sandbox AI agents on Windows, macOS and Linux

A 1.0 release for agent containment

Microsoft has released version 1.0.0 of Microsoft Execution Containers (MXC), a sandboxing layer built to run AI agents and other untrusted, machine-generated workloads inside boundaries that the workload itself cannot change. According to the Windows Developer Blog, which announced the release on October 7 in a post that reached the front page of Hacker News, MXC is now generally available, with support for running agents on Windows 365 Cloud PCs also generally available.

The release targets a problem Microsoft describes as a dilemma: organisations can either grant agents broad access to files, networks and applications and hope nothing goes wrong, or block agents entirely and lose their productivity benefits. MXC is positioned as the containment piece of a broader Windows strategy with three pillars — containment, identity and manageability.

The core idea: the agent is not the security authority

Microsoft's argument is that a boundary around an agent has to be defined by the developer or the organisation and enforced independently of whatever the model, generated code, plugins or tools decide to do. The blog gives the example of a coding agent asked to update a website: it legitimately needs read/write access to the repository and build tools, and may need to read production server configuration, but it should not be able to modify that configuration. An agent might reasonably conclude that editing the server config is the fastest route to completing its task — and still blow past the authority its developer intended.

With MXC, developers declare the resources a workload needs, such as specific files and network destinations, through a unified JSON configuration schema and multi-language SDK. The runtime enforces that boundary using the appropriate container backend, and because the policy lives outside the workload, generated code cannot grant itself additional access. The same declaration model is meant to work whether the agent runs on a local device or in the cloud, with MXC handling platform-specific containment details on Windows, macOS and Linux.

Four isolation levels

MXC offers a spectrum of backends, since a coding agent that needs low latency has different isolation needs from a workload processing sensitive data. According to the announcement:

• Process container — available on Windows 11, macOS and Linux; uses the native process sandbox on each platform (AppContainer on Windows, Seatbelt on macOS, Bubblewrap on Linux) and suits lightweight, responsive workloads like model-generated code and tool execution.
• Session container — Windows 11 only; runs long-running agents under a separate Windows account and session, isolating the desktop, clipboard, UI and input from the interactive user.
• WSL container (WSLc) — Windows 11 only; provides a Linux environment through WSL for Linux-first toolchains and workloads that depend on Linux packages.
• MicroVM — Windows 11 and Linux, labelled experimental; offers hardware-enforced virtualisation for higher-risk workloads.

Policies cover five areas: which containment environment the workload runs in; process settings such as command, arguments and environment variables; file system access split into writable, read-only and fully blocked locations; inbound and outbound network rules, including loopback behaviour; and whether the workload can touch the interactive desktop.

Enterprise management is still arriving

Microsoft frames MXC as a way to delegate more work to agents without handing them the full authority of the signed-in user. Two layers of policy are intended to compose: developers declare what their agents need, while organisations add constraints through management tooling, so the same agent can run inside different enterprise security postures.

Several pieces are not yet shipped. Intune policy for managing MXC process containers on Windows 11 is described as coming soon. Microsoft also says Windows will soon use Entra to distinguish agent activity from user activity, and will extend Microsoft Agent 365 controls to local on-device agents so IT teams can manage containers, apply policy and monitor activity.

On the developer side, Microsoft notes that integration can be bootstrapped with a coding agent itself drafting an initial workload policy via the MXC SDK, which a human then reviews and refines.

Why it matters

Agent frameworks have largely treated permissions as a prompt-level or harness-level concern, which means a misbehaving model, a poisoned plugin or a prompt injection can potentially escalate beyond what anyone intended. MXC moves enforcement to the operating system, applying traditional least-privilege sandboxing to workloads that are non-deterministic by nature. The cross-platform support — and the ability to run the same containment model from a laptop to a Cloud PC — matters for teams deploying agents in mixed environments.

The gaps are worth watching: the stronger isolation options are Windows-only or experimental, and central IT controls via Intune, Entra identity separation and Agent 365 integration are still on the roadmap rather than in the 1.0 product. What version 1.0 establishes is the enforcement model itself — an agent sandbox the agent cannot talk its way out of.