AI agents are now running in enterprise environments. They browse the web, read and write files, call APIs, execute code, and interact with line-of-business applications. The security question that most organisations have not answered yet is: where exactly are these agents running, and what can they touch?
Microsoft's answer is Windows 365 for Agents — a dedicated, isolated Cloud PC execution environment designed specifically for AI agent workloads. This post covers what it is, how the security model works, how it is provisioned and managed from Intune, and what you need to think about before deploying it.
The problem Windows 365 for Agents solves
Running an AI agent on a user's existing workstation creates three unsolvable problems:
- Blast radius. If the agent is compromised or behaves unexpectedly, it has access to everything the user has access to — their files, their browser sessions, their email client, their VPN tunnel.
- Auditability. You cannot independently audit what the agent did versus what the user did. The logs are interleaved.
- Consistency. Agent behaviour varies depending on what software is installed, what the user has open, what the screen resolution is, and what other processes are competing for resources.
Windows 365 for Agents gives each agent its own isolated, Intune-managed, Entra ID-joined Cloud PC. The agent runs in this environment and cannot reach the user's primary workstation, other Cloud PCs, or any network resource not explicitly permitted by policy.
Architecture: how it fits together
Key security properties
| Property | How it works |
|---|---|
| No user credentials in agent sessions | Agents authenticate using Entra ID managed identities or workload identities. No password, no MFA prompt, no user token stored in the session. |
| Session isolation | Each agent session runs in its own Cloud PC. Cross-session data access is not possible — the VMs do not share memory, storage, or network namespaces. |
| Ephemeral option | Cloud PCs can be configured to reset to a known-good snapshot after each agent task. No persistent state means no data leakage between task runs. |
| Full Intune management | Compliance policies, app control, Defender for Endpoint, and Conditional Access apply identically to agent Cloud PCs as to user Cloud PCs. |
| Audit logging | All agent actions on the Cloud PC are logged in Entra ID audit logs and Defender for Endpoint — attributable to the workload identity, not mixed with user activity. |
Provisioning an agent Cloud PC from Intune
- Select Type: Agent (where this option appears in your tenant — it requires the Windows 365 for Agents licence)
- Select the Azure network connection — or use Microsoft-hosted network if the agent only needs internet access
- Choose the image: Windows 11 Enterprise (agent-optimised) or a custom image with your required software pre-installed
- Set the compute profile — for most browser and API-based agent tasks, 2 vCPU / 4 GB RAM is sufficient; document processing or code execution tasks may need 4 vCPU / 8 GB
- Assign the policy to an Entra ID group containing the agent machine accounts
Configuring Conditional Access for agent identities
Agent Cloud PCs are Entra ID-joined and appear as devices in your tenant. Create a dedicated Conditional Access policy for agent workload identities:
- Users: Select the workload identities (managed identities) used by your agents
- Cloud apps: Scope to only the apps the agent needs to access (e.g. SharePoint Online, specific APIs)
- Conditions › Device platforms: Windows only
- Conditions › Filter for devices:
device.extensionAttribute1 -eq "AgentCloudPC"(set this attribute on provisioning) - Grant: Require compliant device (enforces your Intune compliance policy)
- Session: Sign-in frequency: Every 1 hour (limits the window if a session token is stolen)
Monitoring agent sessions
All agent Cloud PC activity is visible in the same places as user Cloud PCs, but with the workload identity as the actor:
# Get all Windows 365 Cloud PCs and filter for agent devices Connect-MgGraph -Scopes "CloudPC.Read.All" -NoWelcome $cloudPCs = Get-MgDeviceManagementVirtualEndpointCloudPC -All $agentPCs = $cloudPCs | Where-Object { $_.DisplayName -like "Agent-*" } $agentPCs | Select-Object DisplayName, Status, OSVersion, LastModifiedDateTime | Format-Table -AutoSize Write-Host "Total agent Cloud PCs: $($agentPCs.Count)" -ForegroundColor Cyan
What this means for Intune admins today
Windows 365 for Agents is not yet broadly available to all tenants — Microsoft is rolling it out in preview through mid-2026. Here is what to do now:
- Review your existing Windows 365 licence agreement — the agent SKU may be an add-on or separate purchase. Engage your Microsoft account team for pricing.
- Design your agent network boundary now — which APIs can an agent call? Which SharePoint sites can it read? Document this before provisioning. Changing network policy after agents are running is operationally painful.
- Define your agent identity model — managed identity per agent function (finance agent, HR agent, IT agent) rather than a single shared agent identity. Least privilege applies to AI just as much as to humans.
- Write your Intune compliance policy for agent Cloud PCs — same hardware requirements as standard Cloud PC, but you may want stricter app control (no browser access to unmanaged sites, for example) depending on what your agent does.
CSP and Group Policy
The Windows 365 for Agents environment is a standard Windows 11 Cloud PC from a policy perspective. All Intune device configuration policies, compliance policies, endpoint security policies, and Defender for Endpoint configurations apply identically. There are no agent-specific CSPs — the agent-specific behaviour is configured at the Windows 365 provisioning and network layer, not at the device policy layer.
References
- Windows 365 for Agents: A secured execution environment for AI agents — Windows IT Pro Blog
- Windows 365 Enterprise overview — Microsoft Learn
- Create a Windows 365 provisioning policy — Microsoft Learn
- Workload identities in Microsoft Entra — Microsoft Learn
- Conditional Access for workload identities — Microsoft Learn