What is a non-human identity (NHI)?

By Nolan Sullivan, Founding Growth Engineer

·Published August 19, 2026·Updated September 9, 2026

A non-human identity (NHI) is a digital identity that lets software authenticate and access resources: a service, workload, pipeline, bot, or AI agent. The identity represents the software actor. An API key, OAuth token, or certificate is a credential it presents, while a cloud IAM role defines the permissions it can assume.

The Cloud Security Alliance distinguishes the software actor from the credentials it presents. The distinction between the actor, its credentials, and its permissions matters when you need to know who owns access, what can be rotated, and what must be revoked. Vendors use the term “NHI” for this problem space, but do not always apply it to the same object.

Human and non-human identities represent different actors and follow different lifecycle and access patterns.

What do IAM vendors mean by NHI?

Vendors agree that NHIs let software access systems, but they draw the line between the identity and its credential differently.

• Okta: NHI includes software actors such as service accounts, bots, and AI agents, as well as credentials such as API keys and tokens. Okta reserves machine identity for infrastructure such as virtual machines, containers, and devices.
• Microsoft: An NHI is a digital identity used by software. Microsoft Entra groups application identities under the term workload identity. Entra Agent ID gives AI agents a separate model because they make dynamic decisions and adapt their behavior.
• CyberArk: NHI and machine identity are often used interchangeably for software actors across infrastructure and applications.
• Palo Alto Networks: Machine identity is used more narrowly for cryptographic identities such as TLS certificates and SSH keys.
• Oasis: NHI covers digital constructs used for machine-to-machine access and authentication.
• Astrix: NHI covers programmable access credentials. MCP servers connect AI agents to external tools and APIs.

These definitions overlap, but they do not always describe the same object. Keeping the credential separate from the identity preserves ownership and attribution when credentials rotate.

The distinction also changes lifecycle management. Human identities usually follow an HR-driven joiner-mover-leaver process for onboarding, role changes, and offboarding. NHIs authenticate programmatically and follow the lifecycle of the software and infrastructure they support.

This scale makes the lifecycle harder to manage. GitGuardian’s State of Secrets Sprawl 2025 found 23.8 million secrets across 1.4 billion public GitHub commits from 2024. Some environments have up to 50 NHIs for every human identity, while machine-identity inventories have reached 82 per employee. These figures count different objects, so they are not directly comparable. They still show that machine access can outnumber workforce access by a wide margin.

The ISO 27001 standard includes Annex A control A.5.16 for identity management. Applying that control to an agent means giving it an identity that is issued, attributable, and revocable.

How do AI agents differ from service accounts and API keys?

A service account is a directory object an application uses to run a job. A workload identity in Entra can be the application, service principal, or managed identity assigned to that workload. An API key or OAuth token is a credential; a machine identity is often a certificate or SSH key bound to infrastructure.

An AI agent can use several of these identity and credential types. It may be created on demand, switch roles, and act as a system or on behalf of a person. That combination calls for an identity model that records an owner, scoped access, and a lifecycle.

The four agent working arrangements classify accountability and engagement. Identity uses a separate security dimension with two common authority patterns:

• Delegated-user authority. Cursor, Claude Code, Copilot, or an internal assistant calls tools on a person’s behalf. The agent should use that person’s delegated permissions. This authority can continue into an unattended individual task.
• Service or workload authority. An agent performs a shared organizational role through a dedicated identity, a human sponsor, and short-lived credentials. This authority can support attended or unattended organization agents.

A hybrid run can use both across different steps. The audit trail must record the principal used for each consequential action.

The Model Context Protocol (MCP) provides the interface. Agents reach internal APIs, SaaS apps, and data stores through MCP servers that expose tools such as get_invoice and create_refund. The identity question is which principal may invoke a given tool, on a given server, in a given session.

A Kubernetes workload and an agent acting through a Cursor session can both authenticate through NHIs. The agent differs because it chooses its next call at runtime and can chain tools that were not fixed in a manifest.

What breaks when an agent uses a shared API key?

Teams often start by placing a shared bot token in the MCP configuration. That weakens four controls that already work for people.

