TL;DR: Microsoft Agent Identity Platform preview adds agent identities to Entra ID and a new Agent ID Administrator role, but Silverfort found that the role could take ownership of arbitrary service principals and then add credentials for full takeover before Microsoft fixed it. The boundary error shows how new NHI controls can inherit old privilege paths if scoping is not exact.
At a glance
What this is: Silverfort’s research shows that a role intended for agent identities could cross its boundary and control non-agent service principals, turning ownership into a takeover path.
Why it matters: IAM teams managing NHI and emerging agent identities need exact scoping, because shared directory primitives can let a narrowly named role unlock broad privilege escalation.
By the numbers:
- 99% of orgs have at least one privileged service principal; over half use agent identities (of those, almost half have 100+).
Context
The control problem here is not AI hype, but privilege boundary drift inside an identity platform. A role created for agent identities was able to affect non-agent service principals, which means the authorization model did not stay aligned with the object model it was meant to govern.
Service principals are already high-value NHI assets because they back automation, integrations, and directory-wide permissions. When a role can move from managing agent objects to taking ownership of general service principals, the result is not just a bug. It is a privilege escalation path that can outgrow the new control plane.
The article’s core lesson is that identity systems built on shared primitives need stricter scope isolation than the labels suggest. That is especially true when AI agent identity is layered on top of existing service principal infrastructure, where one boundary mistake can expose an entire tenant control surface.
Key questions
Q: What breaks when an agent identity role can affect non-agent service principals?
A: The boundary between agent governance and application governance breaks, and ownership becomes a takeover primitive. When a role intended for one object class can modify another, the organisation loses assurance that scope statements match real enforcement. That turns a delegated admin role into a privilege escalation path rather than a constrained control plane.
Q: Why do privileged service principals make role-scope gaps so dangerous?
A: Because the attacker does not need to create new privilege, only inherit what the target already has. If the compromised or reassigned service principal holds directory roles or powerful Graph permissions, ownership abuse converts immediately into lateral administrative reach. The risk rises with the target’s existing permissions, not with the label on the role.
Q: How can security teams tell whether identity role scoping is working?
A: Look for consistent enforcement by object type, not just by role name or documentation. A working design should block owner changes, credential changes, and permission changes on objects outside the intended boundary. If the same role can act on both agent and non-agent service principals, the control is not actually scoped the way the programme assumes.
Q: What should teams do when new AI agent identities share directory primitives with existing apps?
A: Treat the shared primitives as a boundary-testing requirement before rollout. Separate the permissions that manage agent identities from the permissions that manage general service principals, then confirm the enforcement layer blocks cross-object inheritance. Without that test, a new identity type can inherit old privilege paths and widen the attack surface.
Technical breakdown
How ownership became the takeover primitive
In Entra ID, service principals are the identities that authenticate to APIs, receive permissions, and represent apps inside a tenant. The research shows that once the Agent ID Administrator role could add ownership to a non-agent service principal, the path to takeover was straightforward: ownership first, then credential creation, then authentication as that principal. That sequence matters because ownership changes are often treated as administrative metadata, but on service principals they can become effective control of the identity itself. Practical distinction: this is not merely a configuration error, it is identity control transfer.
Practical implication: treat service principal ownership changes as direct control changes, not routine administration.
Why scope checks failed on the service principal surface
The documented role scope covered agent-related actions, but the implementation appears to have inherited permissions through the shared service principal surface. Agent identities in this platform are built from familiar directory primitives such as service principals and users, and that reuse creates a scoping hazard when object-type checks are not strict enough. The important technical issue is not the existence of service principals, but the mismatch between the intended agent-only boundary and the actual owner-update operation exposed to broader objects. Practical distinction: the authorization check was too general for the object class it touched.
Practical implication: validate role enforcement at the object-type level, not just the role-description level.
Why privileged service principals raise the blast radius
The takeover path becomes materially worse when the target service principal already holds directory roles or high-impact Graph permissions. In that case, ownership abuse does not merely hijack an application identity. It inherits the permissions already attached to that identity and can extend into tenant-wide control functions. That is why the article emphasises privileged service principals as crown-jewel assets. The mechanism is simple, but the effect depends on the existing permission set attached to the target identity. Practical distinction: the escalation is defined by the target’s privilege, not by the role name alone.
Practical implication: inventory and segregate high-privilege service principals before new admin roles are widely delegated.
Threat narrative
Attacker objective: The attacker’s objective is to convert a limited agent administration role into full control of a more privileged service principal and use its permissions for escalation.
- Entry occurs when a principal is assigned the Agent ID Administrator role and begins acting within the agent identity control plane.
- Credential access follows when that role can add itself as owner of a non-agent service principal and then create new credentials.
- Escalation occurs when the attacker authenticates as the taken-over service principal and inherits its existing permissions.
- Impact is tenant-level privilege escalation, especially when the targeted service principal already holds privileged directory roles or sensitive Graph permissions.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Scope drift in a new identity role is still a privilege escalation problem. The most important lesson is not that Microsoft added a new agent control plane, but that the control plane reused a shared service principal surface without preserving the intended boundary. That is a classic governance failure in NHI design: a role name suggests narrow authority, while the underlying object model still permits broader control. Practitioners should treat boundary accuracy as a first-class security requirement.
Ownership on service principals is a control point, not an administrative convenience. Once ownership can be changed outside the intended object family, credential creation becomes a downstream takeover primitive. This is why role scoping, object-class enforcement, and change monitoring have to be evaluated together rather than as separate checks. The practitioner takeaway is to assume ownership changes can become auth changes unless proven otherwise.
Agent identity governance cannot be validated by label alone. The article shows that agent identities may sit on top of the same primitives that already govern applications and service principals, so the real question is whether the role boundary is enforced on the actual object instance. That matters across NHI governance, IAM, and future agentic identity controls. Practitioners should demand boundary testing, not just documented scope.
Privileged service principals create the identity blast radius that turns a scope bug into a material risk. The issue was not abstract because many tenants already have at least one privileged service principal, and some environments have many more. That means new identity controls must be tested against the existing privilege estate before broad rollout. Practitioners should reassess how new admin roles interact with crown-jewel service principals.
Identity role design for AI agents needs explicit separation from legacy application administration. The article introduces a useful concept: agent-role boundary leakage. That is what happens when a role built for AI agent governance can still influence general service principals through inherited directory primitives. The implication is that new agent identity programmes must be judged by how well they prevent privilege inheritance, not by how neatly they are named.
From our research library:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Agent-role boundary leakage: when a role for AI agents can still act on general service principals, the organisation has a scope-integrity problem, not just a preview-stage feature issue. That means future agent identity programmes should be tested against the underlying directory primitives before the role is broadly delegated.
Ownership changes on service principals should be treated as high-risk identity events because they can become the first step in a takeover chain. If the actor can add itself as owner and then mint credentials, the boundary between administration and authentication has already collapsed.
The practical question for IAM and NHI teams is whether new control planes inherit legacy privilege paths from existing directory objects. If they do, the programme needs stronger object-type isolation and tighter review of crown-jewel service principals before rollout expands.
For practitioners
- Audit service principal ownership paths Review who can become owner of non-agent service principals and verify that new identity roles cannot cross object-family boundaries.
- Monitor credential creation on high-value principals Alert on any new secret or certificate added to service principals that hold directory roles or high-impact Graph permissions.
- Separate agent identity administration from application administration Ensure roles created for AI agent management cannot modify owners, credentials, or permissions on general service principals.
- Inventory privileged service principals first Identify service principals with elevated directory roles or sensitive Graph permissions before delegating any agent identity role at scale.
- Correlate role activity with target object type Investigate ownership and credential changes by both actor and target so that normal-looking admin actions on the wrong object class are surfaced.
Key takeaways
- A role intended for agent identities was able to cross its boundary and manipulate non-agent service principals, exposing a real scoping failure.
- The research found that 99% of organisations have at least one privileged service principal, which makes the blast radius large wherever ownership abuse is possible.
- The control lesson is to test role enforcement against object type and privilege level before new AI agent administration roles are widely delegated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The issue is a role boundary that grants broader control than intended over service principals. |
| NHI-01 — Improper Offboarding | Taking ownership then adding credentials shows why identity control transfer must be revocable and bounded. | |
| Recommendation — Review role scope against NHI-05 and remove any path that lets agent admins control unrelated principals. Apply NHI-01 controls to ensure ownership and credential changes are tightly governed and reversible. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The role exceeded its intended least-privilege boundary on non-agent service principals. |
| Recommendation — Enforce AC-6 so delegated roles cannot expand beyond the exact object set they are meant to manage. | ||
| MITRE ATT&CK | TA0004;TA0006 — Privilege Escalation; Credential Access | The attack path used ownership abuse to gain credentials and escalate privileges. |
| Recommendation — Map service principal ownership abuse to TA0004 and TA0006 and alert on both ownership and credential changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The flaw is a permissions boundary failure inside identity administration. |
| Recommendation — Use PR.AA-05 to validate that entitlements on agent roles do not extend to non-agent service principals. | ||
Key terms
- Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
- Service principal takeover: Service principal takeover is the point at which an attacker or unauthorized admin gains enough control over a service principal to add credentials and authenticate as that identity. In NHI programmes, ownership, credential issuance, and permission inheritance become the critical control points because they convert administration into runtime access.
- Role boundary leakage: Role boundary leakage occurs when a role designed for one identity class can act on another identity class because the enforcement logic is too broad or the object model is shared. For AI agent governance, it means a narrowly named role can still reach general service principals if object-type checks are not strict.
- Privileged service principal: A privileged service principal is a non-human identity that already holds elevated permissions such as directory roles or high-impact API rights. These identities carry disproportionate risk because any ownership or credential abuse can immediately translate into wider tenant control, making them crown-jewel assets in identity governance.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 2, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org