Microsoft has made Execution Containers generally available, providing a policy-driven boundary for AI agents, generated code, plugins and tools. Announced on 7 October, MXC lets developers declare the files and network destinations a workload needs, while the platform enforces those permissions independently of the agent.
The release addresses a fundamental problem in agent security: a model cannot be responsible for limiting its own authority. An agent may choose a technically effective action that exceeds the user’s intent. The containment policy must therefore sit outside the model, harness and generated code.
Policies describe resources, not platform mechanics
Developers use a unified JSON configuration and multi-language SDK to specify required resources. MXC maps those requirements to the appropriate containment backend on Windows, macOS or Linux. This separates the workload’s needs from operating-system-specific sandbox details and can make a common agent design easier to deploy across environments.
The agent cannot grant itself additional access. A coding assistant might receive write permission for a repository and read permission for a production configuration, while a modification attempt against that configuration is blocked. The same principle applies if a plugin or generated tool decides to take the action.
Four containment levels fit different risks
Process containers provide lightweight isolation for responsive workloads and use AppContainer on Windows, Seatbelt on macOS or Bubblewrap on Linux. Windows session containers run an agent under a separate account and session, isolating its desktop, clipboard, interface and input from the interactive user.
WSL containers support Linux-first toolchains on Windows, while an experimental microVM backend provides hardware-backed isolation for higher-risk workloads. Each option has different performance and security properties. Teams need to select the boundary according to the data, tools and consequences involved, not simply choose the lightest or strongest default.
Containment can span device and cloud
Microsoft says the same policy model can apply from a local computer to cloud execution. Windows 365 support is generally available, allowing agents to run beside existing work on managed Cloud PCs. That gives organisations a path to apply consistent resource declarations while choosing where the workload executes.
Portability does not guarantee identical enforcement across backends. Security reviews should document which operating-system mechanism implements each control and what remains outside the boundary. Network identity, secrets, user consent and application-level authorisation still require separate design.
Identity and management come next
Windows will add Microsoft Entra capabilities that distinguish agent activity from user activity. Microsoft also plans to extend Agent 365 controls to local agents so IT teams can apply policy and monitor activity. A distinct identity is essential for investigations and for restricting an agent without interrupting the person who owns the device.
Useful logs should record the agent identity, requested action, policy decision, target resource and outcome. Administrators need to correlate those events with application and network records. Containment prevents some actions, while observability explains attempted and permitted behaviour.
General availability broadens the ecosystem
Microsoft has named support from agent and development products including OpenAI Codex, GitHub Copilot, OpenClaw, Replit, LM Studio, NVIDIA OpenShell and Unsloth AI, with other vendors planning integration. A shared containment layer could reduce duplicated sandbox engineering across agent providers.
Integrations still need careful validation. An agent may launch child processes, call external tools or hand work to another service. Teams should test whether every component remains inside the intended boundary and whether denied actions fail safely rather than triggering uncontrolled workarounds.
Security depends on the policy
MXC can enforce only what administrators define. An overly broad network rule or file grant can leave substantial risk, while an excessively narrow policy may make the agent unreliable and encourage users to bypass controls. Deployment should begin with representative tasks and progressively refine least-privilege permissions.
Organisations should also plan patching, image provenance, secret rotation and cleanup of persistent workspaces. Isolation reduces the blast radius of a mistake but does not replace secure software supply chains or human approval for consequential operations.
A foundation for governed desktop agents
Execution Containers give Windows and Microsoft’s wider agent stack an enforceable boundary between intention and action. General availability means developers can move beyond informal sandboxes and build against a supported policy model for local and cloud workloads.
The launch is most important as infrastructure, not a visible assistant feature. As agents gain access to desktops, code and business systems, reliable containment will determine whether organisations can adopt them without granting the full authority of every user they assist.
Security teams should include escape attempts, confused-deputy scenarios and policy changes in their tests. They should verify that an agent cannot use an allowed tool to reach a forbidden resource indirectly, and that updates do not silently broaden access. A reusable policy model is valuable only when its effective permissions can be inspected and continuously validated.
Evidence from those tests should become part of the deployment approval and ongoing control record.