Table of Contents
A non-human identity (NHI) is any digital identity that isn’t tied to a human user. The term covers:
Devices (IoT sensors, mobile endpoints, desktops)
Software workloads (microservices, containers, serverless functions)
AI agents (autonomous or semi-autonomous software entities)
Gartner’s IAM taxonomy of NHIs places NHI at the top of a hierarchy that includes everything from RFID-tagged animals in agriculture to organizational legal entities. But in the systems most developers work with day to day, non-human identity translates to things like API keys, OAuth clients, X.509 certificates, SSH keys, and bot accounts.
This post examines what non-human identity means for the majority of developers: how NHIs relate to machine identities, where AI agents break the traditional model, and the authentication flows used to secure machine-to-machine communication.
NHI vs. machine identity
The terms “non-human identity” and “machine identity” are often used interchangeably, but they describe different tiers of the same idea. Gartner’s taxonomy places NHI at the top, with machine identity as a subset covering devices and workloads. Other NHI branches include non-machine NHIs (like the aforementioned animals and legal entities), but these are edge cases outside the scope of most software teams.
The distinction between NHI and machine identity matters because the market has muddied it. Gartner observed that the term “NHI” is often used as a buzzword by vendors offering workload IAM capabilities, broadening the label beyond its functional meaning. This is worth bearing in mind when evaluating vendor claims: “NHI” can refer to a comprehensive non-human identity framework, a certificate lifecycle management tool with ambitious branding, or something in between.
This post uses “NHI” as the operative term throughout, with the understanding that the NHIs most software teams actually deal with fall into three practical categories: devices, workloads, and AI agents.
NHI types and risk surface
The NHIs most developers encounter break down along two dimensions: what they are and how they handle authentication.
Device identities cover physical hardware: desktops, mobile endpoints, IoT sensors, and operational technology (OT) equipment. These NHIs are simpler in practice and typically rely on certificate lifecycle management. The credential surface is simpler and narrow, and the solutions for controlling it are well-established.
Workload identities cover the software side: applications, bots, virtual machines, containers, serverless functions, and service accounts. Workload NHIs use a much wider range of credentials, including OAuth tokens, JWTs, API keys, personal access tokens (PATs), encryption keys, and SSH keys. This diversity makes them more complex and harder to govern.
Security teams need to manage identities for both humans and non-humans, but the NHI side is where the most urgent risk surface is concentrated. According to a Cloud Security Alliance study, non-human identities outnumber human identities by roughly 20 to 1 in most cloud-native organizations. Only 15% of organizations expressed high confidence in their ability to secure NHIs, and nearly 1 in 5 organizations reported having a security incident related to them.
NHIs exist with good reason, mostly in service of automating workflows and enabling system-to-system communication. But they’re frequently a target for credential-based attacks due to several recurring patterns:
Excessive permissioning
Inconsistent lifecycle management
Lack of centralized governance
Fragmented creation by different teams using different tools
The credential diversity of workload NHIs leads to cascading challenges: a single microservice might rely on OAuth client credentials for service-to-service calls, APIs for third-party integrations, and certificates for mTLS between internal services. Each credential type has its own rotation parameters, storage requirements, and revocation mechanisms. Without a unified approach, gaps are inevitable.
AI agents are the newest addition to the NHI landscape. Unlike devices and workloads, agents are dynamic and can move across multiple systems with minimal or (zero) human direction. They’re technically workload NHIs in the Gartner taxonomy, but their behavior diverges enough from traditional workloads that they warrant their own identity treatment in our view.
Where AI agents break the traditional NHI model
The NHI categories above (devices and workloads) were designed for a world where the entity requesting access is a deterministic process following a fixed set of instructions. AI agents break that assumption because they are non-deterministic. An AI agent operates autonomously or semi-autonomously, making decisions and taking actions across multiple systems without step-by-step human direction.
Traditional, static NHIs (for example) call the same API with the same credentials in the same predictable pattern. Agents are dynamic and decide what to call, when, and why, based on their current context and objectives. This creates the need for a fundamentally different identity approach.
| Human identities | Traditional NHIs (devices, workload) | Agent NHIs |
|---|---|---|---|
Behavior | Interactive, UI-driven | Static and deterministic | Dynamic and non-deterministic |
Auth patterns | Knowledge, possession, and inherence-based auth; MFA | OAuth tokens, API keys, M2M flows, certificates | Delegated access, consent flows, MCP |
Scale | Bounded by headcount | Bounded by infrastructure | Autonomous or semi-autonomous at scale |
Access model | Role and group-based | Static scopes and permissions | Function and tool-level access |
The challenge is that neither human identity patterns nor traditional NHI patterns fit agents particularly well:
Human-centric credentials (SSO sessions, passwords) can give agents dangerously broad permissions with limited revocability
Static workload credentials (long-lived API keys, service account tokens) lack the granularity and auditability that autonomous systems need
This gap between traditional models and emerging agentic identity requirements has driven a shift toward treating AI agents as a distinct NHI category. AI agents treated as first-class identities have their own lifecycle, credential model, and access control approach.
In real-world scenarios, this means scoped, short-lived, and auditable credentials issued per-action and per-session rather than long-lived keys shared across workflows. Case in point: the auth spec for the Model Context Protocol (MCP) provides a framework for this pattern by mandating OAuth 2.1, and supporting per-tool scopes and user consent flows for interactive authorization.
For a deeper look at how agentic identity protocols are shaping how agents interact with tools and each other, see our beginner-friendly guides on MCP and the Agent2Agent Protocol.
Machine-to-machine (M2M) authentication flows
Regardless of whether an NHI is a traditional workload or an AI agent, it needs to authenticate before it can access resources. OAuth provides the standard mechanisms for this, with two flows emerging as particularly relevant to NHI security: client credentials and OAuth token exchange.
Client credentials flow
The client credentials flow is the baseline for machine-to-machine authentication. It’s designed for scenarios where no human user is involved.
The flow is relatively simple:
The client (Service A) sends its client ID and client secret to the authorization server.
The authorization server validates the credentials.
If valid, the authorization server returns a JWT (access token) signed with its private key.
Service A uses the JWT to authenticate with Service B (the downstream resource).
One key security advantage is that the client secret is only stored and managed in one place (Service A) and is never transmitted to downstream services. The downstream service validates the JWT’s signature against the authorization server’s public key (JWKS endpoint), verifies the token claims, and grants or denies access based on the scopes present in the token.
Client credentials is the right pattern when both services are known and trusted, the scope of access is well-defined, and there’s no user context to propagate. It’s the flow most organizations start with for internal service-to-service communication.
OAuth token exchange
Token exchange addresses a more complex scenario: what happens when a service needs to act on behalf of a user or another service, potentially across trust boundaries?
OAuth token exchange allows a client to present an existing token (the “subject token”) to an authorization server and receive a new token with different scopes, audiences, or identity context. Optionally, a second “actor token” can be included to represent the party performing the exchange.
Use cases include:
Delegation chains: A frontend service receives a user’s access token and exchanges it for a narrower token scopes to a specific backend API, preserving the user’s identity while reducing permissions at each hop.
Cross-domain federation: A token issued by one authorization server is exchanged for a token valid in a different trust domain.
Scope reduction: A service with broad access exchanges its token for a one with minimal permissions before calling a sensitive downstream resource.
Token exchange is especially relevant for agentic workflows because scopes can be narrowed at each hop. When an AI agent acts on behalf of a user, the delegation chain needs to be explicit and auditable: who authorized the agent, what scope was granted, and which specific downstream resource the token is valid for. Each hop through an exchange produces a token that is more constrained, bound to a specific audience, and narrowed in scope.
Other related auth patterns
Beyond these two core flows, several adjacent modalities appear in NHI and agentic identity contexts, in particular:
CIBA (Client-Initiated Backchannel Authentication): A decoupled flow where the authentication device is separate from the consumption device. CIBA is relevant for AI agents because it enables human-in-the-loop approval without requiring the agent to pause its workflow for a browser redirect.
Dynamic Client Registration (DCR): Allows new clients (including agents) to register with an authorization server programmatically at runtime, which is essential for scaling agentic systems where new agents spin up dynamically.
Client ID Metadata Documents (CIMD): An alternative to DCR (and new default) for scenarios where traditional registration creates overhead and security risks at scale. The client ID is an HTTPS URL that points to a JSON document containing the client’s metadata.
Cross-App Access (XAA / ID-JAG): An emerging OAuth extension that uses IdP-mediated JWT assertions to grant short-lived, scoped API access across enterprise applications without requiring user-facing consent flows for each integration.
Handling non-human identity in the agentic era
NHI is the fastest-growing (and riskiest) segment of the modern identity surface. The sheer scope (workloads, devices, AI agents) is stretching traditional IAM models in ways that demand fundamental shifts in how organizations handle credential lifecycles, delegation patterns, and policy enforcement. Getting M2M authentication right starts with understanding which flows apply to your architecture, which credential types your NHIs actually need, and how the bigger picture fits together.
To see how Descope solves M2M authentication, agentic identity, and non-human identity management, sign up for a Free Forever account, join our AuthTown dev community, or explore the Agentic Identity Hub.
