Microsoft Execution Containers Introduces Configurable Security Boundaries for AI Agents on Windows

Suppose an AI coding agent needs to fix a failing test. It must be able to read the project, edit source files, and run the test suite. But should that same agent also have permission to open your personal documents, read credentials in another directory, or send files to an unfamiliar server?

Running an agent under your everyday Windows account tends to bundle these permissions together. Even a task that only requires access to one repository can end up granting access to a much broader area.

Microsoft Execution Containers (MXC) is designed to make this boundary explicit. According to the release report provided, Microsoft has made MXC generally available on Windows 11, allowing developers to restrict the files and networks an agent can access. A Windows Developer announcement dated October 7, 2026, explains that these policies are enforced at runtime.

The practical change is straightforward. Developers can define an agent’s operating boundaries separately from the instructions given to the AI model. This provides a firmer foundation than simply asking the agent to behave carefully.

How MXC Changes Agent Execution#

Traditional desktop applications typically run with permissions inherited from the user who launches them. AI agents can exercise those permissions through the tools they are given, including terminals, browsers, file operations, and application integrations.

This creates a mismatch. A user authorizes an outcome, such as “organize this folder,” while the software may receive access that also allows it to modify unrelated data.

MXC provides an isolated environment for running agents. According to the release report, developers can place an entire agent inside that environment or isolate individual components, such as plugins, tools, and agent harnesses. Generated artifacts can also remain within the environment.

This matters because different parts of an agent system carry different risks. A planning component might only need to produce text. A tool that executes generated commands, however, needs a more carefully defined boundary.

Reported capabilities include access restrictions, separation of human and agent activity, and monitoring of agent actions. Together, these help developers limit what an agent can do and distinguish its actions from the user’s own work.

These capabilities do not, however, guarantee that the agent’s decisions are correct. An agent can still make harmful changes to files it is allowed to edit.

Four Isolation Options for Different Uses#

MXC offers multiple backends rather than treating every agent as the same kind of workload. The release report lists the following four options.

| Backend | Boundary described in the report | Suitable uses | |---|---|---| | AppContainer | Process isolation through Windows AppContainer | Coding agents and individual tool executions | | Session container | Separation of account and interactive session resources | Long-running agents that operate a desktop | | WSL container (WSLc) | Container-based isolation within WSL | Workloads that require a Linux environment | | MicroVM | Hardware-level isolation | Workloads that require a hardware-backed boundary |

These options need to be evaluated against the task and the consequences of something going wrong. The available report includes neither performance measurements nor a complete compatibility list, so there is no basis for declaring any one option the best default backend for every deployment.

AppContainer: Restricting Processes#

AppContainer is an existing Windows isolation mechanism. MXC offers it as a process-level option, and the report positions it for coding agents and tool execution.

Consider an agent modifying a local project. Its required working area might consist of a repository, a temporary directory, and selected development tools. Access to other user files adds risk without helping the task.

Process isolation suits this case because the work can be expressed as a bounded set of tool operations. You will need to consult Microsoft’s documentation to determine exactly which permissions can be granted to an application and how to configure them through MXC.

Session Containers: Separating an Agent’s Desktop Activity#

Long-running desktop agents have different requirements. They may need to operate applications, navigate the screen, and maintain an interactive session.

According to the release report, session containers run an agent under a separate account, isolating its desktop, clipboard, user interface, input, and active session from the human user.

This distinction matters. Running a desktop agent in the same session as a person can cause interference, such as shifting focus, overwriting the clipboard, or entering text into an unintended window.

Session isolation addresses these problems. It also means that application setup, authentication, and access to shared resources need to be thoroughly tested in the agent’s dedicated environment.

WSLc and MicroVM: Choosing the Boundary Your Workload Needs#

The other reported options are WSL containers and MicroVM.

WSLc provides container-based isolation within Windows Subsystem for Linux. MicroVM provides hardware-level isolation.

The question to consider is what each backend can isolate while still allowing the workload to function correctly. Linux development and Windows desktop automation may have different requirements. A tool that processes untrusted input may need a different boundary from an agent editing a small, well-maintained repository.

