Descope’s InfraRed 100 recognition and what it means for external IAM

At a glance

What this is: This is a vendor recognition post that frames external IAM as a control plane for end users, partner apps, APIs, and AI agents.

Why it matters: It matters because IAM teams are increasingly being asked to govern non-human access and external identity journeys with the same rigor as human authentication and authorisation.

👉 Read Descope's InfraRed 100 recognition note and external IAM context

Context

External IAM is the set of authentication and authorisation controls used for identities that sit outside the core workforce directory. In this market, the problem is no longer only customer sign-in, but how to manage access for APIs, partners, and AI agents without creating fragmented trust paths.

The article is fundamentally about category positioning, not a technical release. Even so, it reflects a broader shift in identity programmes: external identities are becoming a shared governance surface across human, machine, and emerging agentic access patterns, which makes lifecycle clarity and policy consistency more important than surface-level login convenience.

Key questions

Q: How should security teams govern external identities across customers, partners, APIs, and AI agents?

A: Security teams should classify external identities by actor type, then assign separate authentication, authorisation, and revocation rules for each class. Customers, partners, APIs, and AI agents do not share the same risk profile, so a single policy model usually hides important differences. The goal is consistent governance, not identical treatment.

Q: Why do APIs and AI agents create more external IAM risk than human users?

A: APIs and AI agents often run continuously, use credentials programmatically, and operate at machine speed, which makes scope creep harder to notice. Human-focused controls assume interactive sessions and visible user behaviour, but external machine access can be persistent and embedded in workflows. That is why scope, expiry, and ownership matter more than convenience.

Q: What breaks when external identity lifecycles are not defined clearly?

A: When external lifecycles are unclear, access can outlive the business relationship that justified it. That creates orphaned entitlements, stale tokens, and unmanaged partner or agent access paths. Governance then becomes reactive because teams cannot confidently say who owns the identity, who can approve access, or when it should be revoked.

Q: How do you know if external IAM is actually reducing identity sprawl?

A: You know it is working when every external identity class has a named owner, a documented access path, and a revocation event that can be traced end to end. If teams still discover unknown API keys, unmanaged partners, or untracked agent credentials, the programme is reducing friction more effectively than it is reducing risk.

Technical breakdown

External IAM as a control plane for non-workforce identities

External IAM handles identities that are not traditional employees, including customers, partners, API consumers, service interactions, and AI agents. The architectural challenge is that these identities often need distinct authentication methods, different privilege boundaries, and separate lifecycle handling, yet still must be governed under one policy model. When teams split these flows across point solutions, they lose a coherent view of who or what is accessing what, and why. That is where identity sprawl begins. Practical implication: treat external identity journeys as a governance domain, not just a front-end login problem.

Practical implication: map every external identity type to a defined owner, authentication method, and access lifecycle.

Why APIs and AI agents change the external identity problem

APIs and AI agents do not behave like human users. They can authenticate more frequently, operate at machine speed, and require tighter scope control because their access patterns are persistent, programmatic, and often embedded in workflows. That changes the security model from session-centric customer access to runtime authorisation for non-human actors. If the policy stack cannot distinguish between a person, an application, and an agent, least privilege becomes a slogan rather than an enforceable rule. Practical implication: separate machine and human policy enforcement, even when they share the same external IAM platform.

Practical implication: enforce different policy and review paths for human, API, and AI agent access.

The governance gap behind passwordless and external identity journeys

Passwordless and frictionless experience are useful only when the underlying trust model stays explicit. External IAM still has to prove identity, bind access to the right actor type, and revoke it cleanly when the relationship ends. The technical risk is not authentication alone, but overextending trust across sessions, applications, or integrations that outlive their intended scope. That is why external IAM and lifecycle governance now overlap. Practical implication: design external identity flows with revocation, step-up checks, and entitlement boundaries from the start.

Practical implication: build revocation and step-up controls into external identity design, not after deployment.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

External IAM is becoming the governance layer where human, machine, and agent identities collide. The article shows that the category is no longer limited to customer authentication, because APIs and AI agents now sit inside the same identity surface. That makes the policy problem broader than login orchestration. Practitioners should treat external IAM as a shared control plane for every identity that crosses organisational boundaries.

