Blog Published: Apr 29, 2026

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

Silverfort found that Microsoft's Agent ID Administrator role 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
8 applicable AIDEFEND defenses
Source: Agent ID Administrator scope overreach: Service Principal takeover in Entra ID 
By 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 (8)

AID-M-009.003
Agent Identity, Delegation Lineage & Runtime Authorization
Very High
This is the strongest fit because the failure sits at the boundary between an AI agent identity role and the directory identities it can affect. Agent identity governance needs to preserve who assigned the role, which agent object or service principal was targeted, what delegated scope was intended, and whether the action stayed inside that scope before any side effect such as owner assignment occurs.
AID-H-019.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-019.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-H-004.002
Service & API Authentication
High
Service-principal takeover becomes useful only after the attacker adds credentials and authenticates as the application identity. Service and API authentication controls should restrict who can create secrets or certificates, prefer short-lived or federated credentials, alert on new credentials for privileged service principals, and remove long-lived credentials where possible.
AID-D-004.003
Runtime Configuration & Policy Drift Detection and Monitoring
Medium
The high-signal drift is a role acting outside its expected scope: an agent-administration role changing ownership on a non-agent service principal. Detection should compare live directory changes with the approved role model and emit evidence-rich alerts when a role modifies object classes it should not manage.
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
Foundational Credential Management
Medium
If this pattern is found in an environment, response has to include credential cleanup. Remove unauthorized service-principal secrets or certificates, rotate affected credentials, revoke sessions or tokens issued through the new credential, and review downstream access performed by the taken-over principal.

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.