Microsoft Execution Containers give developers a way to restrict what AI agents can access. This article explains the execution boundaries, platform differences, practical permissions, and security limitations that teams should understand before deployment.

An AI agent can damage a system without ever intending to. A request to fix a failing application may lead it to rewrite a deployment setting or modify files beyond the project. To the agent, these actions may look like progress. For the organization, they could mean an outage or a security incident.

Microsoft Execution Containers (MXC), which reached general availability on October 7, 2026, address this problem by placing an execution boundary outside the agent’s control. Developers define which resources a workload may access, and the selected containment backend enforces those restrictions independently of the model’s decisions.

As AI agents take on more operational responsibility, that separation matters. Teams need a way to delegate useful work while keeping unrelated files, credentials and systems beyond the agent’s reach-even when it decides that crossing those boundaries would help complete the task.

Why AI Agents Need Execution Boundaries

Agent workflows assemble commands and tool actions dynamically. A task that begins with reading a file can lead to running a script, launching another process or contacting a service. Reviewing the initial instruction does not reveal every operation that will follow. A mistake need not be malicious to cause damage. An agent might decide that changing a deployment setting is necessary to make a test pass. Prompt injection introduces another route to unintended actions: instructions embedded in retrieved material can attempt to redirect the workflow.

Microsoft’s containment approach keeps permission decisions outside the workload being restricted. The agent can choose its next action, but it cannot grant itself additional access within that enforced boundary.

What Microsoft Execution Containers Actually Do

MXC provides a common execution interface over different isolation technologies. In its terminology, a workload is the command or program being run; a backend implements the environment containing it.  Developers integrate the SDK, specify containment requirements and launch the workload. The public SDKs support Rust, .NET and Node. They offer one-shot execution and lifecycle operations for supported persistent containers, including provisioning, starting, executing, stopping and deprovisioning.

This differs from assuming that every workload must run in a Docker-style container image. MXC includes native process sandboxes as well as other isolation options. The appropriate choice depends on the operating system, the workload and the required controls.

A Practical Example: Restricting a Coding Agent

Consider a hypothetical agent asked to repair an application and prepare a patch. A proposed access policy could look like this:

This is an illustrative design, not a tested MXC configuration. Each restriction needs to be checked against the deployed backend. The example also exposes a common policy mistake: granting an entire home directory because a build tool needs one cache folder. The narrower grant takes more work to establish, but leaves fewer unrelated resources within reach.

Deployment deserves its own authorization decision. An agent preparing a patch should not receive production credentials simply because they are available on the host.

How MXC Isolation Differs Across Platforms

The current MXC repository lists different default backends:

Other options include Windows session isolation, WSL containers and LXC. The repository marks Windows Sandbox, MicroVM and Hyperlight as experimental options on Windows. Network filtering and other controls remain backend-dependent.

Windows session isolation separates the agent from the user’s active environment through a distinct account and session, including desktop, clipboard and input boundaries. This serves workflows requiring separation beyond a lightweight process sandbox.  A common policy model therefore does not promise identical protection on every machine. Teams must validate the selected backend’s capabilities. MXC should not be described as automatically choosing the “strongest available” sandbox.

Windows updates matter too. The current support table lists Windows 11 24H2 process isolation at build 26100.9278 and session isolation at 26100.9550. Requirements differ across releases, so the published support table should guide deployment.

What “Supports MXC” Means in Practice

Microsoft names GitHub Copilot, OpenAI Codex, Replit and LM Studio among products supporting MXC. That makes the technology relevant to existing workflows, but a support announcement does not describe every action’s execution boundary.

Microsoft’s Copilot documentation illustrates the distinction. With sandboxing enabled, shell commands and, by default, local Model Context Protocol (MCP) servers and language servers run inside the process boundary. Built-in file tools receive policy checks within Copilot’s agent harness-the software coordinating the model and its tools. Those checks are not OS-enforced child-process isolation. Remote MCP servers also remain outside the local process sandbox, with applicable connection checks performed in process.  For adopters, the useful question is which processes, tools and connections are actually contained. A product’s integration details matter as much as its sandbox setting.

Learning Mode and Permissive Mode Are Different

Policy development can be awkward. A test runner may need a temporary directory that was omitted; a package manager may depend on a cache path the author overlooked.

On supported Windows process-container backends, MXC provides diagnostics for identifying such access requirements. Microsoft distinguishes three operating modes:

Learning mode preserves containment while helping developers diagnose failures. Permissive mode relaxes enforcement to observe access patterns.The repository warns that audit mode must not be used to run untrusted code.

A practical starting point is to reproduce legitimate workflows under enforced restrictions, inspect denials and add only justified permissions. Automatically granting everything a workload attempted to access would undermine the purpose of learning from those records.

Containment Still Leaves Decisions to the Application

The architectural implication is straightforward: an agent can make harmful changes within permissions it legitimately holds. Write access to a repository permits useful edits, but can also permit deletion or corruption of project files. An authorized API credential may allow business operations that a filesystem sandbox cannot judge. Allowing a network destination does not establish whether every request to it is appropriate. Containment consequently belongs alongside version control, backups, restricted credentials and application-level authorization. Human approval can remain appropriate for payments, production releases and other consequential actions. These controls address different failure paths. MXC limits resource access; the surrounding application must still decide which business actions are authorized.

What Enterprises Can Use Now-and What Is Coming

Microsoft’s October announcement confirms Windows 365 support for MXC. It also describes Entra-backed agent attribution through Microsoft Agent 365 and Intune management of Windows 11 MXC process containers as forthcoming.

Those timelines should remain separate. Available containment does not establish that every planned identity, reporting or management feature has shipped. Before adoption, teams should choose one bounded workflow, map its resource needs and verify the complete execution path. Test a blocked file write, an unauthorized network request and a tool requiring an omitted resource. Check that failures reach the operator clearly, then review permissions whenever connectors or tools change.

Making Agent Permissions a Deployment Decision

MXC gives teams a practical mechanism for restricting agent execution. The work of defining those restrictions still belongs to the people deploying the system. A useful first deployment gives an agent enough access to complete one clear task, verifies where enforcement applies and handles denied actions explicitly. That creates evidence for expanding its responsibilities later. For organizations moving agents into operational workflows, this is a more defensible starting point than granting broad access and relying on the model to exercise restraint