AI agent identity risk is outpacing enterprise auth controls

At a glance

What this is: Descope’s customer identity analysis shows AI agent adoption racing ahead of enterprise auth and identity controls, with only a small minority treating AI as a governed identity class.

Why it matters: IAM and security teams need to treat AI agents as a distinct governance problem because legacy customer auth patterns do not provide the visibility, scope control, or accountability these systems require.

By the numbers:

• 88% of organizations are using or plan to use AI agents, but only 37% have progressed beyond pilot programs.
• Only 9% have integrated identity and data security controls for AI.

Context

AI agent identity risk is the gap between how quickly organisations are deploying agentic systems and how slowly they are adapting authentication, authorisation, and data controls to govern them. In customer identity programmes, that gap shows up when systems built for human users are asked to supervise software entities that act on behalf of users, but not always within the same trust assumptions.

Descope’s 2025 customer identity analysis frames this as a governance problem, not just a product gap. The core issue is that teams are already using or planning for AI agents at scale, while only a small minority have integrated identity and data security controls for AI, leaving scope, visibility, and accountability under-specified.

That mismatch is most dangerous when organisations treat AI agents as an extension of existing auth patterns rather than as a separate identity class. The result is familiar control language applied to unfamiliar runtime behaviour, which creates blind spots for authorisation, consent, delegation, and downstream data exposure.

Key questions

Q: How should security teams govern AI agents that use multiple identity layers?

A: Security teams should inventory every identity layer an agent can use, including static credentials, session identities, embedded tool identities, and any delegated relationships between agents. Governance fails when one layer is controlled while another remains open, because the agent can still act through the weaker path. Treat the layered identity surface as the actual access boundary.

Q: Why do AI agents create extra risk when they need to authenticate to other services?

A: AI agents expand risk because they often need reusable credentials to complete tasks across multiple systems. If those credentials are standing and loosely tracked, the agent can inherit broad access, blur human and machine ownership, and make rotation harder. That combination increases the chance of misuse, overreach, and delayed response when access should be revoked.

Q: What are the signs that non-human identity controls are failing in AI-driven environments?

A: Common warning signs include long-lived credentials that are not rotated, excessive permissions on service accounts, secrets stored in code or configuration, and weak visibility into which identities are active. If teams cannot answer who owns each credential, where it is used, or when it was last reviewed, the control environment is already drifting outside safe operating bounds.

Q: Should organisations treat AI agents like human users in IAM?

A: No. Human IAM assumes a person logs in, works within a session, and can be reviewed later as a stable identity holder. Agents can act at machine speed, across multiple systems, and with changing runtime context, so they need identity governance built around execution and delegation rather than human authentication patterns.

Technical breakdown

Why customer auth controls break down for AI agents

Customer authentication controls are designed around a human principal signing in, establishing a session, and operating within a predictable interaction pattern. AI agents complicate that model because they may access data, call tools, and make follow-on decisions without a human being present at each step. That shifts the problem from login assurance to delegated execution assurance: who granted the scope, what data can be touched, and how the agent is constrained once active. In practice, the weak point is not only authentication, but the trust boundary after authentication. If the policy model still assumes a person is the actor, the organisation loses visibility into the agent’s effective privileges and actions.

Practical implication: Treat agent authorisation and runtime scope as separate from human login policy.

Identity and data controls for AI need their own lifecycle

The article’s most important signal is that AI systems are being handled as if they fit inside existing IAM and data security workflows, even though they behave more like a new identity class with delegated authority. That means lifecycle questions become central: how an agent is onboarded, what it is allowed to access, how scope is reviewed, and how access is revoked when the use case changes. Without that lifecycle, organisations default to broad access, poor visibility, and weak ownership. The technical failure is not just missing configuration, but missing identity inventory and governance state for the agent itself.

Practical implication: Inventory AI agents as governed identities and tie them to explicit owners, scopes, and offboarding steps.

Why visibility matters more than simple access approval

The article points to a recurring pattern in identity security: organisations may approve access in principle, but they cannot see what the system is actually doing once that access is active. For AI agents, that gap is amplified because the actions can be multi-step, data-rich, and hard to reconstruct after the fact. Visibility is therefore not a logging afterthought; it is part of the control model. If teams cannot answer what data the agent touched, which prompts or actions led there, and whether the behaviour stayed within intended scope, they cannot credibly govern agent risk.

Practical implication: Instrument AI agents for traceability, scope monitoring, and post-action review.

