Microsoft Entra Agent ID: Conditional Access Limits for AI Agents and VDI Migration Advice

Some of the interview is vendor pitch and some is useful advice. The useful part holds up, but Microsoft's own documentation shows the agent-identity idea comes with limits that admins need to know before relying on it.

Who Manchester is and where he works now​

Nerdio announced Manchester as chief product and technology officer on January 7, 2026. The company says he leads product management, engineering, architecture, technology operations and product support as one group. Nerdio sells management tools built on Microsoft's end-user computing stack, mainly Azure Virtual Desktop (AVD), Windows 365 and Microsoft 365. Nerdio also says he worked closely with the company from Microsoft's side since its founding.

That matters when reading the interview. Manchester helped build the cloud desktop services he now recommends, and his company profits when organizations move to them. None of that makes him wrong, but his figures and forecasts below are his claims, not independent industry data.

The 60-million-seat deadlock​

Manchester estimates that about 60 million virtual desktop seats still run on legacy, mostly on-premises infrastructure. StorageReview says many of these are older Citrix or Omnissa Horizon deployments, with years of custom configuration and undocumented admin changes piled up. The interview gives no method for the 60 million figure, so treat it as his estimate.

His diagnosis of why these estates don't move is more useful than the number. The obstacle is not mainly fear of the cloud. It is that nobody fully understands the current environment. In many shops the current director or principal architect is the third or fourth person to inherit the system. The original design from five years ago no longer matches how business units actually use it.

Replacing a stack you don't understand risks breaking something the business depends on. So at renewal time, many organizations sign the maintenance contract again because it feels safer.

In short: the deadlock comes from not knowing what the environment does, not from technology the business is attached to. Renewing preserves that uncertainty for another contract term.

Map the estate first, then migrate in stages​

Manchester's prescription is to measure before moving. He points to Nerdio's own discovery tool, Nerdio Compass. According to StorageReview, at the time of the interview Compass was free during a public preview and needed no agents installed. It reads Citrix, AVD or Intune environments and reports:

• Environment structure
• Workload profiles
• Policy configuration
• Cost

StorageReview says Omnissa Horizon support was on the roadmap, not shipping. Horizon shops should not assume Compass covers them yet. The preview pricing and scope were described as of the interview and may change.

With that inventory, workloads can be sorted into three Microsoft destinations:

The table's fit guidance is general industry practice, not something from the interview. Manchester's point is the contrast: a blind migration gives every legacy user a static 1:1 desktop, whether or not that model suits their work.

The staged method described in the interview works as a checklist:

1. Inventory and profile the existing estate before picking a target.
2. Classify workloads into pooled, personal or Cloud PC destinations.
3. Pilot cohorts in parallel with production instead of switching everything at once.
4. Migrate department by department.
5. Validate fully burdened cost models using real workload data, not list prices.
6. Decommission legacy hardware only after operational parity is proven.

None of these steps needs Nerdio specifically. Any assessment tool, or a careful manual audit, can produce the same data. The method is sound either way.

In short: find out what users actually run, match each group to the right AVD or Windows 365 model, and keep the old platform running until the new one has proven itself.

"Customer Zero": Nerdio runs on Nerdio​

Manchester says one early priority as CPTO was running Nerdio's own IT on its own product. In the interview he describes several hundred remote employees spread around the world. Internal onboarding runs through Nerdio Manager, including:

• Creating Microsoft Entra ID objects
• Assigning Conditional Access policies
• Delivering localized Cloud PCs or hybrid AVD session hosts

The idea is that engineers who hit their own product's friction and edge cases will fix them sooner. That is a reasonable practice, but these operational details come only from the interview. They are not proof of product quality or customer results.

Three stages of AI agent autonomy​

The conversation then moved to agentic AI. Fenton described lab testing of Tassient's Aipex AI-assisted management platform, where plain-English prompts were used to diagnose driver faults, read crash dumps, fix kernel panics and stand up tiered infrastructure services. That raised the obvious question: who is accountable when an agent misconfigures a production subnet or leaks corporate data?

Manchester proposed three stages of maturity. This is his own framework, not a Microsoft standard:

