Agent ID Administrator scope gaps expose service principal takeover risk

At a glance

What this is: Silverfort found that the Microsoft Agent ID Administrator role could be used to take ownership of non-agent service principals and escalate into full service principal takeover.

Why it matters: For IAM and NHI practitioners, the issue shows how a role built for agent governance can still widen the attack surface if it touches shared directory primitives.

By the numbers:

• 99% of orgs have at least one privileged service principal; over half use agent identities, and of those, almost half have 100+.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Silverfort's analysis of the Agent ID Administrator role vulnerability

Context

Agent identities are non-human identities that inherit trust from familiar directory objects such as service principals and application roles. That makes them easier to govern in theory, but also easier to mis-scope when a new control plane is layered on top of old identity primitives. In NHI governance, the question is not whether the object type is new, but whether the permission boundary is actually enforced.

Silverfort’s finding matters because service principals already sit at the centre of automation, integrations, and elevated access. If a role intended for agent objects can reach unrelated service principals, the result is not a theoretical policy bug but a practical privilege escalation path. This is the same class of governance weakness that appears whenever identity platforms expose shared back-end objects through narrow front-end labels.

The pattern is familiar in mature tenants: new identity features are adopted before their effective blast radius is fully understood. That is typical, not exceptional, in environments where NHI ownership, credential creation, and role assignment are handled by different teams without tight correlation.

Key questions

Q: How should security teams handle agent identity admin roles in Entra ID?

A: Treat agent identity admin roles as privileged until you verify the exact objects they can reach. Test whether the role can alter owners, credentials, or policy on any non-agent service principal, then restrict assignment to a small set of operators and require alerting on every ownership change.

Q: Why do service principals create a larger escalation risk than many teams expect?

A: Service principals often carry the permissions that automation, integrations, and security tooling rely on. If one is taken over, the attacker inherits those permissions and can move from administrative access to persistent operational control, which is why privileged service principals need continuous inventory and review.

Q: What breaks when ownership changes are not monitored on service principals?

A: Attackers can use ownership as a quiet bridge into credential creation and authentication. Without monitoring, the activity may look like routine administration while actually creating a new trusted login path for a high-value identity, especially in tenants where service principals already have elevated permissions.

Q: How can organisations reduce the blast radius of NHI role mis-scoping?

A: Separate object classes in your governance model, require approval for role changes that can touch identity primitives, and baseline every privileged principal. The goal is to make it impossible for a narrowly named role to reach a broader identity surface without detection and review.

Technical breakdown

How service principal takeover works in Entra ID

A service principal is the tenant-local identity that authenticates, receives roles, and calls APIs. If an attacker can become an owner of that object, they can usually add a new secret or certificate and then authenticate as the principal itself. That makes ownership a takeover primitive rather than a benign administrative flag. In this case, the key technical failure was not token forgery or password guessing. It was a permissions boundary that allowed an agent-focused role to change ownership on unrelated service principals, bridging from directory administration into direct identity control.

Practical implication: Monitor ownership changes on service principals as high-signal events and treat them as potential credential-building steps.

Why agent identity roles create scoping risk

Agent identity platforms often reuse existing directory objects, APIs, and policy surfaces because they need to fit into enterprise IAM quickly. That reuse is efficient, but it also creates inheritance problems when an action designed for agent-backed objects is checked too broadly. The risk appears when object type, resource type, and admin intent are not aligned. In practice, a role can look narrowly scoped in documentation while still touching shared primitives underneath. That is a classic control-plane mismatch, and it becomes more dangerous as agent identities scale across tenants and connect to high-value integrations.

Practical implication: Validate role scope against the underlying directory objects, not just against the role description in the UI.

Why privileged service principals raise the blast radius

Not all service principals are equal. Some hold directory roles, Graph permissions, or access paths that let them modify identity, policy, or application state. Once an attacker owns one of those principals, the resulting access is limited only by the permissions already assigned to that object. This is why service principal inventory and privilege classification matter as much as credential hygiene. The risk is structural: the more automation and integration a tenant accumulates, the more likely some principals become crown-jewel identities with broad reach.

Practical implication: Build a privileged service principal inventory and review which identities can change directory state or app registrations.

Threat narrative

Attacker objective: The attacker wants to convert limited administrative access into persistent control of a high-value service principal.

