Microsoft Entra Conditional Access for AI Agents: Licensing, Limits and Hybrid Zero Trust

None of this is a product launch or a new build. It's a design guide. Still, the principles line up with real Entra features, and those features come with licensing requirements, preview labels and limits that the blog doesn't spell out. This piece walks through the recommendations and then covers what Microsoft's own documentation says about how far each one can go today.

The core argument: identity replaced the network perimeter​

Tatar's starting point is that hybrid work is now simply how most companies operate. People sign in from home, apps run across several clouds, older systems still live in on-premises data centers, and AI agents now make access requests too. In that world, knowing which network a request came from tells you very little about whether it's safe.

The blog lays out seven design principles:

• Start with identity. Require MFA for everyone, make phishing-resistant methods the baseline, and judge each sign-in in context. Don't hand out standing access.
• Treat AI agents as identities. Each agent gets its own identity with only the permissions it needs, plus the same risk checks and revocation that apply to people.
• Tier apps by sensitivity. HR and finance systems need strong MFA and compliant devices. Low-risk internal tools can use lighter controls.
• Respond to risk in proportion. Ask for reauthentication or step-up checks first, and save outright blocks for truly high-risk conditions.
• Replace broad VPN access with per-app access, moving one app at a time.
• Put internet and SaaS traffic under the same policy model, with web filtering and threat intelligence on top.
• Run policy as an ongoing job. Review sign-in logs, impact reports and user behavior on a regular schedule.

Tatar also lists four mistakes to avoid: using the same settings for cloud and on-premises apps, treating device trust as a substitute for user and risk signals, giving agents broad or shared credentials, and turning on every rule at once with no pilot or rollback plan.

Section summary: The philosophy holds up and matches standard Zero Trust thinking. The details sit in the documentation, so the rest of this piece goes there.

Conditional Access is an if-then engine, and timing matters​

Microsoft's documentation describes Conditional Access as a set of if-then statements. If a policy's conditions are met, its controls apply. If the user satisfies those controls, access is granted; if not, access is denied. Conditions include user risk, sign-in risk, device platform, filters for devices, network location, and, in preview, agent risk.

For anyone designing policies, the most important detail is when evaluation happens. Microsoft's authentication strengths documentation says Conditional Access runs only after the initial authentication. So a policy that requires phishing-resistant MFA won't stop someone typing a password first. They just can't continue until they complete a method that meets the required strength.

That changes how you should read "make phishing-resistant MFA the baseline." In practice it's a requirement you apply per resource, not a switch that removes passwords from the sign-in screen.

Phishing-resistant MFA: what counts and what it costs​

Microsoft offers three built-in authentication strengths: Multifactor authentication, Passwordless MFA and Phishing-resistant MFA. The phishing-resistant strength accepts:

Points Windows admins should know:

• Licensing: Conditional Access requires Microsoft Entra ID P1.
• You can't combine them: "Require multifactor authentication" and "Require authentication strength" can't be used together in one policy.
• Windows Hello for Business behavior: If a user signs in with a password and the policy requires Windows Hello for Business, Entra won't prompt for Hello. The user has to restart the session, choose Sign-in options, and pick a qualifying method. Expect helpdesk calls about this.
• Register before you enforce: Microsoft's admin-MFA guidance warns that requiring phishing-resistant MFA before administrators have registered suitable methods can lock you out of your tenant. Temporary Access Pass can help admins bootstrap passkey registration.

Tatar's tiering advice maps neatly onto this. Apply the phishing-resistant strength to HR, finance and admin roles, and allow the broader MFA strength for low-risk apps.

On privileged access, Tatar recommends just-in-time elevation through Privileged Identity Management. Microsoft's documentation confirms that PIM can require MFA when a role is activated and can be paired with phishing-resistant policies for admin roles. Microsoft also notes that these Conditional Access role policies apply to built-in roles only, not to custom roles or roles scoped to administrative units. Large organizations that have delegated admin rights heavily should check where their gaps are.

Risk-based enforcement needs P2​