1. Human in the loop: the agent analyzes telemetry and recommends fixes, but cannot make admin changes without explicit human approval.
2. Human on the loop: the agent is accurate enough to carry out bounded tasks on its own, while admins watch dashboards and live execution logs.
3. Fully autonomous execution: the agent fixes issues, manages capacity and applies security baselines on its own within strict policy limits, escalating only exceptions outside those limits.

The practical lesson is to decide which stage each agent has earned and give it permissions to match, instead of granting broad rights by default.

Treating agents as Entra identities: what Microsoft actually supports​

Manchester's central recommendation is to treat AI agents like any standard user, under the policies already in place. In the interview's version, each agent becomes its own object in Microsoft Entra. Admins then apply the controls that already govern staff: role-based access control (RBAC), Intune device compliance and Microsoft Purview data loss prevention (DLP).

Microsoft has built much of this. Its product page for Microsoft Entra Agent ID says it provides identity and access management for agents, leveraging familiar capabilities like Conditional Access, identity governance, identity protection, and network controls. Microsoft's documentation describes an agent identity as a special service principal with no credentials of its own. Each one is created from a reusable "agent identity blueprint" and can have a human sponsor who is accountable for it. Some agents can also get a separate agent user account for systems that require a full user account.

The Conditional Access documentation describes the feature as a preview that brings Conditional Access evaluation and enforcement to AI agents. Microsoft's admin guidance says these policies can block all agent identities, allow only specific agents, or block risky agents based on ID Protection signals.

The gaps matter more than the marketing line:

• Enforcement happens at token request. Conditional Access applies when an agent identity requests a token for any resource or when an agent user requests a token for any resource. Access that doesn't go through Entra, such as a hard-coded API key to an outside service, is not covered.
• Policies built for people won't automatically cover agents. Microsoft says Conditional Access does not apply when the policy is scoped to users or workload identities, not to agents, or when security defaults are enabled. Existing policies need to be checked.
• Agent identities and agent user accounts are separate objects with different IDs, so each needs its own policy coverage.
• Some user controls don't apply to agents. A Microsoft Tech Community post on the feature says agents cannot do MFA, use biometrics, run on compliant devices or answer session prompts, because these are human-driven processes. That undercuts the idea that Intune device compliance carries over to an agent unchanged.
• Blueprint actions are exempt. Enforcement does not apply when an agent identity blueprint acquires a token to create agent identities or agent's user accounts.

The interview's DLP example, where an agent's outbound transfer is blocked just as it would be for a person, depends on how policy is configured. It works only if a Purview policy actually covers the data path the agent uses. It is not a guarantee for every agent or every route out of the network.

In short: Manchester is right that agents should be named, sponsored identities with limited permissions. On Microsoft's stack that means Entra Agent ID plus Conditional Access policies scoped specifically to agents, tested in report-only mode first. Do not assume human-focused controls automatically cover agents.

"Tokenomic shock" and AI tool sprawl​

The last topic was cost. Manchester calls it "tokenomic shock": enterprises paying for OpenAI, Anthropic and Microsoft Copilot at the same time, with multi-agent usage that nobody meters well, producing spending that's hard to predict. The interview compares it to the early days of cloud, when unexpected egress fees surprised finance teams at quarter end.

His argument is operational. IT can't run three admin consoles, three token-allocation schemes and three incompatible security models without adding staff. He expects demand for central management layers that sit above multiple models and apply one set of compliance and budget rules across all of them.

This is a forecast. The interview offers no spending data and names no product that already does this across the industry. The practical steps for now are general advice: inventory AI subscriptions the same way you would a VDI estate, give AI spend an owner, and require identity-based access where vendors support it.

The takeaway for Windows and EUC admins​

The VDI half and the agent half of the interview make the same point: you can't govern what you haven't inventoried. For a legacy Citrix or Horizon estate, that means profiling workloads before choosing between AVD pools, personal desktops and Windows 365. For AI agents, it means named identities with sponsors, bounded permissions and Conditional Access policies written for agents, plus a clear view of which access paths those controls don't reach.

Manchester is credible on both topics, and he also sells tools for both. His framework is a good starting point, but check it against Microsoft's documentation before building on it.