Microsoft Entra Agent ID: Conditional Access + Defender XDR…

The identity that didn’t exist a year ago

Simple explanation

Microsoft Entra Agent ID is a new identity type — alongside user accounts, group accounts, and service principals — that represents an autonomous AI agent in your tenant. Microsoft 365 Copilot has an Agent ID. Each Copilot Studio agent has its own Agent ID. Custom Foundry agents have Agent IDs. So do certain partner agents.

This matters because, before Agent ID, you had no clean way to apply identity controls to agents. They acted “as” the invoking user via OAuth on-behalf-of flows, with no agent-shaped object to govern. Now you can:

Apply Conditional Access to an Agent ID — require the invoking user be on a compliant device, in a trusted location, with phishing-resistant MFA — before an agent can act on their behalf.
Manage what an Agent ID can reach — grant or revoke API permissions on the agent’s identity, control which channels it can be invoked from, govern its access reviews.
Analyse blast radius — when something goes wrong, Microsoft Defender XDR can trace which Agent ID was involved, what data it touched, which users invoked it, and what the downstream impact was.

The exam expects you to treat Agent ID as a first-class identity — same toolset as user identity, applied to agents.

Conditional Access for Agent ID

Conditional Access (CA) gained Agent ID as a principal type. A CA policy can now have:

Conditional Access for Agent ID — same model as user CA, applied to agents
CA component	When the principal is a user	When the principal is an Agent ID
Who the policy targets	Users and groups	Specific Agent IDs, all Agent IDs, or filtered subsets (e.g. 'all Copilot Studio agents created by Finance')
Conditions evaluable	User device, location, sign-in risk, user risk, client app, app filters	Invoking user's device + location + risk (the agent inherits invoker context), channel of invocation, agent risk signals from Defender XDR
Typical grant controls	MFA, compliant device, app protection, auth strength	Require invoking user to be on compliant device + phishing-resistant MFA; require invocation from approved channel; block when agent has elevated risk score
Session controls	Sign-in frequency, persistent browser, CAE	Limit agent action volume per session, require human-in-the-loop approval for high-risk actions

Typical Agent ID CA policy

The exam-archetype policy:

Assignments
- Principals (Agent IDs): all Copilot Studio agents tagged “Finance” (filterable subset)
- Target resources: Microsoft Graph + the Dataverse environments holding finance data
- Conditions: invoking user’s location = Aurora Health Service corporate network; invoking user’s device = compliant
Access controls
- Grant: require invoking user be on compliant device AND satisfy phishing-resistant MFA AND user be in the “Finance Power Users” group

If any condition fails, the agent cannot complete the action — even though the underlying user might have had permission to do so directly. This is the “agent invocation needs even stricter context than the user’s direct access” pattern.

Managing Entra Agent ID access

Agent ID access management blends with the agent runtime governance from the previous module. Two layers:

Identity-layer governance (this module) — Microsoft Graph and other API permission grants on the Agent ID, access reviews on Agent IDs (same access-review machinery as user/group reviews), enable/disable on the Agent ID, and lifecycle transitions tied to the agent runtime (e.g. when a Copilot Studio agent is deleted, its Agent ID is cleaned up).
Runtime-layer governance (previous module) — what the agent reads (knowledge sources), which channels it publishes to, real-time protection settings.

Both layers must align: granting an Agent ID Files.Read.All Graph permission means nothing if the agent’s runtime knowledge sources are limited to two SharePoint sites. Conversely, narrowing knowledge sources in the runtime doesn’t prevent the Agent ID from being assigned broader API permissions that a misconfigured tool call could invoke. The exam expects you to reason about both layers.

Why CA on the user alone isn't enough

Pre-Agent ID, your only CA hook for agent invocation was the invoking user’s CA policy. If the user satisfied their CA policy, the agent could act with the user’s identity in OBO flows. This is too coarse:

The user might satisfy “MFA + compliant device” for accessing M365 broadly, but the same user invoking a Foundry agent that reaches patient data deserves a stricter check.
A CA policy can’t distinguish “user opens Word” from “user invokes the genomics-query Copilot Studio agent”. Same user, different risk.

Agent ID gives you the second hook. The agent itself is now a principal that CA can target, with conditions and grant controls that apply specifically to invocation of that agent — independent of the user’s broader CA posture.

Defender XDR blast radius analysis

Microsoft Defender XDR is the unified incident view across Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, and (via the Defender for Cloud connector) Defender for Cloud and Defender for AI Service alerts.

When an incident involves an Agent ID, Defender XDR represents the agent as an entity in the incident graph alongside users, devices, IP addresses, files, and processes. The “blast radius” view answers:

Which Agent IDs were involved? Direct vs. indirect involvement.
Which users invoked the agent during the incident window?
What knowledge sources did the agent read? SharePoint sites, OneDrive paths, Dataverse environments, custom connectors.
What downstream data flows resulted? Did the agent surface labelled-sensitive content to the user? Did the user then forward or upload it elsewhere?
What other entities are connected? Devices, IP addresses, the user’s other agent invocations.

This entity graph is what lets a SOC analyst (Dom-shaped, in our cast) say “the breach radius is contained to these 12 users and these 3 SharePoint sites” with evidence, instead of “we’ll have to assume the whole tenant.”

Sentinel + Defender XDR

Microsoft Sentinel ingests Defender XDR incidents via the Defender XDR connector. Once in Sentinel, the incident can be enriched with Sentinel-side data (network telemetry, custom logs, threat intelligence) and routed through Sentinel automation rules and playbooks. SC-500 expects you to know that Agent ID entities flow end-to-end from Defender XDR into Sentinel via this connector.

Scenario: Ravi tightens CA on Maple Genomics’ patient-data agents

Ravi at Maple Genomics has 4 Copilot Studio agents that read from the Patient Data SharePoint site (sensitivity-labelled “Confidential — Patient Data”). His earlier work locked down agent runtime (previous module). Now he wants identity-layer control:

Group the 4 agents under a tag/filter “Patient-data agents” in Entra > Agent ID. (Agent ID supports filterable subsets that CA can target.)
CA policy ‘Patient agent invocation — high-assurance’:
- Principals: Agent IDs filter = tag “Patient-data agents”
- Target resources: Microsoft Graph + Dataverse environments holding patient data
- Conditions: invoking user’s device must be compliant; invoking user’s location must be corporate-network or VPN-trusted
- Grant: require Phishing-resistant MFA auth strength AND user in the “Patient Data Authorised” group
Access reviews on the Agent ID API permissions quarterly — agents that haven’t been invoked in 60 days lose their elevated Graph permissions automatically.
Defender XDR integration verified — confirm the 4 Agent IDs surface in Defender XDR incidents and that the Sentinel connector ingests the incidents into the SOC’s Sentinel workspace.

A month later, a researcher’s laptop is flagged by Defender for Endpoint for unusual outbound traffic. The Defender XDR incident graph shows the researcher invoked one of the patient-data agents 14 times in the last hour, and the agent retrieved 47 patient records (which the researcher then attempted to upload to a consumer file-sharing site, blocked by Defender for Cloud Apps). The graph cleanly answers: which user, which agent, which data, what they tried to do with it. Blast radius is one user, one agent, 47 records. Containment fires automatically via a Sentinel playbook.