The "challenge rather than block" approach depends on Microsoft Entra ID Protection signals. Microsoft says policies that use sign-in risk detections require Microsoft Entra ID P2. P1 covers basic Conditional Access, but adaptive risk-based policies need the higher tier.

Microsoft's own template for elevated sign-in risk:

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Go to Entra ID > Conditional Access and select New policy.
3. Include All users and exclude your emergency access (break-glass) accounts.
4. Under target resources, include All resources.
5. Under Conditions > Sign-in risk, select High and Medium.
6. Under Grant, choose Require authentication strength with the built-in MFA strength.
7. Under Session, set Sign-in frequency to Every time.
8. Set the policy to Report-only, then switch it to On once you've confirmed the impact.

There's one catch. The policy blocks users from registering MFA during a risky session. A user who hasn't registered MFA and then hits a risky sign-in is blocked with error AADSTS53004, not prompted to register. Get everyone registered before you rely on step-up checks to keep risky sign-ins proportionate.

AI agents: the same principles, different mechanics​

This is where Microsoft's documentation adds the most to Tatar's guidance. "Apply the same risk evaluation and revocation you apply to people" is a good principle, but the controls available for agents today are much narrower.

Microsoft identifies three ways an agent can access resources, and each needs its own policy:

• On-behalf-of (delegated): The token represents the signed-in user, so the user's policies apply. A policy that targets an agent identity does not cover these requests.
• Application-only: The agent uses its own agent identity. Policies scoped to the agent identity apply.
• Agent user account: The agent has its own user account, with a mailbox, Teams presence and so on. A policy targeting the agent identity doesn't reach this account, and the reverse is also true.

Microsoft's documentation states that Conditional Access treats both agent identity objects as separate principal types. So a policy that targets agent identities can't target an agent's user account, and vice versa. It also says policies targeting all users don't include agent's user accounts. In other words, an "All users" MFA policy you wrote years ago does nothing for agent user accounts.

The controls themselves are limited. According to Microsoft's targeting guide, when a policy targets agent identities, the only condition available is Agent risk (Preview), and Block access is the only available option for agent identities, because there's no interactive remediation possible. You can't send an MFA prompt to a background process. Agent user accounts get more options, including device platform, filter for devices, network, and requiring a compliant device. Several of these are still in preview.

Microsoft also says the default is wide open: a tenant that enables agent workloads without at least one Conditional Access policy enforcing block-unless-approved has no enforcement boundary on autonomous AI access. Every token request from an agent identity or agent's user account is allowed by default. That matters more than any line about "agents as first-class actors." On detection versus enforcement, Microsoft notes that without a blocking policy, the logs say "compromised" while the resource still says "yes."

Other limits from the documentation:

• Licensing: Conditional Access for agents requires Microsoft 365 E7, or a Microsoft Agent 365 license plus at least Entra P1 or Microsoft 365 E3. Microsoft's agent management page says ID Protection for agents requires a Microsoft Entra ID P2 license during preview.
• API keys bypass everything: Conditional Access protects only resources secured by Entra ID. An agent that uses an API key skips token issuance entirely, so no policy applies.
• Cloud-hosted agents have no device: A device-compliance requirement on an agent running directly in the cloud blocks it with no way to fix it. Use the Agent execution environments condition (preview) so endpoint-based controls apply only to sessions that start on endpoints, such as Windows 365 Cloud PCs for Agents.
• Scaling with blueprints and attributes: Targeting a blueprint automatically covers all agent identities derived from it, including ones added in the future. Custom security attributes let you write allow lists for approved agents.

Section summary: "Treat agents as identities" is the right idea. Today, though, that usually means block-based policies driven by risk and approval status, separate policies for each token type, and a check of how each agent actually authenticates.

Retiring the VPN: one app at a time​

Tatar's advice to replace broad VPN access with per-app access matches Microsoft Entra Private Access, part of Global Secure Access. Microsoft documents two models. Quick Access is one enterprise app holding several app segments under a shared Conditional Access policy. Per-app access uses separate enterprise apps for more granular policies, at the cost of monitoring each one separately. Both can run side by side. Users need the Global Secure Access client.

