Microsoft Execution Containers now give AI agents a locked room

AI agents can now work across files, networks and apps on their own. Microsoft says that leaves customers with two bad choices.

They can give agents unrestricted access and hope nothing goes wrong, or block them and lose the productivity. Microsoft calls neither option acceptable.

Its blog puts it plainly: an agent cannot be its own security authority. The boundary has to be defined by the developer or the organization, and enforced independently of the agent.

In real life Say a coding agent is asked to update a website. It needs to read and write the website's repository and use tools to build and test the change.

Microsoft's example goes a step further. The agent might also need to read the production server configuration, but it should not be able to modify it.

Without a boundary, an agent could decide that editing that configuration is the fastest way to finish. Microsoft says that can break the production site even if the choice looked reasonable from the agent's side.

MXC is a policy-driven execution layer for untrusted code or dynamically generated workloads. In agent setups, developers can use it to contain model-generated output, plugins, tools, an agent harness, or the entire agent.

Developers declare the resources a workload needs, such as files and network destinations. MXC then enforces the boundary using the appropriate container.

The policy stays outside the agent's control, so the agent or the code it generates cannot grant itself more access.

MXC also separates what a workload needs from the platform-specific details of how to contain it. Developers use one JSON configuration schema and a multi-language SDK, and MXC maps the controls to backends on Windows, macOS or Linux.

Microsoft says the same model works from a local device to the cloud. Windows 365 support for MXC is also generally available, so developers can run agents on Cloud PCs next to their existing work.

Different jobs need different levels of isolation, so MXC offers a range. A coding agent in a repository may want low latency, while an agent handling sensitive data or untrusted code may need more.

• Lightweight process containment: for model-generated code and tool execution. It uses AppContainer on Windows, Seatbelt on macOS and Bubblewrap on Linux.
• Session container: Windows only. It runs an agent in a separate, OS-isolated session with its own local agent identity and its own desktop, clipboard, UI and input boundaries.
• Linux through WSL: for Linux-first agent toolchains that depend on the Linux package ecosystem.
• Hardware-backed isolation: for higher-risk workloads. Microsoft marks this option as experimental.

Microsoft adds that each backend has different security properties. Workloads should be checked for fit with the backend they use.

A policy describes the boundary in a few parts. Microsoft lists the isolation environment, the command and settings used to start the workload, and the locations the workload can modify, only read, or never touch.

It also covers inbound and outbound network connections, including access through the host's loopback interface. And it covers whether the workload can interact with the desktop and related UI.

For the website example, Microsoft says a policy could give the coding agent read and write access to its repository and tools like Git. It would block personal locations such as the Documents folder, block inbound and outbound network connections, and block the interactive desktop.

Microsoft also says you can use your favorite coding agent to integrate the SDK and draft a first policy. Then you review, test and refine the controls.

A first policy often blocks something the agent legitimately needs. Microsoft built three modes to help with that.

• Enforcement: applies the policy with no activity report. Granted actions go ahead and anything outside the boundary is restricted.
• Learning: still enforces the boundary, but records every blocked action in a JSON activity report. That helps developers reproduce failures and see what the workload tried to reach.
• Permissive: records what the policy would have denied, but lets it continue. Microsoft says it is useful while writing a policy, and it does not bypass other operating system or organizational restrictions.

Why it matters: those first denials show where the boundary needs adjusting, so you can grant what is required without widening the agent's reach more than needed.

Microsoft says leading agents and frameworks support MXC today. The list includes GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio and Unsloth AI.

Others are listed as coming. They include Anthropic's Claude Code, Box, Egnyte, Heidi Health, Hermes Agent by Nous Research, Manus, Perplexity, Raycast and Simular.

NVIDIA has integrated OpenShell into MXC. Microsoft says it adds policy controls for access to files and inference services, advanced network controls, credential management and, for enterprises, OCSF auditing.

Microsoft points to GitHub Copilot, Codex and Replit as demanding developer workflows. A coding agent needs the repository, tools and commands for a task, but it should not automatically gain access to unrelated files or network destinations.

This is not a surprise launch. Microsoft first announced MXC at its Build 2026 conference in early June, SC World and Petri reported at the time.

Petri described it as a new security layer on Windows that controls what AI agents can access. SC World noted that partners including NVIDIA, Hermes, Manus and OpenAI had signaled support.

Both reports also said MXC would tie into enterprise tools such as Defender, Entra, Intune and Purview. This week's announcement is the general availability step for the containment layer itself.

It also follows a related Windows move. We covered WSL Containers reaching general availability on Windows 11 a little over a week ago.

Microsoft describes MXC as the first of three pieces: containment, identity and manageability. Only the first is the part now generally available.

Identity is next. Microsoft says Windows will soon let Microsoft Entra tell agent activity apart from user activity in Microsoft Agent 365.

That would let security teams judge an agent's behavior and risk separately from the person using the device. If an agent is compromised or breaks policy, controls could target the agent's access without blocking the employee.

Manageability is the third. Microsoft says Agent 365 controls will extend to local agents on a device, so IT teams can manage MXC containers, apply policies and monitor agent activity.

Intune policy for MXC process containers on Windows 11 is also described as coming soon. It would let administrators control how Windows handles container requests made by agents, and the resource limits those containers enforce.

Microsoft also says agents should behave well inside tighter limits. If a policy blocks a resource, the agent should explain that the task could not be completed, ask for the right permission, or pick a safe alternative. It should not fail silently.

• Everyday users: you will mostly meet MXC as a safeguard inside agent tools you already use, not as something you set up.
• Developers: you can declare an agent's files and network access once and run it on Windows, macOS or Linux.
• IT teams: the identity and Intune controls are still marked as coming soon, so plan around that.
• Agent builders: expect to design for boundaries that may be tighter than your defaults, and to explain blocked actions clearly.