AI agent identity risk is outpacing enterprise IAM controls

At a glance

What this is: Token Security argues that AI agents are becoming identities in practice, with access and autonomy combining to create a governance gap that current controls were not designed to close.

Why it matters: For IAM and NHI teams, the issue is that agents can inherit, accumulate, and exercise permissions faster than inventory, review, and revocation processes can keep up.

👉 Read Token Security's analysis of The Agentic Pulse and AI agent identity risk

Context

AI agent identity risk emerges when software starts authenticating like a user, acting like a workload, and making decisions without the oversight normally attached to either. That creates an NHI governance problem because the access path, ownership model, and review cadence all become unclear at once. Token Security’s framing is useful because it treats the issue as an identity problem, not just an automation problem.

That distinction matters for enterprise IAM because most control stacks still assume a bounded subject with stable purpose, explicit onboarding, and predictable behaviour. AI agents break those assumptions when they inherit human permissions, use dedicated service identities, or operate across workflows with limited visibility. For practitioners, the starting point is not whether the agent is useful, but whether its access can be discovered, scoped, and retired with the same discipline applied to other NHIs.

Key questions

Q: How should security teams govern AI agents that can act across multiple systems?

A: Treat each agent as a non-human identity with a named owner, explicit purpose, and scoped entitlements. Governance should combine inventory, approval, access review, and retirement controls so the agent cannot silently inherit new reach as workflows expand. The practical goal is to keep autonomy useful while keeping access bounded.

Q: When does AI agent autonomy become a security problem?

A: Autonomy becomes a security problem when the agent can chain actions without human review and those actions can affect sensitive systems or data. The risk rises sharply when autonomy is paired with broad access, because mistakes, prompt abuse, or malicious input can propagate faster than a human can intervene.

Q: What is the difference between AI agent governance and traditional IAM?

A: Traditional IAM usually assumes stable identities with predictable roles, while AI agent governance has to account for dynamic behaviour, delegated decisions, and changing access paths. The difference is that agent governance must manage both who the agent is and how far it can act over time, not just whether it can log in.

Q: Why do AI agents complicate zero trust and least privilege?

A: AI agents complicate zero trust because they can authenticate continuously yet still expand their reach through delegation, inherited permissions, and external integrations. Least privilege remains the right principle, but it must be applied to machine identities that can change scope faster than human review cycles are designed to handle.

Technical breakdown

Access and autonomy define AI agent risk

Token Security’s model is useful because it separates two variables that security teams often blur together. Access is what the agent can reach, including APIs, data, services, and infrastructure. Autonomy is how independently it can chain actions and make decisions. A low-access agent can still misbehave, but its blast radius is limited. A high-access agent with high autonomy can turn small errors into large operational effects because it can continue acting without human intervention. That is why the real governance problem is not simply deployment volume, but the coupling of permissions and decision latitude.

Practical implication: Measure AI agent risk as a function of access scope and autonomy, then use that score to drive review frequency and entitlement limits.

Why AI agents resemble non-human identities

AI agents do not fit neatly into either classic human identity or traditional workload identity categories. They may be created by a business user, inherit a user’s permissions, yet run as part of an operational process that behaves more like a backend service. That hybrid nature is what makes them hard to inventory and even harder to govern. If an organisation cannot tell whether the agent is acting on behalf of a person, a process, or itself, then ownership, approval, and offboarding all become ambiguous. In NHI terms, the failure is conceptual before it is technical.

Practical implication: Classify AI agents explicitly as NHIs and assign a named owner, purpose, and retirement path at creation time.

Least privilege is the decisive control surface

The article’s strongest operational point is that autonomy is often less controllable than access, so teams should reduce risk where they have leverage. That means scoping permissions narrowly, reviewing inherited access, and limiting the services and data an agent can touch by default. Continuous access review matters because agent behaviour can expand over time as new integrations, prompts, or delegation paths are added. The governance challenge is not to freeze agent capability, but to prevent permission drift from turning a useful assistant into an uncontrolled identity.

Practical implication: Treat entitlement scope as the primary control and design recurring review for every agent that can authenticate into production systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 agents are becoming a distinct NHI class, not a niche extension of existing automation. The moment an autonomous system can authenticate, act, and make decisions across services, the control question shifts from software governance to identity governance. That shift matters because existing IAM patterns are built around stable subjects, while agent behaviour is dynamic and often delegated. Practitioners should stop asking whether the agent is a tool and start asking which identity controls apply to it.