Whichever backend you choose, check its prerequisites, supported workflows, and operational behavior. The announcement alone does not establish these details.

Match File Permissions to the Task#

“Access to project files” sounds straightforward, but the picture changes when a project contains credentials, private data, or deployment settings.

To create a practical policy, first separate what the agent needs to read from what it needs to change. For a coding task, for example, you might configure:

• Read and write access to the repository being worked on.
• Read-only access to a separate reference directory.
• A dedicated location for temporary files and generated artifacts.
• No access to unrelated personal folders or credential stores.

This is a suggested deployment pattern, not a description of MXC’s configuration syntax or the granularity of controls available across all backends. Those details need to be checked in the documentation.

The principle is still useful: permissions should match the task at hand. If an agent is only updating documentation, carefully consider whether it really needs broad write access to application settings.

Also consider what happens after execution. Output files can still cause harm if someone opens or executes them outside the container. An isolated environment provides a place to inspect artifacts, but it does not make the artifacts themselves trustworthy.

Network Access Needs Its Own Policy#

An agent may need to connect to a model provider, download dependencies, or query internal services. Unrestricted network access, however, also gives a malfunctioning or manipulated agent a route for sending data outside the environment.

That makes the reported ability to customize network access in MXC just as important as file boundaries.

For an initial deployment, list the destinations the task requires. Clarify which services will receive source code or document contents and which are used only for downloads. Then check what MXC can enforce with your chosen backend.

Do not assume that the phrase “network policy” guarantees domain filtering, protocol controls, or visibility into encrypted traffic. The provided report does not explicitly describe those capabilities.

The goal is a policy you can test. If an agent needs access to an approved package source, verify that the access works. Then attempt connections that should be denied and check the results.

Isolation Limits Damage but Does Not Solve Prompt Injection#

Documents, web pages, and repository files can contain text that attempts to redirect an agent’s behavior. If the agent treats that text as instructions, it may attempt actions the user never requested.

Runtime restrictions can contain some of the consequences. If a boundary is correctly configured and enforced, attempts to read outside the permitted area should fail.

But an agent can also misuse access it has been granted. If it can read a confidential document and send its contents to an approved service, isolation alone cannot determine whether that transfer matches the user’s intent.

For this reason, access controls and action confirmation need to be considered separately. MXC can define the scope of permitted operations. Within that scope, the application still needs to handle consequential actions appropriately, especially sending messages, deleting shared data, and publishing changes.

A successful sandbox test provides evidence that the boundary works. It does not prove that every decision made within that boundary is safe.

Available Features and Details That Need Verification#

As of October 19, 2026, the provided report describes MXC as generally available on Windows 11. It also reports plans for organization-wide policy management through Microsoft Intune.

Treat this distinction carefully. General availability of the runtime does not necessarily mean that every announced management feature is available.

The report names OpenClaw and Anthropic Claude Code as partners associated with MXC support. It does not establish which product versions include the integration, whether it is enabled by default, or which backends it supports.

Before deployment, consult the latest documentation from Microsoft and each partner to confirm Windows requirements, installation procedures, available backends, and policy settings. Verify that the integration works in the versions you actually plan to deploy.

Start with One Bounded Task#

A good first test is a workflow whose access requirements are easy to explain, such as updating documentation in a disposable repository.

Evaluate it in four steps:

1. Define success. Specify the files the agent should change and the output it should produce. 2. Configure the boundary. Choose a backend and configure the necessary file and network access. 3. Test operations that should be denied. Attempt to read unrelated folders, write outside the workspace, and connect to unapproved destinations. 4. Review the results. Inspect the artifacts and any available activity records, including failed operations.

Keep credentials and important data out of the environment during the first test. Once you have confirmed that the task works, add permissions only when a need has been demonstrated.

MXC’s value depends on this operational discipline. Configurable boundaries are useful when they fit the actual task and have been tested under conditions where things do not go as expected.

Choose one agent workflow and write down the access it needs. Then use a disposable Windows 11 environment to verify that MXC allows the required work while blocking actions outside that scope.

Source: https://www.publickey1.jp/blog/26/windowsaimicrosoft_execution_containersmxc.html