AI agents expand NHI attack surface faster than IAM can govern

At a glance

What this is: This is a blog analysis of how AI agents expand NHI risk by multiplying identities, permissions, and monitoring gaps across enterprise systems.

Why it matters: It matters because IAM, IGA, and PAM teams now have to govern software identities that are created casually, operate quickly, and can outgrow human-paced control models.

Context

AI agents are software identities that can access enterprise systems, use credentials, and act across workflows without being human users. As they move into customer support, security operations, and business automation, the governance problem shifts from isolated service accounts to a rapidly expanding identity estate that must be inventoried, scoped, and retired.

The article's core claim is that existing IAM models were built for slower, more stable access patterns than the ones AI agents now create. For NHI governance teams, the issue is not simply more identities, but identities that can be created faster than ownership, purpose, and privilege can be formally assigned.

Key questions

Q: What breaks when AI agents are given access without identity governance?

A: What breaks is accountability. The organisation may see actions, logs, and alerts, but it cannot reliably tie them to a governed identity with clear scope and revocation. That creates uncontrolled blast radius, especially when agents can reach sensitive systems through shared tokens, delegated service accounts, or broad API access.

Q: Why do AI agents create more NHI risk than ordinary developer automation?

A: AI agents can choose actions dynamically, call external services, and chain requests without a human approving each step. That increases the chance of overreach, secret exposure, and ambiguous attribution. Ordinary automation follows predefined paths, but autonomous agents can drift outside expected behaviour while still appearing to complete a legitimate task.

Q: What do teams get wrong about AI agent access reviews?

A: Teams often assume an access review can certify an agent the same way they certify a human or a service account. That fails when the agent’s behaviour changes session by session, because the review describes a static snapshot while the risk is dynamic execution. Review evidence should include tool use, action logs, and revocation tests.

Q: Why do service accounts and other NHIs complicate GRC implementation?

A: NHIs complicate GRC because they often outnumber human accounts, change outside normal HR-driven lifecycle processes, and carry access that is easy to overlook in reviews. If inventory, ownership, and expiry are incomplete, the GRC programme will miss the most material access risks. That makes NHI governance a core compliance issue, not a niche security task.

Technical breakdown

Why AI agents change the NHI inventory model

AI agents do not behave like static service accounts. They can be created by different teams, connected to multiple systems, and granted permissions that reflect immediate task needs rather than a long-lived role. That makes inventory, ownership, and purpose mapping much harder than traditional NHI discovery because the estate is not just larger, it is more fluid. In practice, the control problem shifts from cataloguing accounts to continuously understanding which software identities exist, who owns them, and what they can reach.

Practical implication: treat AI agent discovery as a continuous governance function, not a periodic account review.

How privilege creep appears in AI agent deployments

AI agents often inherit access from the human or workflow context that created them, which can quickly produce broad, overlapping, or unnecessary permissions. Because these identities can operate across cloud, SaaS, and internal systems, small scoping mistakes can turn into large blast-radius problems. The important point is that privilege creep is not just an access-control issue here. It is a lifecycle issue, because the identity may be provisioned quickly, used widely, and never cleanly retired.

Practical implication: bind AI agent access to a formal purpose and expiration state, not to the convenience of the initial deployment.

Why machine-speed behaviour strains conventional monitoring

AI agents can make decisions and invoke tools far faster than a human review cycle can keep up with. That means behavioural monitoring has to detect unusual access patterns while the session is still active, not after the fact. Traditional logging alone is not enough if the identity can traverse multiple systems in seconds. The technical challenge is to connect authentication, authorisation, and activity telemetry tightly enough that risky behaviour is visible before it compounds across systems.

Practical implication: align detection and containment to machine-speed execution, not human incident-response timing.

Threat narrative

Attacker objective: The objective is to use a compromised or over-permissioned AI agent to move quickly across enterprise systems and reach sensitive data or security controls before governance catches up.

1. Entry begins when AI agents are provisioned casually and inherit access from the workflow or creator context rather than from a tightly scoped identity request.
2. Escalation occurs when the agent accumulates broad permissions across multiple systems, creating a larger blast radius than the original use case required.
3. Impact follows when a compromised or misused agent traverses cloud, SaaS, and on-prem environments faster than human-paced monitoring can constrain it.

