By Nolan Sullivan, Founding Growth EngineerA non-human identity (NHI) is a digital identity that authenticates and is authorized to access resources on behalf of software rather than a person: a service, a workload, a pipeline, a bot, or an AI agent. The identity is the actor; the API key, OAuth token, certificate, or cloud IAM role is the credential it presents.
The Cloud Security Alliance’s July 2026 paper Defining Non-Human Identity is explicit: an entity is an NHI only when it can authenticate and be authorized, and an API key is not itself the identity. Okta, Microsoft Entra, CyberArk, Oasis, and Astrix all use “NHI” for this problem space, then put different objects in the bag.
What do IAM vendors mean by NHI?
Okta (31 July 2025) calls NHIs “digital credentials assigned to machines, applications, and automated processes”: service accounts, API keys and tokens, machine identities, cloud workload identities, bots. Its lifecycle page (20 February 2026) adds AI agents. Machine identity, for Okta, is the infrastructure subset (VMs, containers, devices). Microsoft calls an NHI “a digital identity used by software.” In Entra that software side is a workload identity (application, service principal, managed identity). Microsoft now ships Entra Agent ID separately, because agents “make dynamic decisions and adapt behavior.”
CyberArk publishes NHIs as digital entities used to identify, authenticate, and authorize machines, devices, infrastructure, applications, workloads, and automated processes, and often uses NHI and machine identity interchangeably. Oasis: “a digital construct used for machine-to-machine access and authentication.” Astrix (Cisco): “digital, automated and programmable access credentials.” Astrix now lists AI agents and Model Context Protocol (MCP) servers as adjacent surfaces, not as the same object as a SaaS OAuth app.
NHIs authenticate programmatically. They do not complete MFA or follow an HR joiner-mover-leaver flow; Okta, CyberArk, Oasis, and OWASP all state this. The OWASP Non-Human Identities Top 10 for 2025 ranks the failures that follow, with improper offboarding (NHI1) first. GitGuardian’s State of Secrets Sprawl 2025 found 23.8 million secrets committed to public GitHub in 2024 (1.4 billion commits). Okta cites NHIs outnumbering humans by up to 50 to 1 in some environments; CyberArk’s 2025 State of Machine Identity Security reported 82 machine identities per employee. Those ratios count different objects. They agree on the direction.
ISO/IEC 27001:2022 Annex A control A.5.16 already requires identity management. An agent is an identity under that control: issued, attributable, revocable. See ISO 27001 for agentic AI.
How do AI agents differ from service accounts and API keys?
A service account is a directory object used by an application to run a job. A workload identity in Entra is the application, service principal, or managed identity assigned to that job. An API key or OAuth token is a credential, often with permissions baked into the string. A machine identity in the PKI sense is a certificate or SSH key bound to a host.
An AI agent sits across those classes. Microsoft’s security-101 page calls agents “an emerging class of non-human identities” that can be created on demand, switch roles, and act as a system or on behalf of a person. Entra Agent ID is the directory product that follows. Okta ISPM inventories “AI agents that users create” next to service accounts and tokens.
Two modes, both already in production:
- Delegated. A person is driving. Cursor, Claude Code, Copilot, or an internal assistant calls tools in that person’s session. The correct identity is the person’s directory account, scoped to the tools their role may use.
- Autonomous. No person is in the loop. A scheduled worker or multi-agent workflow runs against production. The correct identity is a dedicated, owned, short-lived machine identity with a human sponsor, the model Entra Agent ID calls “enforced human sponsorship.”
MCP is the wire. Agents reach internal APIs, SaaS apps, and data stores through MCP servers that expose tools (get_invoice, create_refund). The identity question is which principal may invoke this tool, on this server, in this session.
A Kubernetes service account that pulls an image and a Cursor session that posts a refund are both NHIs in the vendor glossaries. Only the second chooses its next call at runtime and can chain tools nobody named in a manifest. That is why Entra split Agent ID from Workload ID.
What breaks if an agent uses a shared API key?
The common rollout is a bot token in the MCP config, shared across the team. Four controls that already work for people then fail.
Attribution. The audit reads as the service account. OWASP cites Microsoft’s January 2024 Midnight Blizzard intrusion (a legacy OAuth app in a test tenant) and Okta’s November 2023 support-system breach (a service-account password saved to a personal Google account, 134 customers’ files). After an agent issues a refund, “the billing bot did it” is the same answer.
Least privilege. The shared key is granted the union of every task on the team. get_invoice and create_refund travel on one secret. Those are OWASP NHI5 (overprivileged) and NHI9 (reuse). Per-tool policy cannot attach to a credential every agent presents as the same principal.
Lifecycle. People leave. Keys do not. OWASP ranks improper offboarding first (NHI1:2025). There is no HR event for a config file. Okta separates secrets management (where the key lives) from NHI lifecycle (why the identity exists, who owns it, when it is deleted). Vaulting the key does not name the actor or end the session when the owner is deprovisioned.
Session. Standing secrets are NHI7. Workload identity federation, Azure managed identities, AWS IAM roles, and SPIFFE SVIDs exist because standing secrets are already the wrong default for workloads. An agent holding a year-old org API key is that default, applied to a caller that can be prompt-injected into using it.
The PAM objection is that the vault already covers this. PAM stores the secret and brokers privileged human sessions. It does not evaluate create_refund against the person driving Claude, at call time. ISO 27001 A.8.3 for agents is a per-tool-call control, and a shared key has no principal to attach that control to.
How does IAM extend to agents?
The controls are the ones the IdP already runs. They have to bind to the agent session.
SSO into the session. The person behind a delegated agent signs in through Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, or any SAML / OIDC provider. Directory groups become the role. Deprovisioning in the IdP ends agent access with email. Autonomous agents get a dedicated identity with a named human sponsor.
Short-lived credentials at the tool. Replace the standing API key with a token issued for this session, this server, and this call. Federation and managed identities are the pattern for CI and cloud compute. Agents need the same property: the credential dies with the session.
Least privilege per tool, not per server. Connecting to an MCP server is one authorization. Calling a destructive tool on it is another. Reads and writes are different grants. A matching deny wins. That is ordinary RBAC applied to tool name and disposition (read_only, destructive).
One record. Who (directory identity), what (server, tool, arguments), whether (allow or deny), under which rule. ISO 27001 A.8.15 (logging) and A.5.16 both ask for this. A service-account row in the SIEM does not, once the actor is an agent.
The IdP you already operate has to stay in the path after the human has signed in, for every tool call the agent makes.
Where does the Speakeasy AI Control Plane sit?
Once identity has to be evaluated on the tool call, you need a place in the path that sees the caller, the server, and the tool before execution. That place is the AI Control Plane.
The Speakeasy AI Control Plane is the platform that puts existing enterprise identity on that path. Agents reach tools through Speakeasy-hosted MCP endpoints. The person, or the sponsored autonomous identity, authenticates through the IdP the organization already runs. Policy is a grant: a scope plus a selector for server, tool, and disposition. Every allow or deny is recorded against a directory snapshot, not a token id.
The commercial page is agent identity. The path from IdP to a single MCP tool call is in From your IdP to a tool call and the governance guide. This page stops at the definition: NHI is an identity for software, and an agent is an NHI that can act as a user or as a machine and has to be authorized per tool.
To see SSO, per-tool grants, and identity-stamped audit on the path an agent takes, talk to us.