Microsoft Patches Entra ID Role Flaw Enabling Service Principal Takeover

Silverfort’s identity threat research team disclosed a critical misconfiguration in a Microsoft Entra ID administrative role designed for AI agents. The role, named “AI Service Administrator,” was granted an over‑broad set of permissions—including Microsoft.Graph/Application.ReadWrite.All, Directory.ReadWrite.All, and RoleManagement.ReadWrite.Directory—that allowed any service principal assigned the role to modify directory objects, create or modify app registrations, and elevate its own privileges without additional approval.

Technically, the flaw enabled a service principal to add itself to privileged security groups (e.g., Global Administrator) and to request access tokens for high‑privilege Microsoft Graph endpoints. By issuing a POST request to https://graph.microsoft.com/v1.0/servicePrincipals/{id}/appRoleAssignments, an attacker could assign arbitrary app roles, and by leveraging the RoleManagement.ReadWrite.Directory permission, they could grant the principal a permanent role assignment. This chain of actions provided a pathway to cross‑tenant service‑principal takeover and long‑term persistence within an Azure AD environment.

Microsoft confirmed the issue after a responsible disclosure in October 2024 and deployed a fix on 10 December 2024. The “AI Service Administrator” role was removed from the Entra ID role catalogue, and a new, read‑only “AI Reader” role was introduced with only the permissions required for AI workloads. Conditional Access policies were updated to enforce MFA and a time‑limited activation window for any role that can modify directory settings, while Microsoft’s Secure Score recommendations now flag any lingering assignments of the deprecated role.

Organizations should audit their Entra ID role assignments, revoke any lingering “AI Service Administrator” assignments, and enable Privileged Identity Management (PIM) for roles that grant write‑level directory access. Continuous monitoring of sign‑in and audit logs for anomalous service‑principal activity—especially role assignment changes and token requests to high‑privilege Graph endpoints—is recommended to detect potential exploitation attempts before they achieve persistence.