Access and autonomy is the right lens for agentic risk, and it should replace vague maturity discussions. A busy organisation can have many agents with very different risk profiles, and a simple count of deployments does not explain exposure. Access drives blast radius, while autonomy drives how quickly that blast radius can spread. Security teams should use this lens to prioritise the agents that combine broad scope with self-directed execution.

Ephemeral or task-scoped access is not enough unless ownership and revocation are explicit. Short-lived credentials reduce standing exposure, but they do not solve ambiguous delegation, hidden inheritance, or unreviewed integration paths. That gap creates what can be called ephemeral credential trust debt, where temporary access still accumulates operational risk if nobody owns the lifecycle. Practitioners should pair time-bound access with mandatory inventory and retirement controls.

Agentic governance will increasingly converge with NHI governance and zero trust principles. The market is moving toward treating AI agents as first-class identities because that is the only model that scales across discovery, access review, and incident response. That does not mean every agent needs the same treatment as a human user, but it does mean the organisation needs one governance system for all machine identities. Teams should align agent controls with NHI lifecycle management rather than treating them as an exception.

OWASP-style agent risk framing will matter more than product-centric feature lists. The practical value is not in how many agent capabilities a platform claims, but in whether teams can reason about prompt abuse, tool misuse, delegated access, and identity drift. That is the level at which incident response and governance become operational. Practitioners should evaluate controls by the failure modes they prevent, not by the number of agent features they expose.

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% have implemented policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security, according to the same report.
• For a broader view of the category risk, see OWASP Agentic AI Top 10 for the control failures that most often surface in autonomous systems.

What this signals

Identity blast radius: AI agents should be managed as identities whose effective blast radius is defined by access scope, not by whether they were created through a user interface or an API. That shift will push practitioners toward tighter inventory, faster revocation, and more explicit ownership across the full lifecycle.

With 98% of organisations planning to deploy more AI agents within 12 months, according to AI Agents: The New Attack Surface report, the governance gap will widen unless teams standardise onboarding, review, and shutdown rules now.

The most durable control model will blend NHI lifecycle management with agent-specific risk review, because access review alone will not capture autonomy drift or hidden delegation paths. Teams should align their programme with NIST AI Risk Management Framework principles for governance, mapping ownership and accountability before scale makes remediation expensive.

For practitioners

• Inventory every AI agent as an identity Create a live register that records owner, purpose, authentication method, connected systems, and retirement criteria for each agent. Use the same discipline you would apply to other non-human identities, including service accounts and API tokens.
• Bound agent permissions to explicit tasks Strip inherited or broad entitlements from agents and replace them with task-scoped permissions that map to approved workflows. Re-review any agent that can touch production systems, customer data, or administrative APIs.
• Separate autonomy from access reviews Assess how independently an agent can act, then assess what it can reach, and do not assume one implies the other. A low-autonomy agent can still be dangerous if it inherits privileged access, while a high-autonomy agent becomes critical once it can chain actions across systems.
• Add retirement triggers to agent lifecycle controls Define events that force review or shutdown, such as owner change, new integration, scope expansion, or inactivity. If an agent cannot be cleanly revoked, it is not governed, only tolerated.

Key takeaways

• AI agents are operational identities, so IAM teams need inventory, ownership, and revocation controls that match their speed and scope.
• The main risk is not agent adoption by itself but the combination of access, autonomy, and hidden delegation paths.
• Security programmes should treat least privilege and lifecycle governance as the primary controls for agentic environments.

Key terms

• Access and autonomy: A practical way to assess AI agent risk by looking at what the agent can reach and how independently it can act. Access determines blast radius, while autonomy determines how quickly that blast radius can spread across systems without human intervention.
• Non-Human Identity: A digital identity used by software, services, workloads, or agents rather than a person. In practice, this includes tokens, service accounts, certificates, API keys, and autonomous AI agents, all of which need ownership, scoping, review, and revocation.
• Identity blast radius: The amount of damage an identity can cause if it is misused, over-permissioned, or compromised. For AI agents and other NHIs, blast radius is shaped by entitlements, data reach, and the number of systems an identity can touch before controls intervene.

What's in the full article

Token Security's full post covers the operational detail this post intentionally leaves for the source:

• A deeper explanation of the Agentic Pulse model and how the vendor is measuring access and autonomy over time
• The three agent categories the vendor sees in enterprise environments, including how their identity patterns differ
• The vendor's view of why current security frameworks are missing the emerging AI agent identity problem
• Practical examples of how the vendor is thinking about access control and oversight for autonomous agents

👉 Token Security's full post expands on the agent access and autonomy model behind the analysis.

Deepen your knowledge

AI agent identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are formalising controls for autonomous systems and service identities, it is worth exploring.