Microsoft Execution Containers: contain local agents

Key insights

• MXC uses a JSON manifest to describe a workload, its isolation level, and its containment rules.
• The same policy model is translated into platform-specific containment mechanisms.
• Policies can restrict file access and network traffic; UI controls can also limit clipboard and simulated input.
• A learning mode can log allowed activity or denials to help refine rules before enforcing them.
• The demonstrated test profiles progressively allow file reading, writing, and outbound network access.

Microsoft Execution Containers (MXC) provide policy-driven containment for agents and other workloads running on a local machine, limiting what they can access. Developers building agents and IT teams evaluating local agent risks are the primary audiences. John Savill's [MVP] demonstrates MXC concepts and policy tests in a YouTube video.

What's new

MXC offers a common policy layer over operating-system containment features. Instead of implementing every low-level control separately for each platform, a developer describes a workload and its permitted access in a manifest, then MXC maps that policy to the platform’s available mechanisms.

The goal is to limit an agent’s authority independently of what the agent tries to do. The transcript describes policies for files, network access, and interaction with the user interface. For example, a policy can deny network traffic, allow a workload to read a file but not modify it, or permit access to a specific outbound port.

That distinction matters because a local agent may run under the logged-in user’s identity and access resources available to that user. Process separation alone does not necessarily keep it from using the same underlying operating-system kernel. MXC’s containment policy provides another layer of control around the workload.

Who it is for and what you need

MXC is aimed at developers who build coding agents or other software that runs generated code or interacts with a local computer. The transcript also describes a possible governance use: identifying agents on desktops and applying containment to them. It does not provide a specific administrator deployment procedure.

The demonstration uses an MXC SDK and local tooling on Windows, along with JSON configuration files and a PowerShell test harness. The harness tries to read and write a file, list processes, and download from a website. The material does not state licensing requirements, minimum operating-system versions, regional availability, or a rollout stage.

MXC is described as cross-platform, but supported containment levels differ by operating system. The transcript says process containment is supported across Windows, Linux, and macOS; Windows has the broadest set of levels discussed. It names AppContainer on Windows, Seatbelt on macOS, and Bubblewrap on Linux as platform-specific mechanisms used for process-level containment.

How it works

The manifest describes three main things: the workload to run, the isolation level, and the rules that constrain it. MXC translates the platform-independent policy into operating-system primitives when the workload runs. The policy can also describe UI restrictions, such as preventing clipboard access or simulated mouse and keyboard input.

1. Define the command or workload to execute in the MXC manifest.
2. Choose a containment level and specify permitted resources, such as readable paths or network access.
3. Validate the configuration with the local MXC tooling before running the workload.
4. Run the workload through MXC and check which test actions succeed or fail under the policy.

In the demonstration, a restrictive profile denies access to the test file and network while still allowing process listing. A read-only profile lets the harness read the file but not write to it. Another profile adds write access, and separate profiles test outbound access on port 443 and a combination of file and network permissions.

These examples show why policies should be specific: adding a permitted path or network rule changes what the process can do without granting every capability. The transcript also describes a learning option that captures denials or logs activity. Developers can use that information to adjust a policy before enforcing it, reducing the chance that a restrictive rule breaks the workload.

Limitations and open questions

MXC does not remove the need to decide what an agent should be allowed to access. The transcript’s test is a manually prepared Windows example, not a complete enterprise rollout or a comparison of performance across containment types. It also does not provide a full installation guide or detailed policy reference.

Isolation is not identical across platforms. A process container still relies on platform-specific operating-system mechanisms, while a virtual machine uses a separate kernel and offers a different isolation boundary. The transcript presents process, session, container, virtual machine, and remote-device approaches as a spectrum, but does not establish that every level is available through MXC on every operating system.

The video mentions agent activity metadata in Windows 11 at the end, but that topic is separate from MXC and is not explained in enough detail here. Licensing, supported versions, formal availability, and how administrators would centrally deploy or manage policies are also not stated in the supplied material.

Sources

• Microsoft MXC repository
• MXC whiteboard diagram
• John Savill's [MVP] MXC demonstration

Frequently asked questions

What does Microsoft Execution Containers do?

MXC provides policy-driven containment for agents and applications. Its manifest describes a workload, an isolation level, and rules such as permitted file paths and network access.

Does MXC support Windows, Linux, and macOS?

The material describes MXC as cross-platform and says process containment is supported across Windows, Linux, and macOS. It also says the available isolation levels vary by operating system.

How can I test an MXC policy?

The demonstrated workflow validates the configuration syntax with local MXC tooling, then runs a test workload and checks whether file and network operations succeed or fail. The supplied material does not give a complete installation guide.

What licenses or Windows versions does MXC require?

The supplied material does not state licensing requirements or minimum Windows versions.