Hackers Hijack Service Principals via Entra Agent Abuse Administrator

The Microsoft Entra Agent Identity Platform is at the center of a recently identified critical scope overreach vulnerability. This flaw stems from the newly introduced Agent ID Administrator role, enabling accounts to hijack arbitrary service principals and escalate privileges across an 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.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.