How Microsoft separates AI agents on Windows

Windows AI agent security in Microsoft’s design rests on three different execution boundaries: process isolation and session isolation run locally, while Windows 365 for Agents puts an agent in a separate cloud PC. Microsoft describes process isolation as a way to restrict file and network access; session isolation separates an agent from the user’s interactive environment.

The distinction matters because a separate identity, a restricted process and a separate desktop constrain different things. Microsoft introduced Microsoft Execution Containers (MXC), the policy-driven layer behind its local isolation approach, on June 2, 2026.

Two ways to isolate an agent locally

With process isolation, an agent’s workload runs inside a constrained process boundary. Microsoft says policies can restrict which files it can access and which network domains it can reach. The company cites coding agents as a suitable use, where generated code can run within limits set by the application or developer.

Session isolation separates an agent from the user’s interactive desktop, clipboard, interface, input devices and active sessions. Microsoft says an isolated session can use its own local identity or a cloud-provisioned identity backed by Microsoft Entra. Its initial release was described as supporting non-interactive sessions, which makes this boundary distinct from simply restricting a process’s file and network access.

In an interview, Microsoft CEO Satya Nadella described AI agents as insider risks. His broader call for human control of advanced AI is covered in our earlier article. MXC gives that security premise a concrete Windows shape: define what an agent may access, then enforce those boundaries at runtime.

MXC’s policies and the audit-mode warning

Microsoft’s MXC repository documents policies for filesystem access, network traffic and user-interface controls, including clipboard and GUI access. The selected backend affects which isolation behavior is available. The repository lists Windows 11 support for x64 and ARM64, with ProcessContainer as the default Windows backend; it marks the Windows Sandbox, MicroVM and Hyperlight backends as experimental.

One setting deserves special attention: audit mode turns off sandbox security for the workload being analyzed. It is a diagnostic mode, not a protected execution mode. A developer inspecting an agent’s behavior should not mistake an audit run for a contained one.

Microsoft also says Defender provides real-time protection against prompt injection and other emerging agent threats. Identity, runtime boundaries and threat monitoring are separate parts of the design: a distinct agent identity can assign activity to an account, while process and session isolation define what the workload can reach.

Local isolation or Windows 365 for Agents?

The right distinction is where the agent runs and which parts of the user’s environment need separation. Process isolation narrows file and network access; session isolation puts the agent in a separate local session; Windows 365 for Agents moves execution to an Intune-managed Cloud PC separate from the user’s machine.

Microsoft’s June 2, 2026 post called MXC an early preview and said local process and session isolation were planned to enter early preview shortly after Build 2026. In that same post, Microsoft described Windows 365 for Agents as generally available. Those are different deployment options with different status statements, not interchangeable labels for one sandbox.