Windows 365 for Agents Just Made the Cloud PC an Agent Runtime: What CTOs Should Lock Down Before Rolling It Out

Microsoft just handed AI agents a full Windows desktop. That's not a feature update - it's a new class of enterprise attack surface, and the governance clock is already running.

On May 28, 2026, Microsoft opened the public preview of Windows 365 for Agents in the United States - a purpose-built agentic cloud PC runtime that lets AI agents operate inside a managed Windows environment. As Help Net Security reported, this is a distinct product line from the human-facing Windows 365 Cloud PC, built specifically for non-human users. It's the third runtime in an enterprise agent architecture that many CTOs haven't finished drawing yet.

What Microsoft Actually Shipped

The core of this release is a new infrastructure model Microsoft calls "hosted on behalf of" - abbreviated HOBO. Under HOBO architecture, each agent gets its own single-instance Azure virtual machine. That VM runs inside Microsoft's Azure subscription, but it's governed by the customer's Microsoft Intune (Mobile Device Management) policies and secured through Microsoft Entra ID (the enterprise identity platform formerly known as Azure Active Directory).

Your IT team configures and audits the machine; Microsoft handles the hosting. The Microsoft Learn documentation on Windows 365 for Agents walks through the technical model, including which agent types are supported in preview.

Licensing requires three things: the new Agent 365 license at $15 per user per month, an existing Intune subscription, and an active Azure subscription. This isn't a standalone purchase - it assumes you're already running Microsoft's enterprise management stack.

What the agent gets is a full Windows desktop - not an API endpoint, not a sandboxed shell. A taskbar, browser, file system, and the ability to click through application interfaces. That's the point. And it's also the risk.

The Three Runtimes Are Now Visible

If you've followed the Rework coverage of Microsoft's agent stack this week, you've seen two of the three runtimes. Microsoft Agent 365 established the control plane - a governance layer for registering AI agents as identifiable assets. Anthropic's self-hosted sandboxes represent the perimeter model - code-first, API-oriented agent execution inside your own firewall.

Windows 365 for Agents is the third leg. Call it the Three Runtimes Lens - a framework for mapping where an AI agent lives, what it can reach, and which controls apply:

The Three Runtimes Lens matters because most enterprise agent strategies collapse into a single question ("should we use AI agents?") when the real question is "which runtime fits this workflow, and what guardrails belong on each?"

Each runtime raises the security and governance ceiling one level. A control-plane agent calling an API is constrained by API scope. An API-first sandbox running code is constrained by the network perimeter. A UI-driven cloud PC agent can do almost anything a human employee with that Windows session could do. That's a materially different risk profile.

Where the UI-Driven Runtime Earns Its Keep

The case for Windows 365 for Agents is strongest wherever a human employee currently clicks through a screen to do work that a well-designed agent could handle more consistently. A few concrete categories:

Legacy ERP systems. SAP GUI and Oracle Forms were built for humans, not APIs. Many enterprises have SAP ECC installations where the REST API surface is thin or nonexistent. An agent with a Windows session navigates those screens and pulls outputs without a multi-year API modernization project.

Citrix and RDP-hosted applications. A significant share of enterprise software in regulated industries runs inside Citrix or Remote Desktop Protocol sessions. Automating those has required expensive Citrix-specific tooling. An agentic cloud PC changes that calculus.

AS/400 and terminal emulator workflows. IBM AS/400 systems and 5250 terminal emulators still run core business logic at thousands of companies. Agents that can operate a terminal emulator automate procurement, inventory, and production workflows that would otherwise require custom middleware.

Third-party SaaS without APIs. Some SaaS tools don't offer API access at the tier most customers buy. A UI-driven agent handles those without requiring a tier upgrade or a vendor negotiation.

The Windows 365 blog framed this direction as early as January 2026, describing the Cloud PC's next chapter as extending the platform to non-human users. The May 28 launch made that practical.

Where It Adds Risk You Didn't Have Before

Key Facts

• Windows 365 for Agents entered public preview on May 28, 2026, priced at $15/user/month for the Agent 365 license (source: Help Net Security)
• HOBO architecture places VMs in Microsoft's Azure subscription, managed via customer's Intune - the agent's Windows session has the same OS-level access as a human Cloud PC user (source: Microsoft Learn)
• Gartner projected that 40% of enterprise applications will include embedded AI agents by 2026, increasing the attack surface of UI-driven automation significantly (source: Gartner, 2025)

