Securing AI Agent Identities in Microsoft Entra: Governance, Conditional Access and Least Privilege in 2026

Treat every AI agent as a non-human identity that needs the same Zero Trust controls as a user: a registered identity with an accountable sponsor, least-privilege access to only the resources it needs, a Conditional Access policy governing where and under what risk it can get a token, ID Protection watching it for anomalous behaviour, and an access review that expires it when no one will vouch for it. Microsoft Entra Agent ID gives you the identity plane to do this — but the defaults create agents faster than most tenants govern them, and legacy Copilot Studio agents running on plain service principals are invisible to it.

What is an agent identity (and why a service principal isn't enough)?

An agent identity is a Microsoft Entra identity purpose-built for an AI agent. Functionally it behaves like a workload identity — it authenticates and holds permissions — but it carries agent-specific classification, metadata and controls that a plain application or service principal does not.

The distinction matters because your tenant now holds two kinds of AI agent, and only one is governable as an agent:

• Agents with agent identities — created through Microsoft Entra Agent ID, or the current versions of Copilot Studio, Azure AI Foundry and Security Copilot. These have clear classification, rich metadata (sponsor, owner, blueprint), agent-specific audit trails and agent-aware Conditional Access and ID Protection.
• Agents without agent identities — created in earlier Copilot Studio / Azure AI Foundry versions as classic applications or service principals. They may carry tag values hinting they're AI agents, but Entra treats them as ordinary apps. They are subject only to the same controls as any other service principal — no agent-specific tracking.

That second category is the blind spot. If you inventory only "agent identities," legacy agents on service principals don't appear, yet they still hold permissions and still act. Any agent-governance programme has to account for both.

How agent identities proliferate (the sprawl problem)

The reason this is urgent in 2026 is that agents now get identities by default, from several channels, often created by non-admin makers:

• Copilot Studio began automatically creating an agent identity for every new agent on 18 March 2026. The user who creates the agent is recorded as its sponsor. Low-code makers can therefore mint governable identities without involving IT.
• Azure AI Foundry and Security Copilot scenario agents likewise create agent identities in current versions. Even Microsoft's own Conditional Access Optimization Agent runs under an agent identity and its queries are logged as performed by an AI agent.
• Microsoft Entra Agent ID is the platform underneath all of this — the framework for creating and managing agent identities and their blueprints.

Two timing facts you must plan around, both worth verifying against your own tenant: Copilot Studio's auto-creation started 18 March 2026, and existing agents created before the Entra Agent ID roll-out (around July 2026) remain on app registrations and are slated for backfill later. Governance capabilities work for both agent identities and those app-registration IDs during the transition — but you cannot assume every agent is a "proper" agent identity yet.

The security framing is simple: agents scale faster than humans, they're created by makers rather than admins, and each one is a standing set of permissions. Left ungoverned, that's textbook identity sprawl — with the added twist that the identity can reason and act on the access it holds.

The governance model: sponsor, owner, and blueprints

Entra Agent ID deliberately separates business accountability from technical administration:

• Sponsor (required) — the business owner accountable for the agent's purpose and lifecycle. This is who attests, in an access review, that the agent still needs to exist.
• Owner (optional) — the technical administrator who manages configuration, credentials and authentication properties.

Agent identity blueprints are the templates every agent identity is derived from: they define an agent type's owners, sponsors, access envelope and audit behaviour once, then apply consistently to every instance. Blueprints are also a control point in their own right — you can apply a Conditional Access policy at the blueprint level to cover every agent derived from it (including future ones), and you can disable a blueprint to stop new agents being created from it and block existing ones.

The roles that manage all this are Agent ID Developer and Agent ID Administrator in Microsoft Entra — scope them like any other privileged role.

Do I need a licence? (Agent 365, E5/E7, and standalone)

Licensing is the part most write-ups get wrong, so here it is precisely, verified against Microsoft Learn:

• Microsoft Entra Agent ID — the platform for creating and managing agent identities and blueprints — is available to all Microsoft Entra customers.
• Microsoft Agent 365 is required (per user) for agents to operate across Microsoft 365 services and enterprise workflows.
• Extending Entra security features to agents requires Microsoft 365 E7 (which includes Agent 365 and the Microsoft Entra Suite), or Microsoft 365 E5 paired with a Microsoft Agent 365 licence.
• Without E5/E7, use standalone licences alongside Agent 365, feature by feature:
  • Conditional Access for agents → Microsoft Entra ID P1
  • ID Protection for agents → Microsoft Entra ID P2
  • ID Governance for agents → Microsoft Entra ID P1
  • Network controls for agents → Microsoft Entra Internet Access (in the Entra Suite or licensed separately)

This mirrors the human-identity split you already know from our Conditional Access baseline guide: P1 buys you enforcement, P2 buys you risk.

Conditional Access for agents — how targeting actually works

You can bring agents under Conditional Access, but what a policy targets depends on how the agent authenticates — the detail most write-ups miss. Conditional Access is evaluated whenever Entra issues or refreshes an access token, using if-then rules, and requires Entra ID P1 or P2 plus a Microsoft Agent 365 licence (Agent 365 licence enforcement is "coming soon" per Microsoft Learn).

Three access patterns, three targeting models:

• Agent acting on behalf of a user (OBO / delegated) — the most common pattern. The token's subject is the user, so the policy targets users and groups, not the agent identity. This is why "just write a CA policy for the agent" often doesn't fire.
• Agent acting as an application (app-only / autonomous) — the token is issued to the agent identity, so the policy targets the agent identity: individually, via its blueprint, or via custom security attributes for scale.
• Agent acting as its own user account — a "digital worker" account is the subject, so the policy targets that agent user account, and can require device compliance / compliant network via the Agent execution environments condition.

Beyond targeting, you can block on High Agent Risk (see ID Protection below) and keep a tenant-wide block on all agent identity authentication as an emergency switch. Because Copilot Studio attaches each agent's connector permissions as first-class API permissions on its Entra Agent ID, you can also target those connector resources — e.g. require a network location or risk condition before a token issues for a specific connector — with the scopes re-validated at runtime against Advanced Connector Policies (ACP) and DLP.

Documented limits to design around (Microsoft Learn): Conditional Access for agents does not apply when Security Defaults are enabled, or when an agent reaches a resource via an API key (which bypasses Entra token issuance entirely); a policy targeting All users does not include agent user accounts; and a policy targeting agent identities does not cover an agent's user account. So this isn't a "lightweight" bolt-on — it's genuinely capable — but its coverage has specific edges you must account for.

ID Protection for agents — risk you didn't have to write

With P2, Microsoft Entra ID Protection extends to agents — in preview (P2 during preview). It surfaces a Risky Agents report and detects several offline risk types for autonomous agents: unfamiliar resource access, sign-in spike, failed access attempt, early-life malicious activity, Entra directory reconnaissance, suspicious credential usage and Microsoft threat-intelligence matches. Admins can confirm compromise (which sets risk to High and triggers any Conditional Access policy set to block on High Agent Risk), confirm safe, dismiss, or disable the agent. One important nuance: in on-behalf-of flows the risky activity is attributed to the user, not the agent, so remediation targets the compromised user session. This is the agent equivalent of the sign-in-risk and user-risk policies in the human baseline — behavioural detection without hand-writing every rule.

Least privilege and connector governance

An agent's blast radius is exactly the access it holds, so least privilege is the highest-leverage control:

• Grant only the resources the task needs. Entra Agent ID lets you enforce least-privilege access by giving agents rights only to the apps and resources required to complete their work.
• See connectors without leaving Entra. Because connector permissions surface on the agent's Entra Agent ID, admins can see which connectors an agent can call from the Entra admin center — no hunting through Power Platform.
• Layer ACP + DLP. Connector scopes are honoured only by the Power Platform connector runtime and re-validated against Advanced Connector Policies and DLP at runtime. Keep those policies authoritative; they are what actually stops an over-scoped agent.
• Add network controls for Copilot Studio agents. The Secure Web and AI Gateway (Global Secure Access / Entra Internet Access) applies web-content, threat-intelligence and network-file filtering to agent traffic.

This is the identity-and-access companion to the data-side controls in our Purview DSPM Copilot governance guide: DSPM stops Copilot surfacing overshared content; least-privilege agent identities stop an agent reaching systems it was never meant to touch.

The agent-governance baseline (named, numbered)

A concrete starting set for a Microsoft-heavy tenant. Adapt the naming to your convention.

What breaks in production (the real gotchas)

• Globally disabling agent identities breaks Microsoft experiences. A tenant-wide block is a blunt instrument: existing agents can start failing, Copilot Studio / Security Copilot / the CA Optimization Agent may degrade, and — worst of all — teams get pushed back onto opaque service principals that lack agent-specific tracking. Prefer Conditional Access to block specific agents over disabling all agent identities. Keep the tenant-wide block as a break-in-case-of-emergency switch, not a daily control.
• Legacy Copilot Studio agents don't migrate in place. There is no automated or in-place migration to convert an existing Copilot Studio agent's service principal into an agent identity. The supported path is recreate-and-deprecate: create a new agent with the Agent ID integration enabled, reconfigure it, then decommission the legacy one. Plan for rework, not a switch-flip.
• Backfill hasn't happened yet. Agents created before the ~July 2026 roll-out remain on app registrations pending future backfill. Your "agent identities" view is therefore incomplete — inventory service-principal-based agents separately until backfill completes.
• Makers create identities, not just agents. Because Copilot Studio auto-creates an identity (sponsored by the maker) on every new agent, governance has to reach makers — naming, sponsorship and least privilege can't live only with IT.
• Connector scopes are not your DLP. The API permissions on an agent's Entra Agent ID are visibility and CA targets; the enforcement is ACP + DLP at runtime. Don't mistake "I can see the connector scope" for "the connector is governed."
• Conditional Access has coverage edges. It doesn't apply under Security Defaults, or when an agent uses an API key instead of an Entra token, and policies targeting "All users" don't reach agent user accounts. Design for these gaps rather than assuming blanket coverage.
• Standing access accumulates silently — the same failure mode as human identities. Without access reviews and access packages, an agent's permissions outlive its purpose. This is why AG08/AG09 are not optional.

Staged rollout plan

• Stage 1 — this week (visibility). Open Entra ID → Agent identities, inventory what exists, and separately list service-principal-based agents (tagged AI apps) that predate agent identities. You cannot govern what you can't see. Threshold to proceed: a single list of every agent and its identity type.
• Stage 2 — weeks 1–2 (accountability). Enforce naming (AG02), confirm a sponsor on every agent (AG03), and disable or reassign orphaned agents. Define blueprints for your common agent types so new agents inherit sponsor/owner/access-envelope defaults.
• Stage 3 — weeks 2–4 (least privilege + Conditional Access). Trim each agent's access envelope to what its task needs (AG04). Stand up Conditional Access on agent resources (AG05) in report-only first, exactly as you would for users, then enforce. Prepare — but keep off — a tenant-wide "block all agent identities" policy as an emergency switch (AG06).
• Stage 4 — weeks 4–6 (risk + lifecycle). If you hold P2, enable ID Protection for agents (AG07). Move agent fleets onto access packages (AG08) and add agents to access reviews with sponsor attestation every 6–12 months (AG09). Add network controls (Secure Web and AI Gateway) for Copilot Studio agents where traffic warrants it.
• Stage 5 — ongoing (governance). Run the quarterly orphaned-agent sweep (AG10). Re-inventory as backfill migrates legacy service principals into agent identities. Pair this with Entra PIM for the humans who administer agents, so no one holds standing Agent ID Administrator rights.

A note on verification

The agent-identity model, licensing tiers, Conditional Access targeting and boundaries, ID Protection risk types, and the dates above (Copilot Studio auto-creation from 18 March 2026; agent identities rolling out around July 2026 with backfill to follow) were verified against Microsoft Learn's Entra Agent ID, Conditional Access for agents, ID Protection for agents, Agent 365 and Copilot Studio documentation on 8 August 2026. Several capabilities are new and still moving — ID Protection for agents is in preview (P2 during preview), and Agent 365 licence enforcement for Conditional Access is noted as "coming soon" — so confirm feature state, exact licensing and portal wording in your own tenant before quoting a date or making a change.

Further reading and references

From TheAdminStack

• Conditional Access Baseline Policies Every Microsoft 365 Tenant Needs in 2026 — the human-identity companion; where the "block high-risk agent identities" managed policy is introduced.
• Govern Microsoft 365 Copilot with Purview DSPM — the data-side controls that pair with agent least privilege.
• Securing Microsoft 365 Copilot: The Oversharing Remediation Playbook — classify-restrict-monitor for the content agents can reach.
• How to Configure Microsoft Entra PIM for Just-in-Time Admin Access — remove standing privilege for the humans who administer agents.

Microsoft Learn (primary sources, verified 8 Aug 2026)

• Microsoft Entra security for AI — overview
• What are agent identities
• Conditional Access for agents
• ID Protection for agents (risky agents)
• Manage agent identities in your organization
• Best practices for Microsoft Entra Agent ID
• Recreate Copilot Studio agents in Entra Agent ID (licensing & migration)
• Microsoft Agent 365 overview

Frequently asked questions

What is a Microsoft Entra agent identity?

It's a Microsoft Entra identity built specifically for an AI agent. It authenticates and holds permissions like a workload identity, but carries agent-specific classification, metadata (sponsor, owner, blueprint) and agent-aware Conditional Access, ID Protection and audit. Agents created on older platforms may instead be plain service principals, which Entra treats as ordinary applications with no agent-specific controls.

Do agent identities cost extra?

Microsoft Entra Agent ID (creating and managing agent identities and blueprints) is available to all Entra customers. Making agents operate across Microsoft 365 needs a Microsoft Agent 365 licence per user, and extending Entra security features to agents needs Microsoft 365 E7, or E5 plus Agent 365, or standalone Entra ID P1/P2 and Internet Access licences alongside Agent 365 depending on which feature you want.

Can I apply Conditional Access to AI agents?

Yes, and it's more capable than "block only," but what a policy targets depends on the flow: on-behalf-of (delegated) agents are governed by policies on the user; app-only / autonomous agents by policies on the agent identity (directly, by blueprint, or by custom security attribute); and agent user accounts as their own accounts. You can also block on High Agent Risk and keep a tenant-wide block as a kill switch. It needs Entra ID P1/P2 plus Agent 365, and doesn't apply under Security Defaults or when an agent reaches a resource via an API key.

What's the difference between a sponsor and an owner?

The sponsor is required and is the business owner accountable for the agent's purpose and lifecycle — the person who attests at review time. The owner is optional and is the technical administrator who manages the agent's configuration, credentials and authentication properties.

How do I stop a rogue agent?

Prefer a targeted Conditional Access policy that blocks the specific agent identity, or disable that single agent. Disabling all agent identities tenant-wide is a blunt emergency control that can break Microsoft experiences and push teams back onto opaque service principals — evaluate the impact first.

Are my old Copilot Studio agents already governed by Agent ID?

Not necessarily. Agents created before Entra Agent ID rolled out (around July 2026) remain on app registrations pending backfill, and legacy Copilot Studio agents on service principals have no automated in-place migration — you recreate them with Agent ID enabled and decommission the old ones. Inventory service-principal-based agents separately until backfill completes.