Microsoft has made Execution Containers (MXC) generally available on Windows 11, giving developers and IT administrators a way to restrict which files, networks, and system resources AI agents can access. The technology creates operating system-enforced boundaries around agents that execute code, use development tools, or perform tasks on a user's behalf.
Announced Oct. 7, the release introduces several containment options, including isolated processes and separate Windows sessions. However, not every capability is ready for production use. MicroVM support remains experimental, while centralized management through Microsoft Intune and expanded agent identity controls are still being developed.
According to Microsoft's announcement, MXC applies resource policies independently of the agent itself. An AI agent cannot simply grant itself additional file or network access when its task requires permissions outside the approved boundary.
For security teams deploying AI agents, the immediate benefit is greater control over what agent-generated code and automated tools can reach. Organizations still need to select the appropriate isolation level, define access policies, and verify that those restrictions remain enforced.
How Microsoft Execution Containers isolate AI agents
MXC uses a unified JSON configuration schema and SDK to define what a workload can access. Developers can restrict file reads and writes, network connections, process execution, and interaction with the user's desktop.
For example, a coding agent could receive permission to modify files in a software repository while being blocked from changing production server configurations or accessing an employee's personal documents.
Microsoft identifies four containment backends with different security properties.
- Process containers: Available on Windows 11, macOS, and Linux. These provide lightweight process isolation using AppContainer on Windows, Seatbelt on macOS, and Bubblewrap on Linux.
- Session containers: Available on Windows 11. Agents run under a separate Windows account and session, isolating their desktop, clipboard, user interface, and input from the interactive user.
- WSL containers: Available on Windows 11. These provide Linux execution environments for agent tools and development workloads that rely on the Windows Subsystem for Linux.
- MicroVM containers: Experimental on Windows 11 and Linux. These use hardware-backed virtualization for workloads requiring stronger isolation.
The appropriate backend depends on the workload. A coding assistant may need responsive access to development tools, while an agent handling sensitive files may require stronger separation from the user's session.
Session isolation is particularly relevant to agents that interact with desktop applications. By separating an agent's desktop and input environment from the user's, Windows can limit opportunities for unintended interaction with applications running in the employee's session.
These controls extend the broader Windows 11 security model, which already uses operating system protections to restrict application privileges and access to sensitive resources.
Enforcement, Learning, and Permissive modes
MXC includes three operating modes that determine how configured access restrictions behave.
Enforcement mode blocks operations outside the approved policy. Authorized activity proceeds, while requests for resources beyond the defined boundary are denied.
Learning mode also blocks unauthorized operations but records them in a JSON activity report. Developers and administrators can use this information to identify missing permissions and adjust policies without disabling containment.
Permissive mode records activity that the MXC policy would deny but allows it to proceed, subject to other applicable operating system and organizational restrictions.
That distinction is important for security teams. Permissive mode helps developers understand an agent's resource requirements, but it does not enforce the configured MXC restrictions.
Organizations should use Enforcement mode for production workloads that require those restrictions and reserve Permissive mode for controlled policy development and testing.
Microsoft also supports organizational controls that can further restrict the permissions requested by agent developers.
However, centralized Intune policy management for MXC process containers is not yet generally available. Microsoft says this capability will arrive in a future release, allowing IT teams to govern container creation and resource access across managed Windows devices.
Agent identity is another developing component. Microsoft plans to integrate Entra identity capabilities with Microsoft Agent 365 so organizations can distinguish agent activity from employee activity and apply controls to individual agents.
These capabilities are separate from the containment technology now generally available.
Which AI agents support MXC, and what security teams should check
Microsoft lists GitHub Copilot, OpenAI Codex, OpenClaw, Replit, LM Studio, NVIDIA OpenShell, and Unsloth AI among the agents and frameworks already supporting MXC.
Additional integrations are planned for Anthropic Claude Code, Box, Egnyte, Manus, Perplexity, and several other products.
Integration support does not necessarily mean every agent feature or deployment configuration runs inside an MXC container. Organizations should confirm the containment options supported by their chosen agent and how its permissions are applied.
The distinction is relevant to enterprise agent deployments that can access sensitive resources. Recent concerns about Claude agents accessing live systems demonstrate the need to define operational permissions before allowing agents to interact with production environments.
Execution containment also has limits.
A container can prevent an agent from reading unauthorized files or reaching prohibited network destinations. It cannot determine whether the agent was manipulated into performing an unwanted action using resources it was legitimately permitted to access.
For example, a prompt-injection attack could persuade an agent to disclose information through an approved destination. If the transfer falls within the configured permissions, containment alone would not necessarily stop it.
Organizations deploying AI agents for work therefore need additional safeguards around tool authorization, sensitive data access, and human approval for high-risk actions.
Security teams evaluating MXC should prioritize four checks:
- Select the appropriate backend. Match process, session, or other supported isolation options to the sensitivity of the workload.
- Apply least-privilege policies. Grant access only to required files, tools, network destinations, and user-interface resources.
- Verify enforcement settings. Confirm that production workloads use Enforcement mode when policy restrictions must block unauthorized operations.
- Test agent behavior. Use Learning mode to identify missing permissions, investigate unexpected resource requests, and refine policies before deployment.
Teams should also confirm the supported Windows configuration and MXC backend requirements for their intended workloads. Microsoft documents backend availability by operating system, but individual deployment prerequisites may differ.
Microsoft Execution Containers provides a way to limit the resources available to AI agents without giving them unrestricted access to the user's environment. Its production value will depend on how organizations configure those boundaries and combine them with identity controls, monitoring, and approval requirements.
Also read: Organizations deploying autonomous tools can reduce exposure by limiting AI agent permissions and restricting access to sensitive systems.