Conditional Access for agents

Why this matters

Conditional Access (CA) is Entra's real-time policy engine. In 2026 it's extended to agents — but with different targeting, different signals, and a critical set of boundaries you won't find in the user CA docs. Miss those, and you'll write a policy that never fires, or blocks the wrong thing.

Cross-ref: Lesson 6.1 covered policy-as-code (OPA / Cedar / capabilities). CA is Microsoft's proprietary policy engine at the token-issuance layer — it fires before the resource even sees the request. Treat CA and OPA as complementary, not competing.

Learning objectives

1. Understand CA's subject-and-audience model for agents.
2. Target CA policies at agent identities, blueprints, and custom security attributes.
3. Write CA rules for each of the three OAuth flows (autonomous / OBO / agent user).
4. Recognise the four scenarios where CA does not apply.
5. Combine CA with ID Protection risk signals for automated response.

1. How CA evaluates agent requests

CA evaluates at token issuance (and at Continuous Access Evaluation revocation events):

Agent → sidecar → Entra token endpoint
                        │
                        ▼
                 +----------------+
                 |     CA         |
                 | evaluate       |
                 | policies for   |
                 | this subject × |
                 | this audience  |
                 +----------------+
                        │
             allow / block / require MFA
                        │
                        ▼
             Token issued (or refused)
             Resource sees the token

Two axes CA always cares about:

• Subject — who is receiving the token? User (OBO), agent identity (autonomous), agent user account (agent-user flow).
• Audience — which resource is the token for? Graph, custom API, MCP server, SharePoint, etc.

Both are matched at every token acquisition and every refresh, and (for supported resources) at CAE revocation events for near-real-time enforcement.

2. Targeting agents in CA — the three levers

2.1 By agent identity (rare)

Use the "Agents" panel in CA. Pick one identity. Best for temporary quarantine of a specific misbehaving agent. Do not use at scale.

2.2 By blueprint

Pick the blueprint. All child agent identities — existing and future — inherit the policy. This is your primary lever for consistent policy across a class of agents.

Important: policies on a blueprint do not cover the linked agent user account — those must be targeted separately (they're users, so they're in the user CA world).

2.3 By custom security attributes (scale)

Define an attribute set with keys like AgentEnvironment, AgentDataSensitivity, AgentBusinessUnit, AgentRiskTier. Stamp them on every agent identity at creation.

Then write CA policies with filters for agents using attribute values:

Include: All agent identities where AgentEnvironment == "prod"
                             AND    AgentDataSensitivity == "high"

This is the model that survives 1000 agents.

Cross-ref: Lesson 9 (Governance) — attributes double as your governance query surface.

3. Policy patterns per OAuth flow

Different flows → different CA targets. Get this table right and you avoid 80% of the confusion.

Critical: policies targeting "all users" do not automatically include agent user accounts. You have to explicitly name them (or use an attribute filter that includes them).

3.1 Baseline autonomous policy (block by risk)

Goal: any autonomous agent flagged high-risk cannot get new tokens.

Assignments:
  Include: All agent identities
Conditions:
  Agent risk level: High
Access controls:
  Grant: Block access

Pair with ID Protection (Lesson 10.6). When ID Protection raises the agent to High, CA immediately stops issuing tokens.

3.2 Restrict autonomous to specific IPs

Autonomous agents run in known infra. Enforce named locations.

Assignments:
  Include: All agent identities where AgentEnvironment == "prod"
Conditions:
  Locations: Not in "MTN prod egress ranges"
Access controls:
  Grant: Block access

Named locations are IP ranges you pre-define. Since the sidecar sends from your own infra, you know exactly which egress IPs are legitimate.

3.3 Agent user account MFA exemption

Agent user accounts cannot satisfy MFA (they have no interactive factors). If your tenant baseline is "MFA for all users", agent user accounts will silently fail.

Assignments:
  Include: All users
  Exclude: <group containing all agent user accounts>
Access controls:
  Grant: Require MFA

Or: build a dedicated CA policy for agent user accounts with device-based / risk-based controls instead of MFA.

3.4 Require compliant device for privileged agent user account

For agent user accounts running on Windows 365 Cloud PCs (aka "Cloud PCs for Agents"), you can require compliant device:

Assignments:
  Include: <the specific agent user account>
Conditions:
  Agent execution environments: Windows 365 Cloud PC for Agents
Access controls:
  Grant: Require compliant device

This is one of the few compliance signals that make sense for agent principals.

4. Test in report-only mode — always

CA policies that block agents feel correct in staging and disaster in prod. Always:

1. Deploy the policy in report-only mode.
2. Let it observe token acquisition patterns for at least 72 hours.
3. Query the sign-in logs for applied / notApplied / failure.
4. Only after you're sure the policy would have caught the right things (and nothing else), flip it to On.

Same discipline you'd use for a user CA rollout; the impact of getting it wrong for agents is higher because agents don't tell you they're broken — they just stop working silently at 3 am.

5. Boundaries — where CA does NOT apply

This is the section that catches everyone. Learn it.

5.1 Blueprint-to-Graph token acquisition

When a blueprint principal acquires a Graph token to create an agent identity or agent user account, CA doesn't fire. Rationale: blueprints have very limited functionality and only exist to spawn identities. The agent tasks themselves are always performed by the agent identity, which is CA-covered.

5.2 Intermediate FIC token exchange