1. Entry begins with assignment of the Agent ID Administrator role to a user who is trusted to manage agent-related objects.
2. Escalation occurs when that user adds themselves as owner of a non-agent service principal and then creates credentials for it.
3. Impact is full service principal takeover, which can expose directory roles, Graph permissions, and other privileged integrations.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent identity governance cannot be evaluated only at the role label level. A role that sounds narrow may still inherit access to shared directory primitives underneath. That is the real failure mode here, because NHI control planes are often built on top of service principals, applications, and user-like objects. Practitioners should assume that any new agent admin role needs object-level validation before it is trusted in production.

Ownership is the new control point in NHI compromise chains. Once an actor can become owner of a service principal, adding credentials is usually a short step. That means ownership changes deserve the same attention as secret creation and role assignment. The governance lesson is simple: treat ownership as a privilege-bearing state, not as metadata.

Identity blast radius is determined by the privileges already attached to the principal. The article shows why privileged service principals must be mapped and monitored before new admin pathways are allowed in the tenant. If a control plane can reach those identities, the failure is not contained to agent management. Practitioners should re-evaluate where high-impact principals sit in the administrative model.

New NHI categories often expose old governance debt. Agent identities are being introduced into environments that already have opaque service principal sprawl, weak offboarding, and incomplete visibility. That combination creates trust debt, where the new control inherits the weaknesses of the old estate. Security teams should treat every new identity class as a chance to re-baseline the entire directory model.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• For a practical control baseline, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs alongside the ownership and rotation paths discussed here.

What this signals

Service principal governance is moving from inventory problems to boundary problems. The immediate programme risk is no longer just whether you know the identities exist, but whether a newly introduced admin role can touch identities it was never meant to govern. Teams should expect more control-plane overlap as agentic features are added to existing IAM stacks, which means least privilege has to be tested against actual object behaviour, not policy intent alone.

Ephemeral controls do not help if the ownership path remains open. A rotation or JIT programme can still fail if an actor can first become owner and then mint fresh credentials. That is why teams need to align entitlement review, service principal privilege classification, and change monitoring into one operational view, ideally alongside the lifecycle guidance in the Ultimate Guide to NHIs.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, the security issue is not isolated misconfiguration. It is the structural tendency of identity estates to accumulate trust faster than they are re-baselined, which is exactly why agent governance needs continuous review.

For practitioners

• Inventory privileged service principals now Identify every service principal with directory roles or high-impact Microsoft Graph permissions, then classify which ones can modify identity state, policy, or app registrations.
• Alert on ownership changes and credential creation Create high-severity detections for Add owner to service principal and Add service principal credentials, especially when the actor holds an agent-admin role or similar delegated control.
• Re-scope admin roles against underlying objects Review new and existing directory roles to confirm they cannot reach unrelated service principals, applications, or other shared primitives through inherited permissions.
• Separate agent governance from legacy app administration Use distinct review paths for agent identities, service principals, and application objects so a control meant for one class cannot silently affect another.

Key takeaways

• A role built for agent identities can still become a privilege-escalation path if it reaches shared directory primitives.
• Ownership changes on service principals are security events, because they can precede credential creation and takeover.
• Agent governance should be tested against real object boundaries, privileged principal inventory, and alerting on credential minting.

Key terms

• Service Principal: A service principal is the tenant-specific identity an application or workload uses to authenticate and access resources. In practice, it is often the object that carries permissions, so its ownership, credentials, and role assignments are high-value control points in NHI governance.
• Agent Identity: An agent identity is a non-human identity assigned to an AI agent so it can authenticate, call tools, and operate within defined permissions. It should be governed like any other privileged principal, with explicit lifecycle controls, ownership restrictions, and monitoring for scope drift.
• Ownership-based Takeover: Ownership-based takeover is an attack pattern where control of an identity object lets an actor add credentials and then authenticate as that object. It is especially dangerous in directory systems because ownership can look administrative while actually enabling persistent access.
• Identity Blast Radius: Identity blast radius is the amount of access an attacker gains after compromising a single identity object. For NHIs, the blast radius depends on attached roles, delegated permissions, integrations, and how quickly ownership or credential changes are detected.

Deepen your knowledge

Agent identity governance and service principal takeover paths are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic identity from an existing Entra ID estate, it is worth exploring.

This post draws on content published by Silverfort: Agent ID Administrator role vulnerability in Microsoft Entra ID. Read the original.