Validated Research Published: Apr 29, 2026

Entra Agent ID Administrator Scope Gap: Agent Roles Reaching Service Principals

Silverfort found that Microsoft Entra's Agent ID Administrator role (an agent-management role in Microsoft's identity platform) could add owners to arbitrary non-agent service principals. Once owner, an attacker could add credentials and authenticate as that principal, turning an agent-management role into a takeover path. Microsoft fixed the issue across clouds by April 9, 2026.

The lesson is broader than one preview-role bug: every new AI-agent role must be tested against the real directory objects and actions it can reach.

Privilege EscalationService Principal TakeoverIdentity & AccessEntra IDService Principals
9 applicable AIDEFEND defenses
Source: Agent ID Administrator scope overreach: Service Principal takeover in Entra ID 
Author: Noa Ariel (Silverfort)
Original article: Apr 23, 2026

Threat Analysis

  • Agent identity reused the service-principal foundation. Entra Agent ID adds blueprints, agent identities, and agent users, but agent identities still sit on familiar Entra application and service-principal objects.
  • The role said 'agent objects,' but enforcement reached broader service principals. Agent ID Administrator was documented as scoped to agent-related objects, yet Silverfort showed it could add an owner to non-agent service principals.
  • Ownership became a takeover primitive. After becoming owner, the researcher could add credentials and authenticate as the target principal. If that principal held privileged directory roles or high-impact Graph permissions, the result became privilege escalation.
  • UI risk labeling mattered. Silverfort noted that the role was documented as privileged, but the Entra UI did not show it that way. That mismatch can reduce review for a role that affects service-principal ownership.
  • The fix closes this path, but the pattern remains important. Microsoft blocked Agent ID Administrator from managing non-agent service-principal owners. The durable lesson is to validate new AI identity roles against inherited object types, not just documentation.

Applicable AIDEFEND Defenses (9)

AID-M-009.003
Agent Identity, Delegation Lineage & Authorization Context
Very High
This is the strongest identity-context fit because the failure sits between an AI agent role and the directory identities it can affect. Preserve who assigned the role, the target agent object or service principal, original authority, delegated scope, and exact owner-assignment action; AID-H-018.002 consumes that context and owns the pre-effect authorization decision.
AID-H-018.002
Policy-Based Access Control
Very High
The core failure was an authorization policy that did not enforce the documented resource boundary. A policy engine should evaluate the actor role, target object type, target subtype, requested operation, and current tenant context: Agent ID Administrator may update owners on agent-backed service principals, but must fail closed on non-agent service principals.
AID-H-018.006
Continuous Authorization Verification (Anti-TOCTOU)
High
The attack chain has two sensitive steps: become owner, then add credentials. Both must be authorized at execution time, not inferred from an earlier role check. Even if a user can manage agent identities, the system should re-check the target service principal type and effective permissions before owner changes, credential creation, and sign-in as that principal.
AID-H-004.001
User & Privileged Access Management
High
Agent ID Administrator is a human-assignable administrative role. It should be treated with privileged-role hygiene: approval workflow, eligible assignment instead of standing access, step-up authentication, periodic access review, and explicit inventory of which administrators can manage agent identities.
AID-E-001.003
AI Agent & Workload Principal and Issuance Disablement
High
If a service principal was taken over through this path, disable that exact compromised agent or workload principal at every authoritative identity, federation, and authorization plane and deny every fresh credential or token issuance path. Removing the attacker-added secret alone is insufficient if the principal can mint replacement access; already-issued tokens and delegated grants remain AID-E-001.002 and AID-E-001.004.
AID-E-001.004
Delegated Grant & Connected-App Authorization Revocation
High
After an attacker becomes owner or administrator of a service principal or app registration, incident response must enumerate and revoke delegated OAuth grants, connected-app consents, app-role assignments, and SaaS application grants that could keep access alive after ordinary token or secret rotation. This complements foundational credential cleanup rather than replacing it.
AID-D-011.004
Non-Human Identity & Delegated Token Abuse Detection
Medium
Non-human identity and delegated-token abuse detection is the precise telemetry for this takeover: correlate service-principal credential issuance, exchange, and refresh with subsequent sign-ins, so that a new secret or certificate added to a privileged service principal - followed by authentication whose client, scope, or workload is inconsistent with policy - raises a high-risk identity alert.
AID-D-005.004
Specialized Agent & Session Logging
Medium
Investigation requires a trace that joins role assignment, Graph API call, target service principal, owner addition, credential creation, and subsequent authentication. Agent identity control-plane logs should preserve those correlation IDs so responders can prove whether the action stayed within the agent identity plane or crossed into general service-principal administration.
AID-E-001.001
Root & Long-Lived Credential Object Eviction
Medium
If this pattern is found, remove the exact unauthorized service-principal secrets or certificates and rotate every affected root or long-lived credential object at its authoritative issuer. Tokens or sessions already issued through those credentials require AID-E-001.002; this control does not claim that separate result.

What Defenders Should Do Now

  • Confirm that Microsoft's fix is applied in the relevant Entra cloud and tenant, then inventory every assignment of Agent ID Administrator and similar agent-identity roles. Treat them as privileged even if the UI does not label them that way.
  • Audit service principals with privileged directory roles or high-impact Microsoft Graph permissions. Prioritize those with recent owner additions or credential changes.
  • Alert on any Agent ID Administrator account adding owners or credentials to non-agent service principals. The expected target class should be agent-related identities only.
  • Review service-principal credential creation. New secrets or certificates on privileged service principals should require approval, ticket linkage, and rapid investigation when created outside deployment workflows.
  • Correlate role assignment, owner change, credential creation, and subsequent sign-in events into one identity-security timeline. A takeover is easy to miss when those events are viewed separately.
  • For every new AI-agent identity feature, test the documented role scope against the underlying directory primitives it inherits from. Do not assume the product name and the effective permission boundary are the same thing.

1 additional consideration

Directory-role simulation for new AI identity features

Beyond the techniques mapped above, teams adopting preview AI identity features should simulate what each new role can actually do across inherited directory object types before assigning it broadly.
Recommendation: Build a pre-adoption test harness that exercises every new AI-agent role against agent objects, non-agent service principals, applications, managed identities, credentials, app role assignments, and owner changes; treat unexpected allow results as blockers before rollout.

Conclusion

The Silverfort finding is a sharp example of why AI agent identity governance has to reach below the marketing object names. Entra Agent ID creates new agent-facing concepts, but those concepts still inherit behavior from applications, service principals, owners, credentials, and Microsoft Graph permissions. AIDEFEND  maps this case to agent identity lineage, policy-based authorization, continuous authorization checks, privileged access management, service authentication, drift detection, forensic logging, and credential cleanup. The practical lesson is simple: every agent role needs a tested resource boundary, and every owner or credential change on a privileged service principal should be treated as a high-risk identity event.