Why Global Administrator Lost Agent User Lifecycle Permissions in Microsoft Entra

Global Administrator lost a defined set of Agent ID-related actions in the Microsoft Entra built-in role reference. I compared the MicrosoftDocs role include files and the shape is clear: Global Administrator lost 19 actions and gained 2 actions, while the surrounding AI Administrator and Agent ID roles now own the narrower agent management tasks.

That is not a bad thing. It is the kind of change I expect when a new identity type becomes real enough to need its own operating model. AI agents are no longer just an application feature hidden behind a service. They have identities, owners, lifecycle, permissions, sign-in activity, and governance concerns. Putting all of that under Global Administrator forever would be the easy path, but not the right one.

My read: Microsoft is splitting agent management into dedicated roles so tenants can stop using Global Administrator as the default answer for every AI administration problem.

What changed

The official Microsoft Entra built-in roles reference now includes the Agent ID and AI roles that make this split possible. The GitHub source behind that page has ms.date 05/21/2026, and the file history includes a 21 May 2026 commit titled ID Governance Admin ir now privileged. The typo is in the commit title, not mine.

That GitHub history lines up with the visible role reference, where Identity Governance Administrator is now shown with the privileged role indicator. That part is easy to defend with Microsoft-owned documentation and MicrosoftDocs GitHub history.

The Agent ID roles are official Learn roles. The role catalog lists Agent ID Administrator, Agent ID Developer, Agent Registry Administrator, AI Administrator, and AI Reader. Agent ID Administrator is described as managing agent lifecycle operations for agent blueprints, blueprint principals, agent identities, and agentic users.

