Your AI agents already have identities in Entra ID

Since May 2026, every new agent built in Copilot Studio gets its own Entra Agent ID. Nobody has to request it, and the opt-out at environment level is gone. In most tenants this means AI agents are now part of the identity estate, whether IT planned for them or not.

Agents created before May keep their old app registrations until Microsoft migrates them. So a typical tenant now holds 2 populations of agents, managed in 2 different ways. Both have rights. Both sign in. The question for a CIO is simple: who is accountable for each of them, and what can they actually do?

The following 5 checks answer that question. None of them needs a new tool. They need someone who reads the data that Entra ID already provides.

Check 1: every agent has a sponsor who still works here

Entra Agent ID separates 3 roles. The sponsor is the business person accountable for the agent’s purpose, access reviews and retention. The owner handles the technical side: configuration and credentials. A manager can request access packages for the agent, but cannot change or delete it.

A sponsor is mandatory when an agent identity is created. If a user creates the agent and names nobody else, that user becomes the sponsor automatically. In a typical environment this is a maker in finance or HR who built a helpful agent on a Friday afternoon. Accountability then rests with someone who may never have thought about identity governance.

Microsoft’s documentation does not describe an automatic handover when a sponsor leaves the company. It recommends maintaining sponsorship and offers lifecycle workflow templates that notify managers and transfer sponsorship on a leaver or mover event. Those workflows only help if someone has switched them on.

Check 2: Entra Agent ID permissions come from the blueprint

Every agent identity is the child of a blueprint. For Copilot Studio, this is a Microsoft blueprint that appears in your tenant with the first agent created after the May rollout. Custom and third-party agents bring their own blueprints.

The blueprint matters more than the agent. In tests published by Compass Security in June 2026, client secrets, certificates and federated credentials could only be configured on the blueprint, not on the agent identity. Permissions granted on the blueprint principal can be inherited by its child agents, and those inherited permissions do not show up when you look at the agent identity directly.

The consequence is practical. To know what an agent can do, you review the agent, the blueprint and the blueprint principal together. And you treat blueprint owners, the Agent ID Administrator role and the AI Administrator role as privileged roles, with the same protection you give to Tier 0 admins.

Check 3: Microsoft’s guardrails stop at the directory

Microsoft has built real limits into Entra Agent ID. Global Administrator, Privileged Role Administrator and User Administrator cannot be assigned to agent identities, and agents cannot join role-assignable groups. A set of high-risk Graph permissions, among them Application.ReadWrite.All and RoleManagement.ReadWrite.All, is blocked even when an administrator tries to consent.

These limits are a floor, not a design. The list of roles that can still be assigned includes Exchange Administrator, Teams Administrator and Power Platform Administrator. Compass Security found 6 allowed Graph application permissions with Tier 0 relevance, including Application.ReadUpdate.All and RoleAssignmentSchedule.ReadWrite.Directory. Blocking a single permission does not block a different permission with the same effect.

Azure is the larger gap. Microsoft advises assigning Azure roles to agents narrowly, for example Key Vault Reader on a single vault. In the same tests, Compass observed no restriction on assigning Azure RBAC roles such as Owner to an agent identity. Microsoft’s directory guardrails do not protect your subscriptions.

Check 4: Conditional Access for agents is a licensing question

Copilot Studio attaches the scopes of every Power Platform connector an agent uses as API permissions on its Entra Agent ID. That makes them visible to Entra admins without the Power Platform admin center, and it makes them targetable with Conditional Access: network location, device compliance or risk conditions before a token is issued.

Since July 2026, these capabilities sit in dedicated service plans. According to Microsoft message MC1395007, Conditional Access and ID Protection for agents are part of Microsoft Agent 365 and Microsoft 365 E7. Organisations that use them without one of these licences need the appropriate licence to keep using them.

For a CIO, this changes the business case. Agent governance is no longer covered by the Entra ID P1 or P2 licences that protect your users. If you plan agents with access to sensitive data, put the licence into the same decision as the agent itself.

Check 5: an agent earns write access with its sign-in history

Entra ID logs agent authentication like any other sign-in. This is the most underused data in agent governance. Before an agent gets any application permission that writes data, its sign-in and audit history should show what it actually did with read access over a defined period, typically several weeks.

Microsoft’s own guidance points in the same direction. Agents that act for a user should use delegated permissions, so they can never exceed that user’s access. Application permissions are for agents that run autonomously across the tenant, and Microsoft recommends using them sparingly and only when they are not high-privilege.

In practice this means 3 stages: delegated or read-only first, scoped write access second, autonomous application permissions only where the business case is documented and a sponsor has signed it.

What to do now

1. IT Operations, this week: export all agent identities from the Entra admin center, plus all Copilot Studio agents that still run on app registrations. List sponsor, owner, blueprint, assigned roles, API permissions and Azure role assignments for each.
2. CISO: add Agent ID Administrator, AI Administrator and all blueprint owners to your privileged access model. Require phishing-resistant MFA and Privileged Identity Management for them, and review them with the same rhythm as Global Administrators.
3. Cloud team: search every subscription for Azure role assignments to agent identities. Replace subscription-wide roles with resource-scoped roles, or remove them.
4. CIO: decide which agents need Conditional Access before they touch sensitive data, and check whether Microsoft Agent 365 or Microsoft 365 E7 is in the budget for exactly those agents.
5. Board: ask for 1 number each quarter: how many agents have rights in production, and how many of them have an active sponsor.

We apply the same rule to our own agents that we recommend to clients: read access before write access, with a named person responsible for every agent and its rights. Our agents work with scoped, logged identities, and a senior partner answers for what they change. If you want this structure for your own tenant, see AI Agent Operations & Governance, or start with the Executive IT & AI Review. For the device side of the same tenant, read our analysis of Windows 10 ESU year 2.