The biggest risk is not passwordless access, but unbounded trust across external identity journeys. Experience improvements do not matter if access scope, revocation logic, and actor classification remain unclear. External identities need lifecycle boundaries as much as they need authentication flows. The practitioner conclusion is straightforward: convenience cannot be allowed to outrun authorisation discipline.

Named concept: external identity sprawl. This is the point at which customer, partner, API, and AI agent access accumulate faster than governance can classify them. The article reflects a market where identity programmes are being asked to govern more actor types through fewer interfaces, which raises the cost of ambiguity. The implication is that teams need one accountable model for external identity ownership.

AI agents intensify external IAM because they inherit machine traits without behaving like fixed applications. They can consume credentials, invoke tools, and move through flows in ways that resemble integrations, but their runtime behaviour can shift faster than static application governance assumes. That means external IAM must be able to distinguish agentic access from conventional API access before policy can be meaningful. Practitioners should expect their external identity model to expand beyond the app-user binary.

Repeat market recognition signals category maturity, not a resolved control problem. Recognition lists and growth narratives often track demand before governance has caught up. In this case, the broader signal is that external IAM is moving from a customer access feature set into a control model for mixed identity populations. The practitioner takeaway is to validate whether current programmes can really govern customers, partners, APIs, and AI agents together.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI, according to the 2026 Infrastructure Identity Survey.
• For a broader view of where AI and identity governance are heading, see Ultimate Guide to NHIs , 2025 Outlook and Predictions.

What this signals

The practical signal for IAM teams is that external identity programmes are now being asked to govern a wider population with sharper distinctions. If customers, partners, APIs, and AI agents are all handled through the same onboarding and policy machinery, ownership ambiguity will rise faster than control maturity can keep up. External identity sprawl: the programme risk is not just more accounts, but more actor types crossing the same boundary with different expectations. That is where governance debt accumulates.

With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the external IAM boundary is no longer just about user experience. It is increasingly the place where machine identities inherit human trust assumptions without human review. Teams that do not separate actor types will keep confusing convenience with control.

For practitioners

• Inventory external identity classes Classify every external actor your programme touches, including customers, partners, APIs, service identities, and AI agents. Give each class a named owner, defined authentication method, and explicit revocation path so they do not collapse into one generic external account category.
• Separate human and non-human policy paths Do not rely on one shared policy model for all external access. Use different rules for login, session duration, token scope, and step-up authorisation when the actor is a human user versus an API client or AI agent.
• Build lifecycle offboarding into external access design Make revocation a first-class requirement for partner apps, APIs, and agent identities. If an integration, vendor relationship, or agent workflow ends, the associated credentials and entitlements should be removed through a defined offboarding process.
• Review whether AI agents are being treated as applications Check where agentic workflows are being governed as if they were static software rather than runtime decision-makers. If the access pattern can change mid-session, the control model needs to account for that behaviour, not just the tool inventory.

Key takeaways

• External IAM is shifting from a customer-access feature set into a shared governance layer for humans, machines, and AI agents.
• The control problem is not only authentication. It is ownership, lifecycle, and scope management across multiple external actor types.
• Teams that cannot separate human and non-human external access will struggle to enforce least privilege or clean revocation.

Key terms

• External IAM: External IAM is the set of identity controls used for people and systems outside the workforce directory, such as customers, partners, APIs, and agents. It covers authentication, authorisation, and lifecycle handling so external access can be governed consistently instead of through disconnected point solutions.
• External Identity Sprawl: External identity sprawl is the accumulation of customer, partner, machine, and agent identities faster than governance can classify and own them. It creates ambiguity around policy, revocation, and accountability, which usually shows up as duplicated access paths, stale entitlements, and poor visibility.
• Actor Type: Actor type is the governance classification of the identity subject, such as human, non-human, or autonomous. The distinction matters because different actor types create different trust assumptions, lifecycle requirements, and access risks, even when they use similar credentials or access the same systems.
• Revocation Path: A revocation path is the defined process for removing access when an identity, relationship, or workflow is no longer valid. For external identities, it must cover tokens, integrations, partner accounts, and agent access so entitlements do not survive beyond the reason they were granted.

Deepen your knowledge

External identity classification and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for external IAM across customers, APIs, or AI agents, it is a useful place to sharpen the model.

This post draws on content published by Descope: Descope named to Redpoint’s InfraRed 100. Read the original.