How shared keys obscure attribution

The audit identifies the service account, which hides the person or agent behind an action. A legacy OAuth application played a role in Microsoft’s 2024 Midnight Blizzard incident, and a service-account password saved to a personal Google account exposed files associated with 134 Okta customers in 2023. The same attribution gap leaves no clear answer to who authorized an agent’s refund.

How shared keys expand permissions

The shared key is granted the union of every task on the team. get_invoice and create_refund travel on the same secret. NHI5 covers overprivileged identities, and NHI9 covers NHI reuse. Per-tool policy cannot distinguish callers when every agent presents the same credential and principal.

Why shared keys complicate offboarding

Keys can outlive the people responsible for them. An HR system may deprovision a person without removing a key stored in a configuration file. Secrets management covers where the key lives. NHI lifecycle management covers why the identity exists, who owns it, and when to delete it. Vaulting the key does not name the actor or end the session when the owner is deprovisioned.

How long-lived keys extend session risk

NHI7:2025 covers long-lived secrets. Workload identity federation, Azure managed identities, AWS IAM roles, and SPIFFE Verifiable Identity Documents (SVIDs) exist because standing secrets are already the wrong default for workloads. A year-old organization API key applies that default to an agent that prompt injection could induce to use it.

Privileged access management (PAM) can vault secrets, broker sessions, and provide just-in-time access for human and machine identities. It improves secret handling, but a shared bot token still hides the individual caller at the MCP tool boundary. PAM or another enforcement layer must link each action to the responsible person or agent. For agents, applying ISO 27001 A.8.3 means enforcing that link when the tool is called.

How should IAM extend to AI agents?

The identity and access management (IAM) concepts are familiar, but enforcement has to extend into the agent session.

Use SSO for delegated sessions

The person behind delegated-user authority signs in through Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, or another SAML or OIDC provider. Directory groups inform their role. With session revocation configured, deprovisioning that person in the identity provider (IdP) ends access based on their delegation. Agents using service or workload authority get a dedicated identity with a named human sponsor.

Issue short-lived credentials for tool calls

Replace the standing API key with a short-lived token scoped to the agent session and target server. Federation and managed identities already use this pattern for continuous integration (CI) and cloud compute. Evaluate authorization separately on every tool call.

Enforce least privilege for each tool

Connecting to an MCP server requires one authorization, and calling a destructive tool on that server requires another. Reads and writes use different grants, with a matching deny taking precedence. This is role-based access control (RBAC) applied to the tool name and its disposition, such as read_only or destructive.

Record each authorization decision

Each authorization record should capture:

• The directory identity.
• The server, tool, and arguments.
• Whether the call was allowed or denied.
• The rule used to reach that decision.

This record supports ISO 27001 A.8.15 for logging and A.5.16 for identity management. A service-account row in a security information and event management (SIEM) system cannot show which person or agent made the call.

The IdP remains the source of identity after the person signs in. An enforcement point in the tool path then uses directory attributes, such as groups and roles, to evaluate every call the agent makes.

Where does the AI Control Plane sit?

Once identity has to be evaluated on the tool call, the organization needs a point in the path that sees the caller, server, and tool before execution. The AI Control Plane provides that point.

The Speakeasy AI Control Plane puts an organization’s existing identity system on that path. Agents reach tools through managed or self-hosted MCP endpoints. For delegated-user authority, the person signs in through the organization’s IdP. For service or workload authority, an agent can prove its identity with a platform identity, registered key, IdP assertion, or SPIFFE.

Speakeasy represents policy as a grant with a scope and selector for the server, tool, and disposition. Its telemetry includes the caller’s directory identity. When authorization-challenge logging is enabled, it also records allow-or-deny decisions.

For the product view, see our agent identity guide. Our agent authorization guide and the agent governance guide follow the authorization path to a single MCP tool call.

An NHI is an identity for software. An agent identity can represent software acting for a user or as a machine. Its access still needs authorization for each tool.

To see SSO, per-tool grants, and identity-linked audit records on the path an agent takes, talk to us.