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

At a glance

What this is: This is a recognition announcement that also shows external IAM is being positioned around customer, partner, API and AI agent access rather than only human sign-in flows.

Why it matters: It matters because IAM teams now have to govern external identity journeys that cross human users, machine access and emerging AI agent access in the same control plane.

Context

External IAM is the set of controls that manages how outside parties authenticate, authorise and move through an organisation’s digital services. In this article, the subject is not just customer login, but a wider external identity boundary that now includes APIs and AI agents as first-class access subjects.

Descope’s InfraRed 100 recognition is the trigger for the announcement, but the governance signal is broader. External identity programmes are shifting from a human-centric front door to a mixed environment where developers, partners, workloads and AI agents all need scoped, auditable access journeys.

For IAM practitioners, that means the old split between workforce identity and customer identity is becoming less useful on its own. The practical question is how to govern authentication, authorisation and lifecycle controls when external access is now multi-actor by design.

Key questions

Q: How should teams govern external IAM when APIs and AI agents share the same access boundary?

A: Treat APIs and AI agents as distinct identity subjects, not as variations of the same user flow. That means separate ownership, separate authorisation scope and separate offboarding logic. If the same control plane cannot explain who is acting, what they may do and when access ends, the programme is mixing convenience with governance.

Q: Why does external IAM need lifecycle controls beyond login and MFA?

A: Because external identity risk is not limited to initial authentication. Partners, APIs and AI agents can retain access long after the relationship, task or workflow changes. Lifecycle controls matter when access must be reviewed, modified and revoked in step with the business purpose that created it.

Q: What breaks when identity and governance controls do not cover both app access and machine access?

A: When governance stops at human users, organisations miss service accounts, API keys, certificates, and workload credentials that can still reach critical systems. That leaves unmanaged pathways for privilege escalation, persistence, and audit failure. A complete programme must treat every identity type as a control point, not just the employee account layer.

Q: What should security teams check before expanding external IAM to AI agents?

A: They should verify whether the platform can represent the agent’s role, limit its privileges, and revoke access without waiting for a human user journey to finish. If those conditions are missing, the programme is not ready for agentic access at scale.

Technical breakdown

Why external IAM breaks when APIs and AI agents share the same boundary

External IAM originally focused on human-facing authentication flows such as login, registration, and step-up verification. Once APIs and AI agents enter the same boundary, the control problem changes: a machine does not just authenticate, it also needs scoped authorisation, lifecycle control, and revocation pathways that match its runtime behaviour. That is why external IAM is no longer only about session creation. It is about ensuring that each external actor type receives the minimum access needed for its function, with governance that follows the identity from issuance through decommissioning.

Practical implication: model external access separately for humans, APIs and AI agents before you standardise policies across them.

External IAM and the move from passwordless login to lifecycle governance

Passwordless authentication reduces friction for people, but it does not solve the broader governance problem described here. The article shows a shift from improving sign-in to managing complete identity journeys across multiple actor types. That includes provisioning, ongoing authorisation, and offboarding for external identities that may belong to customers, partners, service integrations or agents. In practice, external IAM becomes an identity lifecycle discipline, not just an authentication experience layer.

Practical implication: pair passwordless design with explicit offboarding, entitlement review and ownership controls for every external identity class.

How AI agent access changes the trust model for external identity

AI agents complicate external IAM because their access is often delegated, tool-driven, and short-lived, yet still capable of performing meaningful actions on behalf of users or organisations. That pushes identity governance beyond static account records and into authorisation context, session scope and action boundaries. The same external identity programme must now decide whether an agent is acting as a customer proxy, an integration workload, or a semi-autonomous actor. Those distinctions matter because they determine who owns the identity, what policy governs it, and how quickly it can be revoked.

Practical implication: define whether each AI agent is a proxy, workload or autonomous actor before assigning access policy.

NHI Mgmt Group analysis

External IAM is becoming the control plane for mixed identity populations, not just customer access. This article shows a market category that is expanding from login orchestration into governance for end users, partners, APIs and AI agents. That matters because the control objectives differ by actor type even when the surface looks the same. Practitioners should stop treating external identity as a single product domain and start treating it as a mixed-actor governance problem.

External identity boundaries now contain both human and non-human trust decisions. The same access boundary may need to support customer self-service, partner delegation, API consumption and agentic execution. That creates a governance burden around authorisation scope, ownership, and revocation that basic CIAM thinking does not solve. The implication is that external IAM roadmaps now need lifecycle and privilege logic, not just better authentication journeys.

Ephemeral external access requires stronger issuance controls than legacy session thinking. When APIs and AI agents are part of the external identity estate, access can be created and consumed faster than traditional review cycles assume. That is a NHI governance problem as much as a human IAM problem, because service access and delegated access can persist outside the intent that created them. Practitioners need controls that understand who or what is receiving access, for how long, and under whose accountability.

External IAM vendors are increasingly competing on breadth of identity coverage, not only sign-in UX. Recognition lists and market signalling reflect a category shift toward platforms that can span customer identity, partner identity and machine identity. For security teams, that means vendor selection now needs to test whether the platform can govern non-human access with the same discipline as human access. The practical conclusion is that breadth without lifecycle control is not enough.

External IAM is converging with machine identity governance. Once APIs and AI agents are treated as external identities, the boundary between CIAM and NHI governance blurs. That does not mean every organisation needs to merge teams, but it does mean access policy, auditability and offboarding criteria must be consistent across identity types. The practitioner takeaway is to align external IAM architecture with the identity subject, not the channel.

From our research library:

• 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.
• Read next: Agentic AI Identity Guide

What this signals

External IAM is now a mixed identity governance problem. As soon as APIs and AI agents sit inside the same external boundary as customers and partners, the real control issue becomes subject type, not channel. Organisations need policy models that distinguish human login from machine authorisation and delegated agent action.

Identity journeys have become the governance unit. The article points to a market where authentication, authorisation and offboarding are no longer separate conversations. The useful architectural question is whether one programme can maintain consistent accountability when the same external platform serves people, service interfaces and AI-driven actors.

Machine access cannot be managed as a customer add-on. External IAM programmes that keep machine identities inside human-centric review processes will miss ownership gaps, revocation delays and privilege scope drift. That is where the programme design needs to change, not just the UI.

For practitioners

• Map external identity types separately Inventory where external access is used by end users, business customers, partner applications, APIs and AI agents, then assign distinct policy rules for each identity class.
• Define ownership for non-human external access Require a named business or technical owner for every external API credential, token or agent interaction path so accountability does not disappear inside a shared platform.
• Tie authorisation to identity purpose Limit access scopes to the specific business function of the external identity, especially when the same platform serves human users and machine actors.
• Build lifecycle checks into external journeys Review provisioning, entitlement changes and revocation paths for external identities so dormant partner, API and agent access is removed when relationships or use cases change.

Key takeaways

• External IAM is expanding from customer-facing authentication into governance for partners, APIs and AI agents.
• The main risk is misclassifying very different external identity subjects as if they all belong in one access model.
• Practitioners should separate ownership, scope and offboarding rules by identity type before scaling the programme.

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.
• Identity Journey: An Identity Journey is the full sequence of authentication and authorization steps a person or machine follows to gain access to a service. It can include signup, login, MFA, recovery, step-up verification, and policy checks, all of which should be designed and governed as one control flow.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

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.