The Role That Said 'Agent Only' and Meant 'Everything'

April 30, 2026•11 min read

entra-idmicrosoftiamservice-principalprivilege-escalationidentity-governancezero-trustnon-human-identity

The Role That Said "Agent Only" and Meant "Everything"

Here's a scenario I've seen destabilize more than one identity program: a new role gets introduced, it sounds narrowly scoped, someone assigns it because the name sounds safe, and it turns out the scope was broader than anyone realized. Usually it's a SailPoint workgroup assignment gone wrong, or a resource group RBAC role with more permissions than the documentation implied. This time, it's Microsoft Entra ID at the tenant level, and the blast radius is service principal takeover.

In April 2026, Microsoft patched a vulnerability in the Agent ID Administrator role—a privileged built-in role introduced as part of Microsoft Entra Agent ID, their new AI agent identity platform. The flaw: the role wasn't scoped to agent identities at all. Any user assigned Agent ID Administrator could take ownership of arbitrary service principals across the tenant, inject credentials, and authenticate as that principal. If the target SP held AppRoleAssignment.ReadWrite.All, RoleManagement.ReadWrite.Directory, or similar high-impact Graph permissions, the chain ended at Global Administrator.

Silverfort discovered the flaw on February 24, 2026, reported it to Microsoft MSRC on March 1, Microsoft confirmed it March 26, and the patch rolled out April 9. The vulnerability existed in every Microsoft cloud environment until that date.

Responsible Disclosure Timeline

This post covers the technical mechanics, why it worked, and what IAM engineers running Microsoft identity stacks need to do in response—even after the patch.

What Is Microsoft Entra Agent ID?

Microsoft Entra Agent ID is a recently introduced identity and authorization framework for AI agents. The core idea is that AI agents—autonomous software capable of accessing resources, calling APIs, and performing actions on behalf of users—need their own first-class identities rather than borrowing user credentials or reusing service accounts.

The framework introduces four new object types: agent identity blueprints, agent identity blueprint principals, agent identities, and agent users. When created, an agent identity inherits limited OAuth 2.0 delegated permission scopes from its parent blueprint, and many highly privileged directory roles—Global Administrator, Privileged Role Administrator, User Administrator—are explicitly blocked from being assigned to agent identities.

Two roles manage this new plane: Agent ID Developer (creates blueprints and agent identities) and Agent ID Administrator (handles all aspects of agent identity lifecycle operations in a tenant, including credential management and ownership).

On paper, this is a reasonable architecture. In practice, the role enforcement had a gap that turned Agent ID Administrator into a skeleton key.

The Attack Chain

Silverfort's discovery hinged on a fundamental question: what objects can the Agent ID Administrator role actually modify?

The intended answer: agent-related objects. Blueprints, agent identity principals, agent users.

The actual answer: nearly any application service principal in the tenant.

The attack sequence looks like this:

Attack Chain: Agent ID Administrator to Global Admin

Step 1 — Enumerate. Using the Microsoft Graph API or Azure CLI, a user with Agent ID Administrator queries the tenant for service principals and identifies candidates with elevated permissions—specifically those holding high-value Graph app roles like AppRoleAssignment.ReadWrite.All, RoleManagement.ReadWrite.Directory, or Directory.ReadWrite.All.

Step 2 — Claim ownership. The attacker uses the Agent ID Administrator role to assign themselves as an owner of the target service principal. This should have been restricted to agent-backed service principals. It wasn't.

Step 3 — Inject a credential. As an owner, the attacker adds a new password or certificate credential to the service principal. The original credentials remain in place—no disruption to existing workloads, no alerting on failed authentications.

Step 4 — Authenticate as the SP. The attacker authenticates against Entra ID as the service principal using the injected credential, inheriting all permissions that principal held.

If that principal had RoleManagement.ReadWrite.Directory, the attacker now controls directory role assignments—full Global Administrator equivalent, no MFA required, no Conditional Access applied.

The phrase Silverfort used is accurate: ownership is a takeover primitive. Become an owner of a service principal, and credential injection is trivial. The step that should have been gated—assigning ownership outside of agent scope—wasn't.

Why Almost Every Tenant Was Exposed

Silverfort's data puts 99% of tenants with at least one privileged service principal. That number should not be surprising to anyone who has done a Entra ID governance engagement. Service principals proliferate in enterprise environments:

First-party Microsoft applications (many carry high-impact Graph permissions by design)
Third-party SaaS integrations requesting broad permissions to operate
Automation accounts and custom-built tooling that inherited permissions over time without cleanup
CI/CD systems granted cloud resource management rights

In the environments I've worked in—financial services, aerospace, federal contractors—service principals with Application.ReadWrite.All or Directory.ReadWrite.All are rarely reviewed with the same rigor as human administrator accounts. They're not subject to access certification campaigns. They don't age out. Their owners are often a departed engineer or a distribution list that nobody monitors.

The identity governance gap for non-human identities is real and well-documented. CyberArk's 2025 Identity Security Threat Landscape report estimated machine identities outnumber human identities at an 82:1 ratio in enterprise environments. NIST's National Cybersecurity Center of Excellence, in their February 2026 concept paper on software and AI agent identity, called this out directly: most IAM programs treat service principals like ordinary service accounts and miss what makes them different—autonomy, dynamic permissions, and the absence of behavioral monitoring that would flag unusual activity on a human account.

The Agent ID Administrator vulnerability landed squarely on this gap.

The Root Cause: Object Schema Inheritance and Missing Type Gates

