Source: Microsoft Execution Containers: Policy-driven containment for AI agents, by Logan Iyer
An agent that runs under your login can touch everything you can. Microsoft Execution Containers (MXC) puts a boundary around it: you declare what it may read, write and reach, and the operating system enforces that from outside the agent.
Run a coding agent as yourself and it inherits your authority: every file, every network destination, every window you can reach. The usual choices are to give it full access and hope, or to block it and lose the help. The source calls both unacceptable.
A coding agent is asked to update a website. What it needs is narrow:
Without a boundary, the agent may decide that changing the server configuration is the fastest way to finish, and break the production site. From the agent’s side that can look reasonable. It still exceeds the authority the developer meant to grant.
“Do not touch the server config” in a prompt is a request to the thing you are trying to limit. The source puts it plainly: an agent cannot be its own security authority. The boundary has to be defined by the developer or organization and enforced independently of the agent.
With containment, an attempt to modify the config is designed to fail whatever the model, generated code, plugin or tool decides. The policy sits outside the workload, so the agent cannot grant itself more access.
The agent never holds the policy. Every file and network call goes through the OS, which checks it against rules written outside the agent.
Developers declare the resources a workload needs in a JSON configuration, through an SDK available in several languages. MXC maps those requests to a backend on Windows, macOS or Linux. A policy covers five areas.
| Area | What it controls |
|---|---|
| Containment | The isolation environment, such as a process or session container |
| Process | Command, arguments, working directory, environment and other start settings |
| File system | Where the workload may modify, where it may only read, where it has no access |
| Network | Inbound and outbound connections, including services on the host’s loopback interface |
| User interface | Whether it can access or interact with the desktop and related UI |
For the website task, the source’s example policy grants read and write on the repo and access to Git, denies personal locations such as Documents, and can block inbound and outbound network and the interactive desktop.
The shape, sketched below, is illustrative only. It is not the real MXC schema; use the repository’s schema and samples.
// illustrative only, not the MXC schema
{
"fileSystem": {
"modify": ["./website-repo"],
"read": ["/etc/server-config"],
"noAccess": ["~/Documents"]
},
"network": { "inbound": "block", "outbound": "block" },
"ui": "block"
}Different work needs different isolation. A coding agent in a repo may want low latency; untrusted code or sensitive data may need more.
| Backend | Availability | How it isolates |
|---|---|---|
| Process container | Windows 11, macOS, Linux | The platform’s process sandbox: AppContainer on Windows, Seatbelt on macOS, Bubblewrap on Linux. Lightweight, for responsive work. |
| Session container | Windows 11 only | A separate Windows account and session, with its own desktop, clipboard, UI and input. |
| WSL container (WSLc) | Windows 11 only | A Linux environment through WSL, for Linux-first toolchains. |
| MicroVM | Windows 11 and Linux, experimental | A hardware-backed virtualized boundary for higher-risk workloads. |
A least-privilege policy is hard to write before you know what the agent touches. MXC has three modes.
| Mode | Ungranted access | Activity report | Use |
|---|---|---|---|
| Enforcement | Blocked | No | Production policy |
| Learning | Blocked and recorded | Yes, JSON | Diagnose failures; check the policy grants only what is needed |
| Permissive | Allowed and recorded | Yes | Observe while authoring the policy |
The activity report, which lists the resources a workload tried to use, is only available for process containers on Windows. Permissive mode does not bypass other operating system or organizational restrictions.
Declare the files, tools and network the task needs.
Read the activity report where available.
Granted operations proceed; everything outside the boundary is restricted.
Organizations can add constraints on top of the developer’s policy through management policy. The source says Intune policy for MXC process containers on Windows 11 will soon be available; it is not shipped yet. The same agent can then run inside different company boundaries without the developer encoding each company’s security posture.
So an agent must expect tighter limits than its defaults. When a resource is blocked, it should explain that the task could not be done within its permissions, ask for user or admin action where supported, or pick a safe alternative. It should not fail silently.
| Belief | What holds |
|---|---|
| A prompt rule keeps the agent away from prod config | Only a boundary outside the agent does |
| Containment means blocking the agent | It means granting only what the task needs |
| You must know every resource up front | Learning and Permissive modes show you |
| A blocked call is the end of the story | The agent should say what it could not do |
Microsoft Execution Containers: Policy-driven containment for AI agents, Windows Developer Blog, 7 October 2026. The source for every fact on this page.
The MXC repository, microsoft/mxc on GitHub: SDK, configuration schema, documentation and samples.
A companion explainer is the Short on our YouTube channel.
Sources: policy areas, backends, modes and the website example are from the Windows Developer Blog post; the version number is from the Hacker News submission title. The JSON above is illustrative. Deemwar is not affiliated with Microsoft.