Identity sprawl and AI agents are widening the attack surface

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Semperis's research: AI agents and other non-human identities are widening identity attack surfaces, with overpermissioned access and weak recovery posture creating new paths to outage and compromise.

Why it matters: IAM and security teams need to treat agent identities, privilege drift, and recovery readiness as one control problem because machine-speed failures can become business outages before human response catches up.

By the numbers:

• NHIs already vastly outnumber human users 10:1, according to Microsoft, with that ratio trending toward a 100:1 ratio as agentic and workload identities proliferate.
• 74% believe that AI functionality will increase attacks on the identity infrastructure.
• 32% increase in identity-based attacks in the first half of 2025.
• Only 32% are very confident they could fully regain identity infrastructure control after an AI-related breach.

Context

AI is changing the identity attack surface by multiplying service principals, workload identities, and AI agents that can touch core directories and SaaS controls. The governance problem is not simply scale. It is that each new non-human identity adds another access path, another lifecycle obligation, and another recovery dependency across the identity fabric.

When those identities can influence Active Directory, Entra ID, or Okta, the issue becomes operational resilience as much as access control. That is why identity security challenges and risks now include overpermissioned automation, shadow NHIs, and recovery gaps that outpace existing IAM cadences.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents increase non-human identity risk?

A: AI agents increase non-human identity risk because they can execute many actions quickly once they inherit a credential or tool permission. That speed expands blast radius, shortens attacker dwell time, and makes weak delegation more dangerous. The remedy is tighter scoping, continuous verification, and strict separation between observation and execution privileges.

Q: What signs show that identity recovery is not actually ready for an AI-related breach?

A: The clearest signs are weak confidence in regaining control, unclear restoration steps for directories and federation, and dependencies on the very systems most likely to be altered during an incident. If teams cannot restore identity authority without guesswork, then recovery has not been tested as a control.

Q: What is the difference between shadow AI discovery and NHI governance?

A: Discovery finds the asset. NHI governance controls its lifecycle. In practice, shadow AI discovery tells you what exists across cloud and endpoint surfaces, while NHI governance determines who owns it, who approved it, what it can reach, and when it should be removed.

Technical breakdown

Why agent identities change the access model

AI agents do not behave like static service accounts when they can request, enumerate, or reconfigure access at runtime. That means entitlement decisions can no longer be understood only at provisioning time. The real issue is the interaction between identity, local machine context, and delegated authority, especially when an agent can inspect secrets or alter security settings faster than a human can intervene. In practice, this turns the identity layer into an execution layer, where misuse can occur through legitimate permissions rather than broken authentication. See the Agentic AI Identity Guide.

Practical implication: Treat AI agent access as a governed execution path, not just another account type.

How overpermissioned support agents create identity blast radius

A support agent with broad directory or endpoint permissions can turn a routine help desk workflow into a containment failure. If the agent can grant access, reconfigure policy, or inspect local secrets, then the privilege boundary sits inside the workflow itself rather than around it. This is why privilege scope, approval gates, and tool boundaries matter more than the model behind the agent. The technical risk is not merely excessive access. It is that the agent can act on identity systems in ways that multiply impact across teams and channels. See the Agentic AI Security Guide.

Practical implication: Bound every agent action to the minimum identity scope needed for the task.

Why recovery readiness is part of identity security

Identity failures become business outages when directories, federation, or recovery workflows cannot be restored quickly and cleanly. In a hybrid identity environment, compromise or misconfiguration can propagate through trust relationships, synchronization paths, and conditional access dependencies. That is why recovery is not separate from identity governance. It is part of the control plane. If teams cannot confidently regain control of identity infrastructure after an incident, then the issue is not just breach exposure. It is loss of operational authority over the environment itself. See the Active Directory and Entra ID Hardening Guide.

Practical implication: Test identity recovery as a control objective, not as a separate disaster-recovery afterthought.

Threat narrative

Attacker objective: The attacker aims to turn delegated AI access into control over identity systems, secrets, and recovery paths.

1. Entry begins when an AI agent, service principal, or endpoint-linked helper gains legitimate proximity to identity infrastructure through broad permissions or local machine access.
2. Credential harvest or abuse follows when the agent can enumerate secrets, access browser sessions, or expose SSH keys and password manager data at machine speed.
3. Escalation occurs when the actor uses those permissions to reconfigure identity settings, grant access, or widen trust paths across directories and support workflows.
4. Impact lands as identity infrastructure loss, team lockout, or prolonged business outage because recovery depends on systems that have already been altered or exposed.

Breaches seen in the wild

• Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
• SolarWinds supply chain compromise: A backdoored Orion build reached 18,000 customers; attackers then forged SAML tokens and hijacked app service principals.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity sprawl has become an attack primitive: When machine identities outnumber humans by an order of magnitude, the governance problem is no longer who has access, but how fast access can be created, reused, and forgotten. The article shows that AI agents and helper workflows are adding to this sprawl faster than organisations are tightening lifecycle control. Practitioners should treat identity sprawl as an operational control surface, not a hygiene metric.

Overpermissioned agents collapse the boundary between assistance and authority: A support agent that can reconfigure security settings, grant access, or inspect local secrets is not merely helping users. It is operating inside the trust boundary of identity infrastructure. That creates a governance gap where the same delegated role can become both service desk and escalation path. The implication is that privilege scope must be defined by action, not by job label.

Recovery readiness is now an identity control, not just a continuity concern: The article’s confidence gap around regaining control after an AI-related breach shows that many programmes still separate identity administration from crisis response. That separation no longer holds when directories, federation, and endpoint-linked secrets are all part of the same failure domain. Organisations need to think of identity recovery as a control-plane requirement, not a post-incident convenience.

Shadow AI and shadow NHIs are converging into one governance problem: The same environment that tolerates unmanaged AI tools also tolerates abandoned workload identities and stale permissions. That convergence means discovery, ownership, and offboarding now have to span humans, machine identities, and AI-enabled workflows together. If teams govern those estates separately, the attack surface stays fragmented and therefore exploitable.

Ephemeral assistance, permanent privilege debt: The article exposes a named concept worth tracking: short-lived AI interactions can still create long-lived identity exposure when permissions, secrets, and recovery paths are never re-scoped. That debt accumulates across support workflows, local endpoints, and directory integrations. The practical conclusion is that identity governance must measure what the agent can touch, not just how often it is used.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Only about one-third of approximately 500 organizations surveyed by McKinsey in 2026 report maturity level three or higher across agentic AI governance controls.
• Read next: Agentic AI Identity Guide

What this signals

Identity resilience now has to include agent behavior: Security teams can no longer assume that the identity layer is only a directory and access problem. When AI assistants can inspect secrets, change settings, or influence authentication paths, governance has to move closer to runtime authority and recovery validation. That is a programme design issue, not just a tooling issue.

Agentic identity drift will be measured in permissions, not prompts: The most important signal is whether AI helpers accumulate access faster than teams can review or revoke it. Once that drift is visible, the programme can no longer rely on periodic access review alone and has to track delegated authority across endpoints, directories, and support workflows.

Governance teams should watch for the point where machine identities become operational actors: As AI agents are embedded into help desk and admin workflows, they stop being edge cases and start behaving like routine administrators. That transition demands closer alignment between IAM, PAM, and incident recovery so that one broken workflow does not become an identity outage.

For practitioners

• Define agent permission boundaries by task Map each AI agent, service principal, and helper workflow to a narrow set of allowed identity actions, then remove any capacity to reconfigure security settings outside that task boundary.
• Inventory local secret exposure paths Review endpoints where agents can reach SSH keys, password managers, browser sessions, or cached tokens, and treat those paths as identity attack surfaces rather than convenience features.
• Separate support workflows from access-granting power Remove routine help desk paths that can approve access, alter directory controls, or widen VPN exposure without independent review, especially where AI is inserted into the workflow.
• Test identity recovery under compromise assumptions Validate whether administrators can still restore control of Active Directory, Entra ID, and federation paths after agent misuse, policy drift, or stolen credentials.

Key takeaways

• AI agents are expanding the identity attack surface because they can hold and use non-human identities with more speed and reach than human operators.
• The article highlights a confidence gap in recovery, with only 32% very confident they could fully regain identity infrastructure control after an AI-related breach.
• The control gap is not just access volume, but overpermissioned delegation, secret exposure on endpoints, and weak identity recovery testing.

Related NHI Mgmt Group resources: Agentic AI Identity Guide · Agentic AI Security Guide · Active Directory and Entra ID Hardening Guide · Ultimate Guide to NHIs: Key Challenges and Risks

Key terms

• Agentic AI Identity: The complete set of credentials, permissions, and governance controls applied to an autonomous AI agent, covering authentication, authorisation, action logging, and access revocation. Distinct from traditional NHI because agent identities are often ephemeral, delegated, and multi-hop.
• Shadow NHI: A non-human identity created outside of formal governance processes and not tracked, managed, or known to the security team, creating an unmonitored attack surface. Shadow NHIs are commonly discovered during incident investigations.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Recovery readiness: Recovery readiness is the ability to restore critical services safely, predictably, and in the right order after disruption. It depends on people, process, and access as much as it depends on backup technology. In identity-heavy environments, recovery readiness also includes knowing who can approve, execute, and validate restoration.

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.