The Global Administrator detail is pulled from a generated include file named includes/global-administrator.md. The current include has ms.date: 06/11/2026. Comparing that file with the 21 May 2026 revision gives the same shape as the same result: 19 actions removed and 2 actions added. The related role includes show where the work moved: AI Administrator gained the 17 agentUsers/* lifecycle actions, Agent ID Administrator gained recovery and authentication actions, and Agent ID Developer gained blueprint create-as-owner.

The timeline I see

The Entra releases and announcements page lists General Availability - Microsoft Entra Agent ID platform under April 2026. That entry describes Agent ID as an identity and authorization framework for AI agents, using protocols such as OAuth 2.0, MCP, and A2A.

For AI Reader, the useful source is Microsoft 365 Message Center item MC1296473, published 30 April 2026. It says the role would roll out in early May 2026 and provide read-only access to Agent 365 usage, health, and configuration. It also says existing roles, permissions, and policies were not changed by that announcement.

Then on 21 May 2026, the role reference source was updated. That looks like the documentation point where the Agent ID and AI roles, plus the privileged-role metadata change for Identity Governance Administrator, became visible in the role catalog source. The Global Administrator include itself was updated later, with ms.date: 06/11/2026.

What Agent ID is

The What is Microsoft Entra Agent ID? page describes Agent ID as an identity and security framework for AI agents. The same page says Agent ID is available for all Microsoft Entra customers, with additional licensing needed for specific security features such as Conditional Access for agents, ID Protection for agents, ID Governance for agents, and network controls.

The agent identities page explains the model behind the permissions: agent identities are special service principals created from agent identity blueprints. They do not hold credentials themselves. The blueprint acquires tokens on behalf of the agent identity.

The short version is this:

• Agent identity blueprint is the template that defines how an agent identity can be created and what it can request.
• Agent identity blueprint principal is the service principal representation of that blueprint in the tenant.
• Agent identity is the identity used by an AI agent when it needs access to resources.
• Agent user is the agentic user object that has its own lifecycle: create, delete, enable, disable, restore, licensing, manager, sponsors, usage location, and sign-in session controls.

That object model is why the role changes matter. If agents now have identity objects and user-like lifecycle operations, tenants need separate build, operate, read, and governance roles. Otherwise every agent task ends up as a Global Administrator task, which is exactly what Microsoft appears to be moving away from.

The authorization page for Microsoft Entra Agent ID is also relevant. It says agents are not suitable for unrestricted high-privilege directory access, blocks several sensitive role and Graph permission paths for agent identities, and points to Agent ID Administrator and Agent ID Developer as the roles for managing and creating agents.

The manage agent identities page is useful because it maps tasks to roles. It says viewing agent identities does not require an admin role, managing agent identities can use Agent ID Administrator or Cloud Application Administrator, creating agent blueprints uses Agent ID Developer, and Conditional Access policy work still belongs with Conditional Access Administrator.

Who owns what now

This is the role split I would use when reviewing a tenant. It is not only about who can click a button today. It is about separating build, operate, read, and govern responsibilities before agent identities become another unmanaged identity pile.

Role	Use it for	Do not use it for
Agent ID Administrator	Operating Agent ID objects: agent identities, blueprints, blueprint principals, authentication settings, and deleted-item restore/delete for Agent ID objects.	General AI service administration or broad tenant administration.
Agent ID Developer	Creating agent identity blueprints and becoming owner of what was created.	Tenant-wide agent operations after the blueprint is in place.
AI Reader	Read-only monitoring of Microsoft 365 Copilot, AI services, copilot agents, and agent identity objects.	Creating, changing, disabling, or restoring agent objects.
AI Administrator	AI service administration and the agentUsers/* lifecycle set: create, delete, enable, disable, license, restore, update profile fields, and revoke sessions.	Agent ID blueprint design or PIM governance by itself.
Identity Governance Administrator	Access reviews, lifecycle governance, entitlement management, and governance controls around privileged assignments.	Direct Agent ID object operations. The change here is privileged-role classification, not an Agent ID permission transfer.
Global Administrator	Break-glass and tenant-wide administration when no narrower role fits.	Routine Agent ID or AI lifecycle work. That is the point of this permission split.
Agent Registry Administrator	Managing Agent Registry objects where your tenant uses Agent Registry.	General Agent ID lifecycle or agent-user lifecycle work.

About the Global Administrator diff

I compared the MicrosoftDocs current global-administrator.md include with the 21 May 2026 revision. The action list confirms 19 removed actions and 2 added actions for the Global Administrator role.

Change	Actions
Removed from Global Administrator	microsoft.directory/agentIdentityBlueprints/allProperties/read microsoft.directory/agentIdentityBlueprints/verification/update microsoft.directory/agentUsers/assignLicense microsoft.directory/agentUsers/basic/update microsoft.directory/agentUsers/create microsoft.directory/agentUsers/delete microsoft.directory/agentUsers/disable microsoft.directory/agentUsers/enable microsoft.directory/agentUsers/invalidateAllRefreshTokens microsoft.directory/agentUsers/lifeCycleInfo/read microsoft.directory/agentUsers/lifeCycleInfo/update microsoft.directory/agentUsers/manager/update microsoft.directory/agentUsers/photo/update microsoft.directory/agentUsers/reprocessLicenseAssignment microsoft.directory/agentUsers/restore microsoft.directory/agentUsers/revokeSignInSessions microsoft.directory/agentUsers/sponsors/update microsoft.directory/agentUsers/usageLocation/update microsoft.directory/agentUsers/userPrincipalName/update
Added to Global Administrator	microsoft.directory/agentIdentities/authentication/update microsoft.directory/agentIdentityBlueprintPrincipals/authentication/update

The important pattern is that most removed actions are agentUsers lifecycle and profile actions. Global Administrator still has many Agent ID object actions in the current include, but the agent-user lifecycle set is no longer sitting directly in the Global Administrator action list.

How the other roles connect

After checking the related include files, AI Administrator is part of the story. The 17 agentUsers/* actions removed from Global Administrator show up as additions to AI Administrator. Agent ID Administrator and Agent ID Developer also changed, but in a different part of the Agent ID control plane. AI Reader changed too, but that looks like read-scope tuning, not a direct move from Global Administrator.

Date in MicrosoftDocs include	Role	What changed
21 May 2026	Identity Governance Administrator	Role catalog shows it as privileged. I did not find an action-list change in the include comparison.
11 June 2026	Global Administrator	Lost 19 actions and gained 2 actions in the generated include.
11 June 2026	Agent ID Administrator	Gained recovery and authentication-related Agent ID actions, and lost two older actions.
11 June 2026	Agent ID Developer	Gained blueprint create-as-owner.
17 June 2026	AI Administrator	Gained 17 agentUsers/* actions, matching the agent-user action set removed from Global Administrator.
17 June 2026	AI Reader	Lost microsoft.office365.usageReports/allEntities/allProperties/read. I read this as read-scope tuning, not part of the Global Administrator permission move.

Why this was needed

This change makes sense because AI agents are becoming first-class identities in Microsoft Entra. Once an agent has an identity, owners, lifecycle, permissions, and sign-in activity, it needs the same basic separation of duties we already expect for users, apps, devices, and privileged roles.

Global Administrator is too broad for that daily work. If every agent-user lifecycle task stays under Global Administrator, the tenant has only two bad choices: over-assign Global Administrator to AI operators, or force every agent lifecycle request through a tiny group of tenant admins. Neither model scales well, and neither is great for auditability.

The new split is cleaner. AI Administrator owns the agent-user lifecycle set. Agent ID Administrator owns more of the Agent ID object recovery and authentication surface. Agent ID Developer gets the blueprint owner creation path. AI Reader gives security and operations teams visibility without write access. Global Administrator still exists for broad tenant control, but it should not be the normal role for agent operations.

That fits the normal least-privilege direction in Microsoft Entra and the Agent ID authorization model. Microsoft is already blocking highly privileged role assignments and sensitive Graph permissions for agent identities. It would be odd to do that on the agent side, while leaving every agent-user lifecycle task bundled into the broadest human administrator role. The two Global Administrator additions also make sense in that model: Global Administrator still keeps control over authentication-related settings on agent identities and blueprint principals, while the agent-user lifecycle actions move to AI Administrator.

Practical read: Do not treat Global Administrator as the operational Agent ID role. Review Agent ID Administrator, Agent ID Developer, AI Administrator, and AI Reader assignments directly.

How to see the diff yourself

There are two practical ways to check this. Microsoft Graph shows the current tenant-facing role definition. MicrosoftDocs history lets you compare the current generated role reference with an older generated role reference.

For the current state in a tenant, query the Global Administrator role definition. Microsoft Graph documents role definitions as unifiedRoleDefinition objects, and the permission list is exposed under rolePermissions.allowedResourceActions.

Connect-MgGraph -Scopes "RoleManagement.Read.Directory"

$globalAdmin = Get-MgRoleManagementDirectoryRoleDefinition `
  -Filter "templateId eq '62e90394-69f5-4237-9190-012177145e10'"

$globalAdmin.RolePermissions.AllowedResourceActions |
  Sort-Object |
  Where-Object { $_ -like "microsoft.directory/agent*" }

The raw REST call is the same idea. The Graph API lists role definitions under /roleManagement/directory/roleDefinitions. Microsoft documents RoleManagement.Read.Directory as the least privileged Graph permission for this read.

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleDefinitions?$filter=templateId eq '62e90394-69f5-4237-9190-012177145e10'

For the historical diff, compare the MicrosoftDocs include file revisions. This is what I used for the 19 removed and 2 added action count.

$before = Get-Content .\global-administrator-59b7d5b.md
$after  = Get-Content .\global-administrator-main.md

function Get-RoleActions($lines) {
  $lines | ForEach-Object {
    if ($_ -match '^> \| ([^|]+) \|') {
      $action = $matches[1].Trim()
      if ($action -like 'microsoft.*') { $action }
    }
  } | Sort-Object -Unique
}

$oldActions = Get-RoleActions $before
$newActions = Get-RoleActions $after

Compare-Object $oldActions $newActions

How I would handle this

If I were reviewing this in a tenant, I would treat Agent ID like a new identity workload, not as a side note under Global Administrator.

1. Start with assignments. List Global Administrator, Privileged Role Administrator, Identity Governance Administrator, AI Administrator, AI Reader, Agent ID Administrator, Agent ID Developer, and Agent Registry Administrator.
2. Move standing access into PIM where possible. I would especially avoid permanent Agent ID Administrator and AI Administrator assignments unless there is a clear operational reason.
3. Use Agent ID Developer for teams that need to create blueprints. Do not hand them Global Administrator just because they are building an agent.
4. Use Agent ID Administrator for operating agent identities, blueprint principals, authentication settings, and deleted-item restore/delete for Agent ID objects.
5. Use AI Administrator for the agent-user lifecycle: create, disable, enable, delete, restore, license, profile updates, sponsors, manager, usage location, UPN, and sign-in session actions.
6. Use AI Reader for security operations, service owners, and governance reviewers who need visibility without write access.
7. Use Identity Governance Administrator to govern privileged access, access reviews, entitlement management, and lifecycle workflows around these role assignments.
8. Review existing agent identities under Entra ID > Agents > Agent identities. Check owners, sponsors, granted permissions, sign-in logs, and audit logs.
9. Decide whether Conditional Access for agents should be in report-only mode first, then move to enforcement when the impact is understood.

The operational question is no longer only "who has Global Administrator?" It is "who can build, operate, read, restore, and govern AI agent identities?" Those are different jobs, and the role catalog is starting to reflect that.

Source links

• Microsoft Entra built-in roles
• GitHub source for the built-in roles page
• GitHub history for the built-in roles page
• Current MicrosoftDocs Global Administrator include
• Current MicrosoftDocs AI Administrator include
• Current MicrosoftDocs Agent ID Administrator include
• Current MicrosoftDocs Agent ID Developer include
• 21 May 2026 Global Administrator include revision used for the diff
• Microsoft Graph unifiedRoleDefinition resource
• Microsoft Graph list roleDefinitions API
• Microsoft Entra releases and announcements
• What is Microsoft Entra Agent ID?
• Agent identities in Microsoft Entra Agent ID
• Authorization in Microsoft Entra Agent ID
• Manage agent identities in your organization
• Microsoft Agent 365 overview
• New licensing prerequisite for Agent 365
• Microsoft announcement for Agent 365 and Microsoft 365 E7 pricing
• USD to EUR rate used for the euro estimate
• Microsoft 365 Message Center MC1296473, published 30 April 2026, for the AI Reader rollout.