Conditional Access for Agent Identities in Microsoft Entra extends Zero Trust principles to non‑human identities by enforcing policy based access controls for agents, applications, and automated workloads. It ensures agent access is continuously evaluated based on identity, risk, and context before granting access to enterprise resources.
AI agents are rapidly becoming part of everyday enterprise operations summarizing incidents, analyzing logs, orchestrating workflows, or even acting as digital colleagues. As organizations adopt these intelligent automations, securing them becomes just as important as securing human identities.
Microsoft Entra introduces Agent Identities and extends Conditional Access to them but with very limited controls compared to traditional users and workload identities. This blog breaks down what Agent Identities are, how Conditional Access applies to them, and what are current limitations.
What Exactly Are Agent Identities?
Microsoft Entra now supports a new identity type designed specifically for AI systems:
- Agent Identity – like an app/service principal but specialized for AI
- Agent User – an identity that behaves more like a human user
- Agent Blueprint – a template used to create agent identities
This model exists because AI systems behave differently than humans or applications:
they can act autonomously, operate continuously, and make decisions without user input.
AI-driven automation must be governed and that’s where Conditional Access comes in.
Conditional Access for Agents, but with Important Limitations
Today, Conditional Access for agent identities is purposely minimal.
Microsoft clearly states:
Conditional Access applies only when:
- An agent identity requests a token
- An agent user requests a token
It does NOT apply when:
- A blueprint acquires a token to create identities
- An agent performs intermediate token exchange
What Controls Are Actually Available Today?
✔ Supported Today
|
Category |
Supported? |
Details |
|
Identity Targeting |
✔ Yes |
You can include/exclude agent identities & agent users |
|
Block Access |
✔ Yes |
This is the only Grant control currently available |
|
Agent Risk (Preview) |
✔ Yes |
Early stage risk evaluation |
|
Sign-in evaluation |
✔ Yes |
Token acquisition governed by CA |
❌NOT Supported Today
These CA controls do not apply to Agent Identities:
- MFA
- Authentication strength
- Device compliance
- Approved client apps
- App protection policies
- Session controls
- User sign-in frequency
- Terms of Use
- Location conditions (network/device-based)
- Client apps (legacy/modern access)
Why?
Because agents do not perform interactive authentication and do not use device signals or session context like humans. Their authentication is purely machine‑driven.
How Conditional Access Works for Agents
When an agent identity (or agent user) requests a token, Microsoft Entra:
- Identifies the requesting agent
- Checks CA policy assignments
- Evaluates any agent-risk conditions
- Allow/Blocks token issuance if conditions meet
That’s it.
No MFA prompt.
No device check.
No authentication strength evaluation.
This makes CA for agents fundamentally different from CA for humans.
Why Is Conditional Access So Limited for Agents?
Two major reasons:
- Agents cannot satisfy user-based controls
AI agents cannot:
- Perform MFA
- Use biometrics
- Run on compliant devices
- Follow session prompts
These are human-driven processes.
- Agents authenticate via secure credential flows
They use:
- Client credentials
- Federated identity credentials
- Token exchange flows
So CA is limited to identity-level allow/block and risk-based token decisions.
Practical Use Cases (Given Today’s Limitations)
Even with limited controls, CA for agents is still important.
- Stop compromised agents from continuing to operate
If Microsoft Entra detects high agent risk:
- CA can block token issuance
- This halts the agent’s ability to act immediately
- Enforce separation of duties for AI agents
Even though you cannot apply MFA or auth strength, you can:
- Separate agents into “allowed” vs “blocked” groups
- Apply different CA rules per department or system
- Prevent AI sprawl
Large enterprises may generate hundreds of AI agents.
CA gives central admin control:
- Only approved, vetted agents can operate
- Others are blocked at token-request time
Why Agent Blueprints Cannot Be Governed by CA
Blueprints are templates, not active identities.
Blueprint token flows are system-level operations, not access attempts.
Therefore:
❌ No CA evaluation
❌ No controls applied
❌ Not counted as agent activity
Only actual agent identities are governed by CA.
What the Future Might Include
Microsoft hints the capabilities will expand:
- Agent risk scoring
- Agent behaviour analytics
- More granularity in CA for agents
- Additional grant controls
- Policy scoping at task or capability level
But as of today, CA for agents remains intentionally constrained to allow safe onboarding of the new identity type without accidental disruption.
Final Summary
Conditional Access for Agent Identities is currently a lightweight enforcement mechanism designed to block unauthorized or risky agents, not a full policy suite like we have for human users.
✔ What it does:
- Controls whether an agent identity can acquire a token
- Allows blocking specific agents
- Implements early agent‑risk logic
- Applies Zero Trust principles at the identity perimeter
❌ What it does not do:
- Enforce MFA
- Enforce authentication strength
- Enforce device or location conditions
- Apply session controls
- Govern blueprints
As organizations adopt more autonomous agents, this foundational layer keeps AI identities visible and controllable and sets the stage for richer governance in the future.
Microsoft