When Microsoft announced Entra Agent ID, the pitch was straightforward: as AI agents proliferate across enterprise environments, they need proper identities. Not shared app registrations tucked away in a service account. Real, governed, auditable identities that slot into your existing Conditional Access policies and identity governance workflows.
It was a reasonable answer to a real problem. What nobody counted on was that the very administrative role designed to manage those agent identities had a scope gap wide enough to hand an attacker the keys to your entire tenant. That role: the Agent ID Administrator.
Microsoft patched the issue on April 9, 2026. If you haven’t audited who holds that role in your tenant, now is the time.
What Entra Agent ID Is and Why It Exists
Microsoft Entra Agent ID is an identity framework for AI agents, currently in public preview. The core problem it solves is agent sprawl: organizations deploying Copilot agents, custom Azure AI agents, and third-party agentic tools end up with dozens or hundreds of nonhuman identities that need to access Microsoft Graph, SharePoint, Exchange, and other enterprise resources.
Before Entra Agent ID, the common pattern was to register these agents as regular app registrations (essentially service principals) and manage credentials manually. That approach doesn’t scale, doesn’t give you meaningful audit trails specific to AI agents, and makes it nearly impossible to enforce least-privilege consistently across a fleet of autonomous systems.
Entra Agent ID introduces two core constructs:
Agent Identity is the primary account an AI agent uses to authenticate. Like a service principal, it has an object ID and app ID. Unlike a regular service principal, it’s tied to an agent-specific lifecycle and governed through Entra Agent ID’s management plane.
Blueprint is a template that defines an agent’s identity configuration, including federated identity credentials (FIC). The blueprint holds credentials and issues tokens on behalf of agent identities that derive from it.
The framework hooks into the same Conditional Access, Identity Protection, and identity governance infrastructure you already use. In theory, it means you can apply the same Zero Trust controls to AI agents that you apply to human users: require compliant devices, block risky sign-ins, enforce access reviews.
In practice, it means you’re introducing a new administrative role with real power.
The Agent ID Administrator Role and Its Unintended Reach
Microsoft created a dedicated directory role for managing Entra Agent ID objects: the Agent ID Administrator. The role was documented as scoped to agent-specific objects (Blueprints and Agent Identities) with no stated authority over regular application service principals.
That scoping was incorrect.
Silverfort, an identity protection firm, discovered in late February 2026 that the Agent ID Administrator role could modify the owners of any Application Service Principal in the tenant. Not just agent-related ones. This wasn’t a theoretical edge case. Any user assigned to the Agent ID Administrator role could:
- Add themselves (or an attacker-controlled account) as an owner of an unrelated service principal
- Attach new credentials to that service principal
- Authenticate as the application and operate within all of its existing permissions
The blast radius of this depends entirely on what service principals exist in your tenant and what permissions they hold. In most enterprise environments, this is very bad. If any service principal holds privileged Microsoft Graph permissions like RoleManagement.ReadWrite.Directory, Directory.ReadWrite.All, or Application.ReadWrite.All, an attacker with Agent ID Administrator access could effectively achieve Global Admin equivalence.
Silverfort’s data on this is worth sitting with: approximately 99% of enterprise tenants contain at least one privileged service principal. More than half of tenants with agent identities average around 100 agent identities per tenant. The attack surface was not small.
How the Attack Chain Works
The mechanics are worth understanding in detail, because the same class of scope gap could appear in other new roles Microsoft introduces as the agentic AI platform matures.
Step 1: Assign the role to a low-privilege account
An attacker who can assign directory roles (or who compromises an account with that capability) assigns Agent ID Administrator to a target account. The role was positioned as an operational role for AI agent management, not a sensitive privileged role. This means it may have been assigned more freely than Global Admin or Privileged Role Administrator.
Step 2: Enumerate service principals
Using the effective permissions of the Agent ID Administrator role, the attacker enumerates existing service principals in the tenant. The goal is finding ones with high-impact Microsoft Graph permissions or privileged directory role assignments.
Step 3: Take ownership
The attacker adds their account as an owner of the targeted service principal. Service principal owners can manage credentials and configuration for that principal.
Step 4: Add credentials and authenticate
With ownership established, the attacker adds a client secret or certificate to the service principal. They then authenticate as the application using those credentials.
Step 5: Operate at the service principal’s permission level
Now the attacker is operating with whatever access the service principal had. If it held RoleManagement.ReadWrite.Directory, they can assign any directory role to any account. If it held privileged Exchange or SharePoint permissions, they have data access. The tenant is effectively compromised.
Timeline and Patch Details
The responsible disclosure process here was by-the-book:
- February 24, 2026: Silverfort discovers the Agent ID Administrator scope overreach
- March 1, 2026: Silverfort reports the issue to Microsoft Security Response Center (MSRC)
- March 26, 2026: Microsoft confirms the vulnerability
- April 9, 2026: Microsoft rolls out a full fix to all cloud environments
The fix is specific: the Agent ID Administrator role is now blocked from managing the owners of regular, non-agent Service Principals. The role retains its intended scope. It can still manage Blueprints and Agent Identities. But the lateral movement path through service principal ownership is now closed.
No CVE was published at the time of writing. Microsoft typically handles Entra-side identity control issues through service-side fixes rather than CVE assignment, particularly when no customer action is required to patch.
What You Should Audit Right Now
Even though the platform-side fix is deployed, there are several things worth verifying in your environment.
Check who holds the Agent ID Administrator role
In the Entra admin center, go to Roles and administrators and search for Agent ID Administrator. Review every assignment. If accounts were assigned this role during the window between the role’s introduction and April 9, audit their activity logs.
# List all users with Agent ID Administrator role
Get-MgDirectoryRole | Where-Object { $_.DisplayName -eq "Agent ID Administrator" } |
ForEach-Object {
Get-MgDirectoryRoleMember -DirectoryRoleId $_.Id |
Select-Object Id, DisplayName, UserPrincipalName
}Review service principal ownership changes from the risk window
If you have Microsoft Entra audit logs retained (they’re available in the Entra admin center under Monitoring → Audit logs), filter for Update servicePrincipal and Add owner to servicePrincipal events between roughly December 2025 and April 9, 2026. Look for any unusual ownership additions, particularly on service principals with broad Graph permissions.
Inventory your privileged service principals
Run a review of service principals that hold any of the following Graph application permissions: RoleManagement.ReadWrite.Directory, Directory.ReadWrite.All, Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All. These are the principals that would have been highest-value targets. Verify their owners are correct and their credentials haven’t been tampered with.
# Get service principals with high-impact app role assignments
Get-MgServicePrincipal -All | ForEach-Object {
$sp = $_
$roles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id
if ($roles.PrincipalId) {
[PSCustomObject]@{
Name = $sp.DisplayName
AppId = $sp.AppId
Roles = ($roles | Select-Object -ExpandProperty ResourceDisplayName) -join ", "
}
}
}Apply Conditional Access to agent identities
If you’re actively using Entra Agent ID, now is a good time to scope Conditional Access policies explicitly to agent identities. Microsoft’s documentation outlines how to create workload identity Conditional Access policies. These can enforce sign-in risk thresholds and restrict authentication to known IP ranges for your agent workloads.
The Broader Lesson for AI Agent Deployments
This vulnerability is a preview of the category of issues that will emerge as platforms rush to build identity infrastructure for AI agents. The Agent ID framework is new. The administrative roles are new. The mental models for how agents differ from traditional service principals are still being worked out across Microsoft engineering, security teams, and the research community.
A few things to build into your AI agent security posture now:
Treat agent administrative roles as sensitive from day one. The Agent ID Administrator role should have been classified as a privileged role the moment it could affect any service principal. Apply the same scrutiny you’d apply to Application Administrator or Cloud Application Administrator assignments.
Audit nonhuman identities on the same cadence as human identities. Access reviews in Entra Identity Governance can be scoped to service principals and, going forward, to agent identities. Schedule quarterly reviews and assign clear ownership for every agent identity in your tenant.
Prefer federated credentials over client secrets for agent authentication. Federated Identity Credentials don’t produce extractable secrets. If an Agent ID Administrator could take ownership of an agent identity and issue tokens on its behalf, the blast radius is lower when there’s no persistent secret to steal.
Monitor for service principal ownership changes continuously. Tools like Microsoft Sentinel or Defender for Identity can alert on unexpected ownership changes to service principals. This is a high-fidelity signal. Legitimate principals rarely change owners.
Where Entra Agent ID Goes from Here
The platform remains in preview, and the patch demonstrates that Microsoft is responding to security research. That’s the right signal. But preview status also means the permission model, the role definitions, and the trust boundaries are all subject to change. Not every change will come with a security advisory.
If you’re building on Entra Agent ID now, follow the Microsoft Entra release notes, subscribe to MSRC security advisories filtered by Entra, and keep a close watch on any new roles the platform introduces. The identity layer for AI agents is being built in public, which means the security community will find issues. Make sure you hear about them before attackers do.
Summary
The Agent ID Administrator scope flaw is a reminder that new platforms introduce new attack surfaces, and that “scoped to agent objects” is only as trustworthy as the enforcement behind it. Microsoft’s patch closed the specific path Silverfort found. The broader question your security team should be asking every time a new AI identity capability rolls out: how much do you trust the permission model of a platform still in preview?
The fix is in. The audit work isn’t finished.