What Happened
Microsoft's Entra ID (formerly Azure AD) had a role misconfiguration that allowed the "Agent ID Administrator" role to escalate privileges beyond its intended scope. Designed to manage authentication agent identities, this role could be exploited to take ownership of privileged service principals across an entire tenant, effectively granting an attacker control over your identity infrastructure.
Silverfort researchers discovered the flaw, and Microsoft patched it by April 9, 2026.
The core issue was that the Agent ID Administrator role could claim ownership over service principals unrelated to authentication agents. Since 99% of tenants have at least one privileged service principal, this misconfiguration created a universal escalation path in nearly every Entra ID deployment.
Timeline
Discovery Phase
Silverfort researchers found that the Agent ID Administrator role's permissions extended beyond agent-related identities to arbitrary service principals within the tenant.
Disclosure
The vulnerability was reported to Microsoft through responsible disclosure channels.
Patch
Microsoft resolved the scope enforcement issue by April 9, 2026, restricting the role to its intended function.
Which Controls Failed or Were Missing
1. Least Privilege Enforcement
The Agent ID Administrator role violated the principle of least privilege. It was granted ownership permissions over service principals outside its operational scope. Your role definitions should never include unnecessary permissions—every capability must map to a specific, documented job function.
2. Scope Validation
The role lacked proper scope boundaries. When creating a custom role or evaluating a built-in role, you need technical controls that prevent the role from accessing resources outside its designated domain. This wasn't a documentation problem—it was a missing enforcement mechanism.
3. Service Principal Inventory and Classification
Most organizations don't maintain an accurate inventory of their service principals, let alone classify them by privilege level. Without this visibility, you can't detect when a low-privilege role suddenly gains ownership of a high-privilege identity.
4. Privilege Change Detection
The attack path required taking ownership of a service principal. Your monitoring should flag ownership changes on privileged identities immediately. If your SIEM or identity governance tool doesn't alert on this, you're missing a critical signal.
What the Relevant Standards Require
ISO/IEC 27001:2022
Control 8.2 (Privileged access rights) requires organizations to restrict and control privileged access rights. The control explicitly calls for:
- Allocation of privileged access rights based on the principle of least privilege
- Regular review of privileged access rights
- Procedures to prevent misuse of privileged access rights
The Agent ID Administrator flaw violated all three requirements. The role had excessive privileges, and the scope creep went undetected.
Control 8.3 (Information access restriction) mandates that access to information and systems be restricted according to the access control policy. Service principals are system identities—they require the same access restrictions as human users.
NIST 800-53 Rev 5
AC-2 (Account Management) requires organizations to define authorized users, group and role membership, and access authorizations for each account. The control includes:
- AC-2(7): Role-based schemes that enforce privilege separation
- AC-2(12): Account monitoring for atypical usage
Microsoft's role definition failed AC-2(7) by not enforcing separation between agent management and general service principal administration. Your monitoring should have caught the first ownership change under AC-2(12).
AC-6 (Least Privilege) states that each user and process should operate with the minimum set of privileges necessary. AC-6(5) specifically addresses privileged accounts and requires organizations to restrict privileged accounts to specific personnel or roles.
NIST Cybersecurity Framework v2.0
PR.AC-4 (Access permissions and authorizations are managed) requires you to incorporate the principle of least privilege and separation of duties. Your identity platform must enforce these principles at the technical level, not just document them in policy.
Lessons and Action Items for Your Team
1. Audit Your Entra ID Role Assignments
Run this check today:
- List all custom roles and their permissions
- For each built-in role, verify the actual permissions match Microsoft's current documentation
- Identify every assignment of the Global Administrator, Privileged Role Administrator, and any role that can modify other roles
- Document which service principals have privileged roles assigned
If you can't generate this list in under an hour, your identity governance tooling is inadequate.
2. Implement Service Principal Classification
Create a tiering system for your service principals:
Tier 0: Can modify identity infrastructure, access all data, or deploy code to production
Tier 1: Can access sensitive data or modify business-critical systems
Tier 2: Limited access to non-sensitive resources
Tag each service principal with its tier. Configure alerts for any role assignment or ownership change affecting Tier 0 or Tier 1 principals.
3. Enable Privileged Identity Management (PIM)
If you're not using PIM for administrative roles, you're accepting unnecessary risk. PIM provides:
- Time-bound role assignments
- Approval workflows for role activation
- Audit logs for every privilege elevation
Configure PIM for any role that can modify identity configurations or access sensitive data. The Agent ID Administrator attack required persistent ownership—PIM would have limited the exposure window.
4. Monitor Ownership Changes
Add this detection rule to your SIEM:
Alert when:
- Any service principal ownership changes
- Any role assignment is modified
- Any service principal is granted a privileged role
Filter out:
- Changes by approved automation accounts
- Changes during approved maintenance windows
You need to know within minutes when a privilege boundary shifts.
5. Review Your Custom Roles
If you've created custom roles in Entra ID, audit them against these criteria:
- Does the role name accurately describe its scope?
- Can you justify every permission in the role?
- Have you tested what happens if this role is compromised?
- Does the role include permissions to modify other identities or roles?
If your custom role includes microsoft.directory/servicePrincipals/owners/update, you need to restrict its scope to specific service principals, not the entire directory.
6. Test Your Privilege Escalation Paths
Assume an attacker compromises a low-privilege service account. Map every possible escalation path:
- Which roles can this account be assigned?
- Which service principals can this account modify?
- What permissions do those service principals have?
Use tools like ROADtools or AADInternals to enumerate these paths. If you discover an escalation path you didn't expect, you have a control gap.
The Agent ID Administrator flaw wasn't exotic. It was a scope enforcement failure in a role definition—the kind of misconfiguration that exists in thousands of identity platforms right now. The difference is whether you find it first or an attacker does.
