Microsoft Execution Containers: A Boundary for AI Agents the Agent Cannot Edit

On October 7, 2026, Microsoft said Microsoft Execution Containers, or MXC, is now generally available. It is a policy-driven layer for running untrusted or model-generated code inside a boundary that the code cannot change. Microsoft frames it as the containment piece of a larger plan for running agents on Windows, with identity and management features still to come. Source

For teams building or buying agents, the useful part is not the Windows branding. It is the design rule behind it: an agent should not be its own security authority. This article walks through what Microsoft describes, which parts are available now and which are promised, and how to turn the idea into something your own team can do this month. It is based on Microsoft's announcement and the open-source repository. We have not run MXC ourselves.

The problem MXC is aimed at

Microsoft describes a coding agent asked to update a website. It needs to read and write the repository and use build tools. It may need to read the production server configuration to understand the deployment, but it should not change it. Without a boundary, the agent might decide that editing that configuration is the quickest way to finish, and break the live site. The action can make sense to the agent and still go beyond what the developer meant to allow. Source

That is a good test case for any agent project. The risk is rarely a movie-style rogue model. It is an ordinary goal pursued with more access than anyone intended. Prompts that say "do not touch production" are a request. A boundary enforced outside the agent is a control.

What MXC is

Microsoft calls MXC a policy-driven execution layer for untrusted code or dynamically generated workloads. In agent setups it can contain model-generated output, plugins, tools, the agent harness, or the whole agent. Developers declare what the workload needs, such as files and network destinations, and MXC enforces that boundary with a suitable container. The policy sits outside the workload, so the agent or generated code cannot grant itself more access. Source

The project is open source. Its repository describes a sandboxed code execution system for Windows, Linux and macOS, with a JSON configuration format, typed SDKs and several backends, from operating-system process sandboxes to full virtual machines. It lists filesystem policy with read-only, read-write and denied paths, and it carries an MIT license. Source

Microsoft says developers use one JSON configuration schema and a multi-language SDK, and MXC maps the requested controls to the chosen backend on Windows, macOS or Linux. Source

Four containment levels

Not every workload needs the same wall. Microsoft lists four backends. Source

A process container runs on Windows 11, macOS and Linux. It is a lightweight option for responsive work such as model-generated code and tool calls. It uses AppContainer on Windows, Seatbelt on macOS and Bubblewrap on Linux.

A session container is Windows 11 only. It runs an agent under a separate Windows account and session, with its own desktop, clipboard, UI and input boundaries. It suits long-running agents that need a desktop.

A WSL container, also Windows 11 only, gives Linux-first toolchains a Linux environment.

A MicroVM backend runs on Windows 11 and Linux and is labelled experimental. It offers hardware-enforced isolation for higher-risk workloads.

Microsoft adds that each backend has different security properties and workloads should be checked for fit. The usual trade-off applies: stronger isolation costs more in startup time and setup. Pick per workload, not per company.

What a policy controls

Microsoft's policy covers five areas: the containment type, the process to start (command, arguments, working directory, environment), the file system, the network, and the user interface. For the website example, a policy could give the agent read and write access to one repository and tools like Git, block access to personal folders such as Documents, block inbound and outbound network connections, and deny access to the interactive desktop. Source

Organizations can add their own limits on top. Microsoft says the same agent can then run inside different enterprise boundaries without the developer hard-coding a security posture. It names Intune policy for MXC process containers on Windows 11 as coming soon, not available today. Source

One design note is easy to miss. Microsoft tells agent developers to expect boundaries stricter than the default. If a resource is blocked, the agent should say the task could not be done within its permissions, ask for the right user or admin action, or pick a safe alternative. It should not fail silently. That is a good rule for any agent you build, with or without MXC. Source

Learning mode: write the policy from evidence

Least-privilege policies are hard to write when you do not know what a workload needs. Microsoft describes three modes. Source

In Enforcement mode, anything not granted is blocked and no activity report is produced. In Learning mode, anything not granted is blocked and recorded in a JSON activity report, so you can see what the workload tried to reach. In Permissive mode, ungranted access is allowed but recorded, which helps when you want to watch an agent without stopping it. Permissive mode does not bypass other operating system or organizational limits.

Microsoft says the activity report is available only on Windows process containers. If you run on macOS or Linux, you will need your own logging to get the same view. Source

The practical lesson carries beyond MXC: run a new agent in a recording mode first, read what it actually touched, then write the allow list from that evidence and switch to enforcement.

What is promised, not shipped

It helps to separate the announcement into what exists and what does not. MXC itself, including Windows 365 support, is described as generally available. Two other pieces are described as upcoming: Microsoft Entra will soon be able to tell agent activity apart from user activity, and Microsoft Agent 365 controls will extend to local agents on-device. Source

The reason identity matters is simple. If an agent runs as the signed-in user, its actions look like the user's actions in logs, and a compromise can force you to lock out the employee. Separate agent identity would let security teams act on the agent alone. Until it ships, plan your own attribution, for example a dedicated service account or a tag on every tool call.

Microsoft also lists agents that already support MXC, including GitHub Copilot, OpenAI Codex and Replit, and says others, including Anthropic's Claude Code, are expected to follow. Check the vendor for the current state before you rely on that list. Source

What a sandbox does not solve

A boundary limits damage. It does not make an agent right. An agent inside a sandbox can still write the wrong code in the allowed repository, send a wrong message through an allowed network route, or leak data through a channel you permitted. Containment answers what an agent may do. It does not check whether what it did was correct.

It also does not replace review. Approvals for consequential actions, tracing of tool calls, and evaluation of outputs still matter. Think of containment as the floor, not the whole building.

A one-week plan for your own agents

This is our recommendation, not a requirement from Microsoft.

First, list every agent or coding assistant in use and write down what it can reach today: repositories, secrets, production systems, network, the user's whole home folder. Most teams are surprised by the answer.

Second, pick one agent with real access and run it in a recording mode, either MXC's Learning or Permissive mode on Windows, or your own logging elsewhere.

Third, turn the log into an allow list. Repository read and write, specific tools, a short list of network destinations. Deny the rest.

Fourth, move that agent to enforcement and test the failure path. Ask it to do something outside the boundary and check that it explains the block instead of failing quietly.

Fifth, decide who owns the policy. A boundary that nobody reviews drifts back to "allow everything".

If your team wants help designing agent boundaries and operating agents in production, see our AgentOps services.