Microsoft's operating guidance warns against overly broad segments such as 0.0.0.0/0, ::/0 or wildcard DNS suffixes, which can pull in unrelated traffic. Moving everything into Quick Access with loose definitions is just a VPN under a new name. A realistic plan:

1. Inventory your internal apps by sensitivity tier.
2. Start with Quick Access for broad coverage, using precise FQDNs and IP ranges.
3. Split high-value apps (finance, HR, admin tools) into per-app enterprise apps with stricter policies.
4. Keep the old VPN running for apps you haven't migrated, and keep a rollback path, as Tatar advises.

Internet and SaaS traffic: a separate product​

Extending policy to internet-bound traffic means Microsoft Entra Internet Access, Microsoft's identity-focused secure web gateway. Web content filtering policies are grouped into security profiles that link to Conditional Access. Microsoft notes that HTTPS filtering relies on TLS Server Name Indication unless you turn on TLS inspection for more precise categorization. Conditional Access on its own doesn't govern every web request. You need the gateway deployed and the client installed.

Operating policy: report-only mode and its limits​

The advice to pilot and stage changes is where Microsoft's tooling is strongest:

• Report-only mode evaluates most policies without enforcing them. Results show in the sign-in log under "Report-only: Success," "Failure," "User action required" or "Not applied."
• "User action required" doesn't mean the user would have succeeded. Report-only never prompts for MFA, so this result tells you a challenge would appear, not that the user would pass it.
• Exceptions: Policies in the User Actions scope can't be tested this way. Report-only policies that check device compliance can still prompt macOS, iOS and Android users to pick a certificate, so Microsoft suggests excluding those platforms.
• There's no true A/B testing. Microsoft states that Conditional Access doesn't split live traffic between two enforced versions of a policy. The closest equivalent is the Conditional Access Optimization Agent's phased rollout, which requires Security Copilot capacity.
• Workbooks: The Conditional Access Insights and Reporting workbook needs Entra ID P1 and a Log Analytics workspace receiving sign-in logs.
• Audit retention: Entra audit logs record policy creation, updates and deletions, and they're kept for 30 days by default. For a longer record, send them to Log Analytics, a storage account or Event Hubs.

For a quick look from PowerShell, Microsoft documents connecting with Connect-MgGraph -Scopes Policy.Read.ConditionalAccess, AuditLog.Read.All, Directory.Read.All and then pulling records with Get-MgAuditLogSignIn and Get-MgAuditLogDirectoryAudit. That's a simple way to build the automated reporting Tatar recommends.

Where the blog oversells​

The guidance is sound, but it comes from Microsoft's own product blog and ends with a pitch for Entra. Keep three things in mind:

• Licensing is never mentioned, even though risk-based policies need P2 and agent controls need Agent 365 or E7. Smaller organizations on Business Premium (which includes P1) can tier apps and use authentication strengths, but not every recommendation is open to them.
• "Micro-segmentation by default" depends on how you define your segments. Broad Quick Access definitions don't segment anything.
• The agent section leans on principle. In practice, many agent controls are still preview and block-only.

None of this makes the advice wrong. It means you should read it as a direction to head in, not a feature list you can switch on this afternoon.

The bottom line for Windows and Entra admins​

Tatar's framework comes down to policy as a design discipline, and the documentation agrees. If you're mapping out next quarter's identity work, here's the order:

1. Register phishing-resistant methods for admins first, then enforce authentication strengths on your top-tier apps.
2. Check whether your licenses actually cover the risk policies you're planning.
3. Write a block-unless-approved policy for agent identities before agents multiply, and handle agent user accounts separately.
4. Find every agent that authenticates with API keys, because Conditional Access can't see them.
5. Run every new policy in report-only mode, read the logs, then enforce.
6. Export audit logs past 30 days so your change history survives.

Will one Entra configuration fit every hybrid enterprise? No. But a team that tiers its apps, separates its token types and tests in report-only mode will end up with policies users can live with instead of ones they work around.