Threat narrative

Attacker objective: The objective is to exploit weak AI identity governance so the agent reaches data or actions beyond its intended scope.

1. Entry occurs when an organisation grants an AI agent broad or default access so it can operate on behalf of users or teams.
2. Escalation follows when the agent can touch information beyond its intended scope or act without enough visibility into its decisions.
3. Impact is the exposure of sensitive data, unauthorised sharing, or control loss across systems that were assumed to be safely mediated by identity controls.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

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 is no longer a pilot problem: it is becoming a production governance problem faster than most customer identity programmes can absorb. When 88% of organisations are using or planning for AI agents but only 9% have integrated identity and data security controls for AI, the issue is not awareness. The issue is that control design is lagging runtime behaviour, and that is where trust breaks first.

Access review was designed for stable principals, not runtime actors: the familiar assumption is that access persists long enough to be reviewed, recertified, and removed on a schedule. That assumption fails when an AI agent can obtain, use, and reshape privilege inside a single operational flow. The implication is that governance has to move closer to issuance and delegation, because review cycles alone cannot observe transient agent behaviour.

Customer authentication is being asked to do identity governance work it was never built for: human login assurance, step-up checks, and MFA coverage do not answer whether an AI agent should exist as a governed identity at all. The deeper problem is not weaker sign-in, but mismatched identity semantics. Practitioners need to stop treating agentic access as a minor extension of CIAM and start treating it as a distinct identity model.

Ephemeral AI trust debt: organisations are accruing governance debt every time they grant an agent scope without a durable owner, observable boundary, or revocation path. That debt is harder to see than a password problem because it is embedded in delegated execution rather than static credentials. The practitioner implication is simple: if the agent cannot be clearly inventoried and bounded, it is already outside mature identity control.

AI identity governance will converge with NHI discipline, but only if teams stop overfitting human patterns: AI agents are not humans, and they are not merely workloads either. They sit in the middle as delegated actors with their own runtime behaviour. The strongest programmes will borrow from NHI governance, authorisation, and lifecycle thinking, then adapt those controls to autonomous decision paths rather than assuming customer auth patterns are sufficient.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Ephemeral AI trust debt: every agent granted broad scope without an owner, boundary, or revocation path creates governance debt that traditional customer auth cannot pay down later. The control problem is no longer just who can sign in, but what a delegated actor can do after authentication, which pushes IAM teams toward lifecycle and authorisation patterns closer to NHI governance than to classic CIAM.

Security teams should expect AI identity review to shift from periodic certification toward issuance-time policy, because agent behaviour can change faster than access review cadences. That makes visibility, inventory, and offboarding the practical differentiators between pilot usage and governed deployment.

AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. That trend reinforces the same operational lesson: AI systems expand the identity surface faster than teams can classify and control it.

For practitioners

• Classify AI agents as governed identity subjects Create an explicit inventory of agents, their owners, and their approved business purpose so they are not hidden inside general application accounts or generic auth flows.
• Separate human login policy from agent authorisation Define what the human must prove at sign-in and what the agent may do after activation, with scopes documented independently from user authentication.
• Attach revocation and offboarding to agent lifecycle Require a named owner, a scope review point, and a removal path for every agent before it is allowed to touch sensitive data or external tools.
• Instrument agent activity for traceability Log the data sources, actions, and downstream decisions taken by the agent so security and IAM teams can reconstruct what happened without relying on user memory.

Key takeaways

• AI agents are becoming a governance problem faster than most identity programmes can adapt, and the gap is now visible in adoption versus control maturity.
• The central weakness is not sign-in alone, but the lack of durable ownership, scope boundaries, and traceability for delegated agent actions.
• Practitioners need to manage AI agents as governed identities with explicit lifecycle controls, separate authorisation, and actionable visibility.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Agent Authorization: Agent authorization is the decision process that determines whether a software agent may take a specific action at runtime. It evaluates context, delegated authority, and resource sensitivity at the moment of execution, not only at login or provisioning time.
• Customer Identity And Access Management: Customer Identity and Access Management is the discipline of governing how external users sign in, recover access, and move through digital services. It combines authentication, profile management, and lifecycle control so organisations can deliver secure, low-friction experiences at scale.
• Ephemeral Privilege: Ephemeral privilege is access that exists only for a short task or runtime window, then should disappear. In cloud and container environments, the challenge is not granting it, but proving it was created, used, and removed within the intended boundary before it becomes a lingering exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.