Breaches seen in the wild

• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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

NHI Mgmt Group analysis

AI agent sprawl is becoming an identity governance problem before it becomes an AI governance problem. The article shows that the core failure is not model behaviour alone, but uncontrolled creation of software identities that carry access into production systems. When identities can be stood up quickly by multiple teams, the first loss is governance visibility, and the second is accountability. The practitioner conclusion is that AI agent governance must sit inside identity operations, not outside them.

Privilege assignment for AI agents is already drifting beyond the assumptions that shaped NHI control design. Traditional lifecycle models assume that an identity's purpose, owner, and scope can be set and then monitored over time. AI agents make that assumption brittle because their task scope can expand, their tools can vary, and their access can be reused across multiple workflows. The implication is that least privilege has to be treated as an ongoing state, not a one-time provisioning outcome.

Identity review processes are lagging the speed at which AI agents consume and combine access. Access reviews work best when there is a stable identity to recertify and a human owner who can explain it. AI agents blur both conditions by operating at machine speed and by spanning multiple business functions. The practitioner conclusion is that review cadence alone cannot close the gap if issuance, monitoring, and retirement are not enforced at the identity layer.

AI agents expose a named concept we can call identity blast radius. That is the distance between a single agent's initial permissions and the number of systems it can touch before intervention. The article makes clear that broad permissions, multi-system reach, and weak ownership turn one identity into many paths of impact. The practitioner conclusion is to govern each agent as if its blast radius will be tested, because in practice it will be.

Autonomous behaviour collapses the assumption that access can be safely governed after issuance. Access review processes were designed for identities whose privileges persist long enough to be observed, certified, and retired. That assumption fails when an AI agent can acquire, use, and discard access within a short operational burst, leaving the review cycle with no stable state to assess. The implication is that governance must move closer to issuance and runtime boundaries, because the old timing model no longer holds.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: Ultimate Guide to NHIs

What this signals

Identity blast radius: AI agents make the distance between initial permission and enterprise impact much larger than most IAM programmes assume. Once a software identity can touch multiple systems in one task, governance has to measure how far it can travel, not just whether it authenticated successfully.

Security leaders should expect the control boundary to move from periodic certification to issuance-time policy enforcement. That shift matters because machine-speed identities can outpace the evidence trail that traditional access review depends on.

The operational test is simple: if you cannot explain why an agent exists, who owns it, and when it should disappear, you do not have governance. You have accumulation.

For practitioners

• Map every AI agent to an accountable owner Require a named human owner for each AI-driven identity, with documented purpose, intended systems, and approved business use. Unowned agents should be treated as governance defects, not just inventory gaps.
• Scope agent permissions to one declared task Bind each AI agent to the minimum access needed for its declared role and block inherited broad permissions from creator accounts or shared service credentials.
• Add AI agent discovery to continuous inventory Track newly created agents, dormant agents, and agents that cross environment boundaries so that inventory stays current as adoption scales.
• Set retirement triggers for AI identities Decommission AI agents when the business process ends, the workflow changes, or the identity is no longer actively needed, rather than leaving dormant access in place.
• Monitor for cross-system privilege expansion Watch for agents that begin with narrow access and then accumulate reach across cloud, SaaS, and internal systems, because that pattern increases blast radius.

Key takeaways

• AI agents are expanding the NHI attack surface because they are created quickly, granted access across multiple systems, and monitored with controls built for slower identities.
• The central issue is governance mismatch, not just more automation, because identity models designed for stable access do not fit software that acts at machine speed.
• Security teams need to shift AI agent oversight toward ownership, purpose, least privilege, and decommissioning if they want to prevent privilege creep and unmanaged blast radius.

Key terms

• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.
• 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.
• Privilege Creep: Privilege creep is the gradual accumulation of access rights beyond what an identity actually needs. It usually happens when permissions are added for convenience and never removed. For NHIs, privilege creep expands blast radius and makes old credentials far more dangerous than their original purpose suggests.
• Identity Ownership: Identity ownership is the assignment of a responsible human for each identity's purpose, access, review, and retirement. For non-human identities, ownership must be explicit because the creator is not always the right person to approve ongoing access. Without ownership, review and revocation become inconsistent and slow.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.