Why IAM fails to secure AI agents in modern enterprises

At a glance

What this is: This analysis argues that conventional IAM controls break down when AI agents can chain actions, infer intent, and use multiple non-human identities across systems.

Why it matters: IAM and NHI practitioners need controls that evaluate agent behavior in context, not just whether an identity was technically authenticated and authorized.

👉 Read Lia Ciner's analysis of why IAM fails to secure AI agents

Context

AI agent identity risk is the gap that opens when autonomous software can authenticate, request tools, and move across services faster than governance processes can classify it. In practice, IAM can still confirm who or what logged in, but it cannot reliably explain whether an agent’s sequence of actions matched business intent. That is why AI agents quickly become an NHI governance problem, not just an application design issue.

The article’s central claim is straightforward: traditional IAM assumptions about static roles, predictable workflows, and clearly bounded identities do not hold for agentic AI. That makes visibility, ownership, and lifecycle control the real control points. For teams building governance around autonomous systems, the operational question is whether they can see and constrain the agent before they can trust the access model.

Key questions

Q: How should security teams govern AI agents as non-human identities?

A: Treat AI agents as governed non-human identities with owners, scopes, expiration, and review cycles. Static authentication is not enough because agents can chain actions and change behavior across systems. Security teams should inventory every agent, bind it to a business purpose, and apply policy controls that limit what it can touch at runtime.

Q: Why do AI agents create more IAM risk than normal applications?

A: AI agents create more IAM risk because they are autonomous actors, not fixed workflows. They can choose tools, call APIs, and move through systems based on context, which makes their access patterns harder to predict. That means a permission that looks valid in IAM can still be unsafe in practice.

Q: What is the difference between authentication and visibility for AI agents?

A: Authentication proves that an agent is allowed to present credentials, while visibility shows what the agent actually did after it gained access. For AI agents, visibility matters more because behavior is dynamic and multi-step. Without correlated logs across systems, teams cannot judge intent, scope, or accountability.

Q: Should organisations use just-in-time access for AI agents?

A: Just-in-time access can reduce standing privilege, but it does not solve agent trust on its own. It works best when paired with task-scoped policies, strong ownership, and runtime checks on data sensitivity and destination systems. Use it to narrow exposure, not as a substitute for governance.

Technical breakdown

Why role-based access control breaks down for AI agents

RBAC works when access needs are known in advance and the identity’s duties are stable. AI agents do not fit that pattern because they select tools and data sources dynamically, often chaining actions across SaaS apps in response to context. That makes preassigned roles either too narrow to function or too broad to be safe. The failure mode is not a missing permission check. It is that the permission model cannot express the difference between technically allowed and operationally appropriate access.

Practical implication: Use task-scoped entitlements and periodic policy review instead of assuming static roles will remain safe.

Why NHI sprawl grows around autonomous agents

Each agent may depend on multiple secrets, service accounts, and OAuth grants, and those identities are often created outside the main IAM workflow. Once that happens, ownership becomes blurred and lifecycle events such as rotation, revocation, and offboarding are harder to enforce. The result is NHI sprawl, where the estate grows through convenience rather than governance. In that state, the security problem is not just too many identities, but too many identities with unclear provenance and weak accountability.

Practical implication: Inventory every agent-linked secret and service account, then assign a named owner and expiry condition to each one.

Why logs do not equal visibility for AI agent behavior

Authentication logs, SaaS audit trails, and cloud telemetry each show a slice of activity, but none of them fully explains an agent’s decision path. An incident responder may see that an agent accessed a system, yet still miss why it did so, what other systems it touched, and whether that sequence was expected. That gap is critical because autonomous behavior is contextual and multi-step. Logging records events, but visibility connects those events to a governed identity and a business process.

Practical implication: Correlate agent actions across systems so you can trace one identity from authentication through downstream tool use.

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

AI agent identity governance is now an NHI problem, not a niche AI problem. Once an autonomous system can request tools, inherit tokens, and act across services, it functions as a non-human identity with execution authority. The governance model has to treat the agent as a first-class identity lifecycle object, including onboarding, scoping, review, and offboarding. Security teams should stop asking whether the agent is authenticated and start asking whether the agent is governable.

RBAC creates false comfort when behavior is dynamic. Role assignment can prove entitlement, but it cannot prove context. That matters because an AI agent may remain within its granted permissions while still making a risky sequence of decisions, such as crossing systems or expanding data exposure. The practical conclusion is that least privilege for agents must be paired with runtime policy and continuous review, not static role assignment alone.

