Conditional Access for AI agents: secure Entra Agent ID sign-ins

To apply Conditional Access to AI agents, first identify how each agent gets its tokens, because the policy has to target the token's subject: the signed-in user for on-behalf-of access, the agent identity for autonomous app-only access, or the agent's user account when the agent acts as a user. Then create policies under Users, agents or workload identities > Agents that block every agent identity except approved ones, block high-risk agents using Microsoft Entra ID Protection, and start each policy in report-only mode.

Who this is for and what you will have at the end

This guide is for identity and security administrators whose tenants now contain agents registered through Microsoft Entra Agent ID, whether they're Copilot Studio agents or agents on third-party platforms such as Amazon Bedrock or n8n that are configured with Agent ID. These agents request tokens like any other client, and without a policy they get them whenever they hold valid credentials and permissions.

At the end you will have:

• A way to map each agent to the identity Conditional Access actually evaluates.
• A report-only policy that blocks all agent identities except those you approve, using either the object picker or custom security attributes.
• A policy that blocks high-risk agent identities, and equivalent policies for agent user accounts.
• A verification routine using sign-in log filters for agents, and a list of the boundaries where Conditional Access doesn't apply.

For the wider architecture of AI workloads that call corporate data, see the production LLMOps and enterprise RAG architecture.

How Conditional Access sees an agent

Every access token has one subject and one audience. Conditional Access evaluates both whenever Microsoft Entra ID issues or refreshes a token, and the subject depends on how the agent authenticates.

Three consequences follow, and most misconfigurations come from ignoring one of them:

• OBO access is governed by user policies. When an agent reads a mailbox on a user's behalf, the token represents the user. Selecting the agent identity in a policy doesn't cover those requests. Your existing user policies, such as MFA and device requirements, do.
• An agent can use more than one pattern. A policy that targets an agent identity doesn't apply to that agent's user account, and the reverse is also true. Create a separate policy for each token subject the agent uses.
• Blueprints act as classes. An agent identity blueprint defines the configuration for the agent identities created from it. A policy that targets a blueprint covers all agent identities created from it, including future ones. It covers agent identities only, not agents' user accounts.

Prerequisites

• Licensing: Microsoft 365 E7 (which includes Agent 365 and Microsoft Entra Suite), or a Microsoft Agent 365 license paired with at least Microsoft Entra ID P1 or Microsoft 365 E3. Agent risk-based policies need Agent 365 with Microsoft Entra ID P2 or Microsoft 365 E5.
• Role: at least Conditional Access Administrator to create policies. Viewing the Risky Agents report needs Security Administrator, Security Operator or Security Reader.
• At least one agent identity registered in the tenant.
• Target resources registered in Entra ID. Every resource the policy protects needs an enterprise application (service principal) in the tenant. That applies to Microsoft Graph, MCP servers, OpenAPI tools and custom tools. Register custom tools as applications and expose their permissions, otherwise there is nothing for Conditional Access to evaluate.
• Security defaults turned off. Conditional Access policies for agents don't apply while security defaults are enabled.

Step 1: Inventory agents and how they sign in

Before writing a block policy, find out which agents are signing in and with which identity type.

1. Sign in to the Microsoft Entra admin center as at least a Reports Reader.
2. Browse to Entra ID > Monitoring & health > Sign-in logs.
3. Add the Is Agent filter and set it to Yes, or the Agent type filter and choose Agent ID user, Agent Identity or Agent Identity Blueprint.
4. Check both the user sign-in tabs and the service principal tab. Because agents can sign in with delegated or app-only permissions, their sign-ins can appear in any of the sign-in log types.

The same data is available from the Microsoft Graph beta endpoint. This request returns service principal sign-ins made by agent identities:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and agent/agentType eq 'AgentIdentity'

In audit logs, agent activity appears under the underlying object type: blueprints as application events, agent identities as service principal events, and agents' user accounts as user events. The agentType property on initiatedBy, performedBy and targetResources tells you whether an event involved an agent; any value other than notAgentic indicates agent involvement.

Record, for each agent, its blueprint, whether it uses its own identity, a user account, or OBO, and which resources it calls. That list becomes your approval list.

Step 2: Block agent identities you haven't approved

The recommended baseline is a block policy that includes all agent identities and excludes the approved ones. Microsoft documents two ways to express "approved".

Option A: the enhanced object picker

1. Browse to Entra ID > Conditional Access > Policies and select New policy. Give it a name that follows your naming standard.
2. Under Assignments, select Users, agents or workload identities.
3. Under What does this policy apply to?, select Agents.
4. Under Include, select All agent identities.
5. Under Exclude, choose Select individual agent identities. Use the All, Agent blueprint principals and Agent identities tabs to pick the approved blueprints or individual agents, then choose Select.
6. Under Target resources > Include, select All resources (formerly 'All cloud apps').
7. Under Access controls > Grant, select Block, then Select.
8. Set Enable policy to Report-only and select Create.

Excluding a blueprint rather than individual agents keeps the policy stable as new instances are created from an approved blueprint.

Option B: custom security attributes

The object picker doesn't scale well past a handful of agents. Microsoft's recommended approach is to tag agents and resources with custom security attributes and target the attributes.