Blueprint and agent identity exchanges at the internal AAD Token Exchange Endpoint: Public (Resource ID fb60f99c-7a34-4190-8149-302f77469936) don't hit CA. Tokens for this resource can't call Graph directly — they're internal to the impersonation chain — so the "real" CA evaluation happens at the next step when a Graph or custom-API token is issued.

5.3 Resources not protected by Entra

CA only protects Entra-issued tokens. If your agent uses:

• A static API key (Slack webhook, third-party CRM key)
• A pre-shared bearer that isn't issued by Entra
• An mTLS cert chain outside Entra's CA

then Entra's CA is bypassed entirely. Use vendor-neutral policy (Module 6 OPA + capability tokens) or a secret broker (Module 5) for those.

5.4 "All users" filter and agent user accounts

CA policies with Include: All users do not automatically include agent user accounts. You have to name them explicitly or use an attribute filter. This is a common miss — you enable "MFA all users" and think you're safe, but agent user accounts sail through.

5.5 Group-membership scoping for agent user accounts

You cannot scope a CA policy to agent user accounts by putting them in a group and targeting the group. Group-based CA scoping doesn't work for agent user accounts. Use explicit selection or attribute filters.

5.6 Policy on agent identity does not cover its user account

If you target the agent identity (or its blueprint), you only cover the autonomous / OBO tokens. The agent user account flow issues its token to the user subject, which is a separate object requiring its own CA targeting.

6. CA + custom security attributes — the scale pattern

At scale you cannot manually pick 800 agent identities in a CA policy. Attributes are the answer.

6.1 Design your attribute set

Attribute set: AgentGovernance
  AgentEnvironment  : dev | staging | prod
  AgentBusinessUnit : cbu | ebu | wholesale | fintech | corp
  AgentDataSensitivity : low | medium | high | pii | financial
  AgentRiskTier     : t1 | t2 | t3 | t4    (t4 = highest privilege)
  AgentPurposeArea  : crm | billing | onbiller | ivr | itsm | ...

Populate at agent-identity creation time — the Agent 365 CLI + Copilot Studio provisioning can be extended to require these attributes.

6.2 Policies that write themselves

Policy: block prod-high-sensitivity from non-prod IP
  Include: Agents where AgentEnvironment=prod AND AgentDataSensitivity in (high,pii,financial)
  Condition: Location NOT in "MTN prod egress"
  Grant: Block

Policy: require sponsor approval for financial-tier agents
  Include: Agents where AgentDataSensitivity=financial
  Grant: Terms of use (with sponsor consent) — required at first token per session

Policy: block on high risk
  Include: All agent identities
  Condition: Agent risk level = High
  Grant: Block

New agents inherit the policies automatically as soon as they're stamped with attributes. You never touch the policies again.

7. Common pitfalls

1. Writing a "all users MFA" policy and thinking agents are safe. They're separate objects; agent user accounts are excluded by default.
2. Targeting the blueprint, expecting to cover the agent user account. Doesn't. Target both.
3. Skipping report-only mode. Live-blocking an agent identity that a business flow depends on breaks that flow silently.
4. Not populating custom attributes at creation. Attribute-based policies without attributes = no coverage.
5. Assuming CA covers static-API-key traffic. It only covers Entra tokens. Everything else needs OPA / broker.
6. Missing that OBO risk attributes to the user, not the agent. You cannot fire a CA policy on the agent identity for an OBO scenario — it doesn't apply. Fire on the user.
7. CAE not enabled on your resources. CA policy change / risk elevation is not near-real-time without CAE support in the resource — check per-service support.
8. Using group membership to target agent user accounts. Not supported. Explicit selection or attributes.

8. Hands-on lab (2 h)

Prereqs: two blueprints (dev and prod), 3 agent identities each, sidecar wired up per Lesson 10.3.

1. Define a custom security attribute set AgentGovernance with keys above.
2. Stamp attributes on all 6 agent identities (Entra portal or Graph).
3. Create a report-only CA policy: Include agents where AgentEnvironment=prod, Location = not in "MTN prod egress", Grant = Block. From an "unauthorised" IP, run the sidecar autonomous flow — expect the sign-in log to show reportOnlySuccess (policy would have blocked). From the "authorised" IP, expect reportOnlyNotApplied or reportOnlyFailure.
4. Flip the policy to On. Run the same tests. Verify the token is issued in the correct case and blocked in the other.
5. Create a policy: Include All agent identities, Condition: Agent risk level = High, Grant = Block. From another lab, mark one identity as "Confirm compromise" in ID Protection — verify the next token acquisition is blocked (CAE takes ≤5 min for supported resources).
6. Create an agent user account and try to invoke a Mail.Send while a tenant "MFA all users" policy is active. Observe silent failure. Add an exclusion for the agent user account; retry.

9. Self-check

1. Which of the three flows uses CA policies targeting the user vs the agent identity?
2. Why does "All users MFA" not cover agent user accounts?
3. What are the four scenarios where CA does NOT apply to agent flows?
4. Which custom-security-attribute pattern would you use for "block non-prod agents from prod resources"?
5. What is the difference between blueprint targeting and agent identity targeting?
6. How does CAE interact with CA + ID Protection for agents?

10. References

• Conditional Access for agents
• Configure policies for autonomous agent access
• Assign custom security attributes
• Vendor-neutral Lesson 6.1 — Per-tool authz and policy as code.
• Vendor-neutral Lesson 6.2 — HITL approvals (CA "terms of use" grants pair well with HITL patterns).