Microsoft Execution Containers Reach General Availability with Policy-Driven Agent Containment

AI agents deliver significant productivity gains by operating across files, networks, and applications. This same capability creates security risks that force organizations into an unacceptable choice: grant unrestricted access and hope for the best, or block agents entirely and lose their benefits. Microsoft Execution Containers (MXC), now generally available, provides a third option by enforcing policy-driven containment at the Windows platform level.

Why Agents Require Managed Execution Boundaries

An agent cannot act as its own security authority. It must operate within boundaries defined by developers or organizations and enforced independently of the agent itself. Consider a coding agent tasked with updating a website. The agent needs read and write access to the repository, access to build and test tools, and possibly read access to production server configuration to understand deployment. Without a managed boundary, the agent might decide modifying the server configuration is the fastest path to completion, potentially breaking the production site. The action appears reasonable from the agent's perspective yet exceeds the authority the developer intended to grant. Containment creates this boundary: the agent can read and write the repository, read the server configuration, but cannot modify it or access anything else unless explicitly granted.

How MXC Implements Policy-Driven Containment

MXC serves as a policy-driven execution layer for untrusted code or dynamically generated workloads. Developers declare the resources a workload requires — files, network destinations, tools — and MXC enforces the resulting boundary using the appropriate container backend. The policy remains outside the agent workload's control, so the agent or generated code cannot grant itself additional access. MXC separates workload requirements from platform-specific containment details, providing a unified JSON configuration schema and multi-language SDK while mapping controls to selected backends on Windows, macOS, or Linux. With Windows 365 support now generally available, developers can run agents on Cloud PCs using the right isolation model to keep execution separate and secure.

Containment Backends Match Isolation to Workload

Different workloads demand different isolation levels. MXC offers a spectrum of containment backends so developers and organizations can select the right level for each scenario.

  • Process container — Windows 11, macOS, and Linux. Lightweight containment for responsive workloads including model-generated code and tool execution. Uses platform-appropriate process sandboxes: AppContainer on Windows, Seatbelt on macOS, Bubblewrap on Linux.
  • Session container — Windows 11 only. Runs agents in a separate OS-isolated session with its own local agent identity and isolated desktop, clipboard, UI, and input boundaries. Runs under a distinct Windows account and session, separating the agent's active session from the user. Suited for long-running agents and automation needing a desktop or stronger separation.
  • WSL container (WSLc) — Windows 11 only. Provides a Linux execution environment through WSL for Linux-first agent toolchains and workloads dependent on the Linux package and development ecosystem.
  • MicroVM — Windows 11 and Linux, experimental. Hardware-enforced isolation with full Linux workload compatibility for higher-risk workloads benefiting from a virtualized boundary.

Each backend has distinct security properties. Workloads should be evaluated for fit with the chosen containment backend.

Policy Areas Define Precise Resource Boundaries

MXC policies define workload boundaries across five areas. Containment specifies the isolation environment — process or session container. Process controls the command, arguments, working directory, environment, and other startup settings. File system governs locations the workload can modify, read without changing, or cannot access. Network manages inbound and outbound connectivity, including loopback interface access. User interface controls whether the workload can access or interact with the desktop and related UI resources.

For the website scenario, a policy could grant a coding agent read and write access to its local source repository and access to Git, while preventing access to the user's Documents folder, blocking all network connections, and restricting desktop access. Adding MXC support is straightforward: developers integrate the MXC SDK, draft an initial workload policy, then review, test, and refine the controls.

Workload and Organizational Policy Layer Together

Agent developers declare resources their workloads may need. Organizations apply additional constraints through management policy such as Microsoft Intune. This allows the same agent to operate within different enterprise boundaries without the agent developer encoding the organization's security posture into the application. Intune policy will soon manage MXC process containers used by MXC-integrated agents on Windows 11, giving IT administrators control over how Windows evaluates container creation requests and the resource boundaries those containers enforce. Agent developers should design workloads to operate within boundaries that may be more restrictive than default configuration. If organizational policy blocks a resource, the agent should explain the task cannot complete within available permissions, request appropriate user or administrator action, or choose a safe alternative — not silently fail.

Three Operating Modes Support Policy Development

Writing least-privilege policy is difficult when you do not yet know every resource an agent workload requires. MXC supports three operating modes to address this. Enforcement mode applies the policy without activity reporting — granted operations proceed, ungranted operations are blocked. Learning mode enforces the configured boundary while blocking and recording ungranted operations in a JSON activity report, letting developers or IT reproduce containment failures and understand which resources the workload attempted to access. Permissive mode records access the policy would have denied but allows the operation to continue, useful during policy authoring because the workload completes while developers collect evidence about resource usage. Permissive mode does not bypass other applicable operating system or organizational restrictions. When bringing an agent into an MXC container for the first time, policy denials reveal where the boundary needs adjustment, helping grant required access without unnecessarily expanding the agent's reach.

Agent Identity and Attribution Coming to Windows

Containment answers what an agent may do. Identity determines which agent performed an action. Windows will soon enable Microsoft Entra to distinguish agent activity from user activity in Microsoft Agent 365. This separation allows security teams to evaluate an agent's behavior and risk independently from the person using the device. If an agent becomes compromised or violates policy, security controls target the agent's access to protected resources without blocking the employee's access. Agent-level attribution improves investigation and governance. Administrators will use Agent 365 to understand which agents are running, associate activity with a specific agent, investigate risky behavior, and apply policy to individual agents or groups instead of relying only on user-level or device-level context.

Ecosystem Adoption Underway

NVIDIA has integrated OpenShell into MXC, adding policy controls for agent access to files and inference services, advanced network controls, credential management, and OCSF auditing for enterprises. Leading agents and frameworks already supporting MXC include GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio, and Unsloth AI. Additional support is coming from Anthropic Claude Code, Box, Egnyte, Heidi Health, Hermes Agent by Nous Research, Manus, Perplexity, Raycast, and Simular. GitHub Copilot, Codex, and Replit demonstrate how MXC supports demanding developer workflows: coding agents need access to the project repository, development tools, and commands to complete tasks, but should not automatically gain access to unrelated files or network destinations. MXC preserves required capabilities while enforcing clear boundaries around the rest of the system.

Getting Started with MXC

Developers can start today with the MXC SDK, configuration schema, documentation, and samples in the MXC repository. Issues and feedback can be submitted on GitHub to help shape future development. With containment, identity, and manageability built into the platform, Windows helps agents run more securely while giving developers and IT control over what they can access and do.