1. Create an attribute set, for example AgentAttributes, with an attribute AgentApprovalStatus that allows multiple values and only predefined values. Microsoft's example values are New, In_Review, HR_Approved, Finance_Approved and IT_Approved.
2. Optionally create a ResourceAttributes set with a Department attribute to tag the resources each class of agent may use.
3. Assign the attribute values to each approved agent or blueprint.
4. Create the policy as in Option A, but under Exclude choose Select agent identities based on attributes, set Configure to Yes, pick AgentApprovalStatus, set Operator to Contains and Value to the approval value, such as HR_Approved.
5. Target All resources, grant Block, and create the policy in Report-only.

Any new agent tagged with a matching value is covered automatically, and approval becomes an attribute change rather than a policy edit.

Note that agent identities support only the Block access control. There is no MFA or compliant-device grant for an agent signing in as itself, because no interactive remediation is possible.

Step 3: Block high-risk agent identities

Microsoft Entra ID Protection evaluates agents for risk. Detections include a sign-in spike, unfamiliar resource access, failed access attempts against unauthorized resources, directory reconnaissance, suspicious credential usage on blueprints, early-life malicious activity, threat intelligence matches, and admin-confirmed compromise. Agent risk is in preview.

1. Create a new policy and under Users, agents or workload identities > Agents, include All agent identities.
2. Under Target resources > Include, select All resources (formerly 'All cloud apps').
3. Under Conditions > Agent risk (Preview), set Configure to Yes and select High.
4. Under Access controls > Grant, select Block.
5. Set Enable policy to Report-only and create the policy.

Agent risk is the only condition available when a policy targets agent identities. Investigate flagged agents in the Risky Agents report in ID Protection. From there you can Confirm compromise, which sets risk to High and triggers this policy, Confirm safe, Dismiss risk, or Disable the agent. Risk detections are retained for up to 90 days.

In OBO flows, risky activity is attributed to the user rather than the agent, so your existing user risk policies handle those cases.

Step 4: Protect agents that act as users

Some agents have their own agent user account with a mailbox and Teams presence. Agent user targeting is in preview, and it has rules that differ from normal users:

• Policies that target all users, selected users, groups, directory roles or external users don't apply to agent user accounts.
• Group-based inclusion and exclusion isn't supported for agent user accounts. Use All agent users (Preview), select individual agent users, or use custom security attributes.

Microsoft documents three policies for this pattern:

Scope device and network policies with the Agent execution environments condition. Device compliance needs Intune enrollment, which is currently supported only on Windows 365 Cloud PCs for Agents, and a compliant network needs the Global Secure Access client. An agent running directly in cloud infrastructure has neither, so without the condition it would be blocked with no path to compliance.

Step 5: Keep on-behalf-of access covered by user policies

Most interactive agents use OBO. The agent exchanges the user's token for a new one scoped to the downstream resource, and that exchange is evaluated by Conditional Access against the user. Review your user policies with that in mind:

• Policies that require MFA, compliant devices or session controls for users already apply when an agent acts for them.
• Resource-scoped policies, such as stricter rules for a sensitive SharePoint site or a custom API, apply to the agent's OBO tokens for that resource.
• Excluding a user or group from a policy also removes that protection from every agent acting on their behalf.

Where Conditional Access does not apply

Conditional Access doesn't evaluate:

• An agent identity blueprint acquiring a token for Microsoft Graph to create an agent identity or agent user account. Blueprints can't access resources on their own.
• Intermediate token exchanges at the AAD Token Exchange Endpoint: Public resource (fb60f99c-7a34-4190-8149-302f77469936). Tokens for that endpoint can't call Microsoft Graph, and the agent's later token acquisition is still evaluated.
• Any tenant with security defaults enabled.
• Resources accessed with an API key or any credential that bypasses Microsoft Entra token issuance.

The last point matters for MCP servers and tools. If a tool accepts a static key, no Entra policy protects it. Register the tool as an application and require Entra tokens. The Zero Trust remote access architecture applies the same principle to human access.

Verify the policies

1. Use the What If tool at Entra ID > Conditional Access > Policies > What If. It can simulate a sign-in for an agent identity (preview) as well as for users and single-tenant service principals. Provide the identity, target resource, device platform and client app.
2. Let the policies run in report-only mode and open agent sign-ins in the sign-in logs. The Report-only tab shows results such as Report-only: Failure for agents the policy would block.
3. Check that every approved agent shows Report-only: Not applied for the block policy. If one shows failure, its blueprint or attribute is missing from the exclusion.
4. After review, switch Enable policy from Report-only to On.

Troubleshooting

Blocked agents surface the same Conditional Access failure codes as users; the guide on AADSTS53003 blocked by Conditional Access covers reading the policy result from the sign-in event.

Checklist

• Each agent mapped to its token subject: user (OBO), agent identity, or agent user account.
• Licensing confirmed, security defaults off, target resources registered in Entra ID.
• Report-only block policy for all agent identities, excluding approved blueprints or attribute values.
• Report-only block policy for high-risk agent identities.
• Agent user policies for risk, compliant device and compliant network, scoped with agent execution environments.
• User policies reviewed for OBO coverage; no broad user exclusions.
• Results verified with What If and the sign-in log Report-only tab before enforcing.

References

• Conditional Access for agents in Microsoft Entra
• Target agent identities in Conditional Access policies
• Secure autonomous agents with Conditional Access
• Secure agent users with Conditional Access
• ID Protection for agents
• Microsoft Entra Agent ID logs
• Integrate third-party agents with Microsoft Entra Agent ID
• Conditional Access: Grant
• The Conditional Access What If tool
• Analyze Conditional Access policy impact (report-only mode)