NHI sprawl is the predictable byproduct of autonomous tooling. Every new agent tends to bring its own service accounts, API keys, and OAuth grants, and those credentials rarely fit neatly into human-centric IAM processes. The result is a growing estate of machine identities with partial ownership and weak lifecycle discipline. Teams should assume the sprawl will accelerate unless discovery, ownership, and expiry controls are automated from the start.

Visibility is the control surface that makes agent governance possible. Without correlated visibility, logs remain fragmented evidence rather than operational insight. That means security teams cannot reliably determine which agent acted, what it touched, or whether its behavior matched intent. The field should treat unified visibility across authentication, SaaS activity, and downstream actions as a prerequisite for any serious NHI program.

Ephemeral access does not solve agent trust by itself. Just-in-time provisioning can reduce standing exposure, but it does not answer the deeper question of how much judgment an agent should be allowed to exercise once access exists. That is the emerging trust problem for agentic AI, and practitioners should frame controls around bounded execution, not only shorter credential lifetimes.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
• That gap makes Ultimate Guide to NHIs -- Lifecycle Processes for Managing NHIs the more practical next step for teams building ownership, rotation, and offboarding controls.

What this signals

The governance takeaway for practitioners is that AI agent risk will not be solved by expanding legacy IAM alone. The control model has to absorb ownership, bounded execution, and lifecycle review for each autonomous identity, or the organisation will keep adding access faster than it can explain it. That is why the identity blast radius becomes the programme-level metric that matters most.

With 48% of organisations still unable to track and audit the data their AI agents access, the operational problem is already a compliance and investigation issue, not just an architecture issue, according to AI Agents: The New Attack Surface report. Security teams should expect AI governance reviews to shift from policy discussion to evidence collection.

Agent lifecycle debt: when agent identities are created faster than they are reviewed, rotated, or revoked, the estate becomes harder to trust over time. That is where NIST AI Risk Management Framework style governance becomes useful, because it forces teams to document accountability before the agent expands its operational reach.

For practitioners

• Discover every agent-linked identity Build an inventory of AI agents, service accounts, OAuth grants, API keys, and certificates that can act without direct human approval. Include shadow AI discovered in SaaS tools and prompt-driven workflows, then map each identity to an owner and business purpose.
• Replace static roles with task-scoped policy Limit each agent to the minimum tools, data sources, and action scope needed for the specific workflow. Recheck those permissions when the workflow changes, not only at annual access review.
• Correlate logs into a single agent trail Connect authentication events, API calls, SaaS audit logs, and downstream cloud actions so incident teams can trace one agent across systems. Use the resulting trail to distinguish expected automation from unauthorized escalation.
• Enforce expiry and ownership on all non-human credentials Require time limits, revocation paths, and named accountability for every secret or token used by an AI agent. Where a credential cannot be attributed to an owner, treat it as a governance defect rather than an acceptable exception.
• Adopt runtime controls for autonomous behavior Use policy checks that evaluate context at execution time, including data sensitivity, destination system, and action chain length. That helps reduce the risk of an agent staying within permission boundaries while still causing excessive exposure.

Key takeaways

• AI agents behave like non-human identities with decision authority, which makes static IAM controls an incomplete defence.
• Most organisations are already seeing agents exceed intended scope, so governance gaps are operational today rather than hypothetical.
• The practical response is lifecycle control, runtime policy, and correlated visibility across every agent-linked identity.

Key terms

• AI Agent: An AI agent is autonomous software that can decide, plan, and execute actions with tool access. In security terms, it behaves like a non-human identity with delegated authority, which means its permissions, ownership, and runtime limits must be governed like any other privileged actor.
• Non-Human Identity: A non-human identity is any machine or software identity used to access systems, including service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. These identities often outnumber human accounts and require lifecycle controls because they can persist, spread, and retain privilege long after the original use case ends.
• Shadow AI: Shadow AI is an AI system or agent operating in an environment without formal approval, ownership, or visibility. It creates governance risk because security teams may not know what data it accesses, what credentials it uses, or which business process it influences until an incident or audit exposes it.
• Agent Identity Blast Radius: Agent identity blast radius is the amount of damage an autonomous agent can cause if its credentials, permissions, or decision logic are abused. The larger the blast radius, the more a single compromised agent can affect data, systems, and downstream workflows across the enterprise.

Deepen your knowledge

AI agent identity governance and lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building policy for autonomous systems from a similar starting point, it is worth exploring.

This post draws on content published by Lia Ciner: Why IAM Fails to Secure AI Agents. Read the original.