Entra ID Admin Role Could Let Hackers Hijack Service Principals
▼ Summary
– A critical scope overreach vulnerability in the Microsoft Entra Agent Identity Platform allowed the Agent ID Administrator role to hijack arbitrary service principals and escalate privileges across the entire tenant.
– Microsoft fully patched this vulnerability across all cloud environments as of April 2026.
– The flaw arose because agent identities are built on standard service principal primitives, enabling users with the Agent ID Administrator role to assign themselves ownership of any unrelated, high-privileged service principal.
– Once ownership was obtained, attackers could generate new credentials, authenticate as the targeted application, and potentially achieve full environment compromise.
– Security teams must monitor audit logs for suspicious owner or credential additions to service principals and treat privileged service principals as critical infrastructure.
A serious privilege escalation flaw in Microsoft’s Entra ID was recently uncovered, exposing a dangerous loophole in the Agent Identity Platform. The newly introduced Agent ID Administrator role could be exploited to hijack arbitrary service principals, granting attackers the ability to escalate privileges across an entire tenant. Microsoft has fully patched this vulnerability as of April 2026, closing the gap in all cloud environments.
The permission boundary issue stemmed from the design of the Agent Identity Platform, a preview feature that assigns AI agents identities through blueprints, agent identities, and agent users. To manage these non-human entities, Microsoft created the Agent ID Administrator role, which documentation stated was strictly limited to agent-related objects. However, because agent identities are built on standard application and service principal primitives, a critical scoping gap emerged.
Researchers at Silverfort discovered that actions such as updating agent identity owners allowed administrators to modify ownership of any service principal in the tenant. A user with the Agent ID Administrator role could assign themselves as the owner of a completely unrelated, high-privileged service principal. Once ownership was established, the attacker could generate new credentials and authenticate as that targeted application. If the compromised service principal held elevated directory roles or high-impact Graph API permissions, this takeover primitive provided a direct path to full compromise of the environment.
Attackers leveraging this vulnerability would naturally target the most powerful non-human identities in a network. According to Silverfort, organizations should proactively identify service principals with admin-level directory roles and secure them appropriately. Administrators can use Azure CLI with jq to query the Microsoft Graph API for these vulnerable configurations. The following script discovers service principals with privileged directory roles:
“` BASE=”https://graph.microsoft.com” roles=”$(az rest -m GET –url “${BASE}/beta/roleManagement/directory/roleDefinitions?\$filter=isPrivileged eq true&\$select=id,displayName” -o json)” u=”${BASE}/beta/roleManagement/directory/roleAssignments?\$expand=principal(\$select=id,displayName)&\$top=999″ { echo -e “SPNAME\tSPID\tROLE” echo -e “——–\t——\t—-” while :; do j=”$(az rest -m GET –url “$u” -o json 2>/dev/null)” || break jq -r –argjson roles “$roles” ‘ ($roles.value | map(select(.displayName|test(“Reader”;”i”)|not) | {key:.id, value:.displayName}) | from_entries) as $r | .value[] | select(.principal.”@odata.type”==”#microsoft.graph.servicePrincipal”) | select($r[.roleDefinitionId] != null) | [.principal.displayName, (.principal.id // .principalId), $r[.roleDefinitionId]] | @tsv ‘ <<<"$j" u="$(jq -r '."@odata.nextLink"//empty' <<<"$j")" [[ -z "$u" ]] && break done | sort -t$'\t' -k1,1 } | column -t -s $'\t' ```
Microsoft acknowledged the issue and deployed a fix that prevents the Agent ID Administrator role from managing the owners of non-agent service principals. While the immediate threat is resolved, the underlying risk of service principal ownership abuse remains a high-value attack path. Security teams must actively monitor their audit logs for successful events involving the addition of owners or credentials to service principals. Because many tenants contain at least one privileged service principal, treating these identities as critical infrastructure is essential to preventing future privilege escalation attacks.
(Source: Cybersecuritynews.com)
