A critical scope overreach vulnerability was recently identified in the Microsoft Entra Agent Identity Platform. The newly introduced Agent ID Administrator role allowed accounts to hijack arbitrary service principals and escalate privileges across the entire tenant.
Microsoft has fully patched this behavior across all cloud environments as of April 2026.
How the Permission Boundary Breaks
The Microsoft Agent Identity Platform is a preview feature that provides artificial intelligence agents with identities using blueprints, agent identities, and agent users.
To manage these non-human entities, Microsoft introduced the Agent ID Administrator role. According to Microsoft documentation, this role was strictly scoped to manage only agent-related objects.
However, because agent identities are built on top of standard application and service principal primitives, a critical scoping gap emerged.
Silverfort researchers found that actions like updating agent identity owners allowed administrators to modify the 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 research, organizations should proactively identify service principals with admin-level directory roles and secure them appropriately.
Administrators can utilize the Azure CLI alongside 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 "SP_NAMEtSP_IDtROLE"
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.
Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.