The reason this flaw existed at all is architectural.

Root Cause: Object Schema Inheritance and Missing Type Gates

In Entra ID, both agent identities and standard service principals share the same core object schema in Azure AD: identifiers, display names, owner slots, and credential fields. Agent identities—particularly those backed by service principals—live in the same object plane as non-agent service principals.

When Microsoft implemented the Agent ID Administrator role, the permission checks for ownership assignment and credential management didn't strictly validate whether the target object was agent-backed or not. The role check passed for any service principal object, because the object type discrimination wasn't enforced at that layer.

This is a classic scoping gap when one object type inherits from or shares a schema with another. The role was built to manage a subset of service principals, but the enforcement code validated against the parent type rather than the intended subtype. The result: permissions intended for agent-scoped operations leaked onto the entire service principal plane.

The AI agent framework itself—the blueprint model, the permission inheritance, the blocked high-privilege roles—wasn't the flaw. The flaw was in the role definition's scope enforcement, not the agent identity model. The remediation is surgical: post-patch, the Agent ID Administrator role returns a Forbidden error on any ownership operation targeting a non-agent service principal.

There's a secondary issue Silverfort flagged: Entra's UI was not labeling Agent ID Administrator as a privileged role, despite Microsoft's own documentation classifying it that way. That's a gap in visibility that increased the likelihood of careless assignment. Microsoft has committed to correcting that indicator.

What IAM Engineers Need to Do

The patch is live. But patching a privilege escalation bug doesn't undo what may have already happened, and it doesn't solve the underlying governance debt that made this exploitable in the first place.

Audit Agent ID Administrator assignments immediately. The role is new—introduced with the Entra Agent ID platform. If anyone in your tenant holds this assignment, understand why and whether it's still necessary. This is not a role that should have broad assignment.

# List current Agent ID Administrator role members (Microsoft Graph PowerShell)
$role = Get-MgDirectoryRole -Filter "displayName eq 'Agent ID Administrator'"
Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id | Select-Object Id, DisplayName, UserPrincipalName

Or via Graph API directly:

GET https://graph.microsoft.com/v1.0/directoryRoles?$filter=displayName eq 'Agent ID Administrator'
GET https://graph.microsoft.com/v1.0/directoryRoles/{roleId}/members

Review AuditLogs for suspicious ownership changes. Specifically, look for service principal ownership changes that occurred between the role's introduction and April 9, 2026. Changes that assigned a human user as owner of a service principal they have no legitimate relationship to are the signal.

In the Entra portal: Monitoring → Audit logs → Activity: Add owner to service principal. Filter for the window prior to the patch. Cross-reference assigned owners against expected ownership mappings.

Inventory privileged service principals and their owners. This should already be part of your non-human identity governance posture, but if it isn't, this vulnerability is a good forcing function. For each service principal holding a dangerous permission scope, document:

Current owners (human accounts and other SPs)
Last credential rotation date
Last sign-in activity
Whether the permissions are still scoped appropriately

The dangerous permission tiers, ordered by escalation potential:

Permission	Escalation Path
`RoleManagement.ReadWrite.Directory`	Direct Global Admin escalation
`AppRoleAssignment.ReadWrite.All`	Self-grant any permission
`Application.ReadWrite.All`	Pivot to other app registrations
`Directory.ReadWrite.All`	Broad object modification

Treat credential additions on service principals as high-severity events. A new password or certificate appearing on a privileged service principal is a takeover signal. Your SIEM should alert on Add service principal credentials in AuditLogs, scoped to SPs with the permission tiers above.

Review how Agent ID Administrator is used in your provisioning workflows. If you're using SailPoint ISC, Microsoft Entra ID connectors, or any IGA tool that manages role assignments, verify that this role isn't being provisioned through automated workflows without appropriate approval gates.

The Pattern You'll See Again

This vulnerability is a preview of a problem the industry hasn't fully solved yet. Every time a major platform introduces a new identity type—AI agents, workload identities, managed identities, device identities—they introduce new object schemas, new roles, and new permission enforcement logic. The scope gaps appear at the boundaries between old and new.

NIST launched its AI Agent Standards Initiative in February 2026 specifically because existing frameworks—including SP 800-53—lack purpose-built controls for agentic systems. The Access Control, Identification and Authentication, and Audit and Accountability control families weren't written with autonomous software identities in mind. Forrester's 2026 predictions flagged that an agentic AI deployment is likely to cause a public data breach before year-end—a claim that looks less like hyperbole after this disclosure.

The Agent ID Administrator flaw was caught by a security researcher before it was weaponized at scale—as far as public disclosure indicates. The next one may not be. AI agent frameworks are being built and expanded rapidly, under competitive pressure, with identity as an afterthought to capability.

IAM engineers need to stay skeptical of new role types introduced alongside new platform features. The name of a role tells you what its designers intended. It doesn't tell you what it actually does. Reviewing role permissions in the Microsoft Entra built-in roles documentation—specifically the allowedResourceActions fields—before assigning any new privileged role is not optional. It's table stakes for identity governance in this environment.

The patch closes the door. It doesn't clean the house. If this role was assigned in your tenant between its introduction and April 9, 2026, your audit logs may still contain ownership changes you haven't examined. Machine identities don't go through the Joiner/Mover/Leaver lifecycle, don't age out of access certifications, and don't trigger behavioral alerts when their credential set quietly grows by one. That's precisely why attackers are targeting them—and why this won't be the last time a new identity type ships with a scope gap that defenders weren't watching for.