A full Windows desktop is a much larger blast radius than an API call. That's the tradeoff CTOs need to name explicitly before rolling this out.

Broader surface than any API scope. An agent that can launch any application in its Windows session can reach anything that user identity has permissions to touch. If those Entra ID credentials are over-provisioned - a common state in mature enterprises - the agent inherits that over-provisioning.

Auditability is harder than API logs. API-first agents produce discrete, structured audit logs. A UI-driven agent navigating a screen produces session recordings only if you've configured them. Reconstructing a decision sequence from screen captures is more work than parsing an API log. You'll need explicit session recording policies in Intune before trusting this in a production workflow.

Intune configuration drift. The HOBO model means Intune policies are the primary guardrail. If those policies drift - stale baselines, unreviewed exceptions, misconfigured conditional access - the agent's Windows session reflects that drift. A Windows session that inherits your Intune state also inherits your Intune debt.

License sprawl. Agent 365 at $15/user/month stacks on top of Intune and Azure. Without spend governance upfront, agent licenses become a large opaque line item with unclear value attribution.

Each of these risks is manageable. But they require deliberate policy decisions before the first agent ships, not after. The right starting framework is the agentic AI governance model - because the governance gap doesn't disappear just because you've added a new runtime.

The CTO Action List for the Next 60 Days

Rolling out Windows 365 for Agents without a boundary policy creates a new class of unmanaged asset in your environment. Here's what to do before the preview becomes production:

1. Audit UI-bound workflows first. Map every workflow where a human clicks through screens because there's no API alternative. That's your candidate list and your risk register. Each workflow moving to an agentic cloud PC needs its own risk tier.

2. Pilot ONE agent with read-only scope. Don't start write-capable. Pick a workflow where the agent reads data and reports it without changing state. That gives you session recording data, Intune policy validation, and an incident-response rehearsal.

3. Write the boundary policy before you scale. Define which Intune policies apply to agent Cloud PCs, which application categories are off-limits, which data classifications the agent can access, and what triggers automatic session termination. Make it a named document your security team signs off on.

4. Set spend caps by workflow. Agent 365 at $15/user/month compounds quickly. Assign each runtime a budget tied to the workflow it automates, with a named owner approving increases.

5. Define a deprovision-on-misuse rule. What does the agent have to do - or fail to do - to trigger session suspension? Define it in advance, automate it via Intune compliance policies, and don't debate it after an incident.

6. Decide who owns the Cloud-PC-as-runtime taxonomy. Is an agent Cloud PC a security asset, an IT asset, or an engineering asset? Leave that undefined and you'll have three teams pointing at each other when something goes wrong.

FAQ

Q: Is Windows 365 for Agents generally available?

No. As of May 28, 2026, it's in public preview in the United States. GA timing hasn't been announced. Treat the current state as a pilot-only environment - use it to test governance models, not run production workloads.

Q: Does Windows 365 for Agents replace Microsoft Agent 365?

No. They're different layers. Agent 365 is the control plane - it governs identity, permissions, and audit trails for all agents in your tenant. Windows 365 for Agents is a runtime - it gives an agent a place to operate. You need both. A runtime without governance is an unmanaged agent session.

Q: How does it compare to Anthropic's self-hosted sandboxes?

Different use cases. Anthropic's self-hosted sandboxes and MCP tunnels are optimized for code-tool agents calling APIs and processing data inside your own firewall. Windows 365 for Agents handles UI-driven workflows where the target system has no API. If the agent needs to call an API, use a sandboxed runtime. If it needs to click through a screen, use Windows 365 for Agents.

Learn More

• Microsoft Agent 365 Is Live: Why Every CTO Now Needs an AI Agent Control Plane
• Anthropic Just Moved AI Agents Inside Your Firewall: What Self-Hosted Sandboxes and MCP Tunnels Mean for CTOs
• 86% of CEOs Are Increasing AI Budgets, But Only 1 in 5 Has the Governance to Back It Up
• The ACE Framework: A Periodic Table for Business AI

The public preview window is your planning window. Every governance decision deferred now becomes a retrofit after the first incident. Start with the boundary policy, pick one read-only pilot, and let the Three Runtimes Lens guide where Windows 365 for Agents belongs - and where it doesn't.