What is a non-human identity (NHI)?

An identity is not the same as the credential used to authenticate it. A service or workload may use a certificate, token, key, or another credential to prove its identity. Those credentials can change or be revoked while the entity remains the same. Microsoft's overview includes software agents such as programs, bots, AI agents, and digital tools; other sources organize these categories differently, so no single taxonomy should be treated as universal.

NHIs can represent different kinds of automated or digital entities. Common examples include:

• Service accounts: accounts used by applications or services to access resources. Their permissions should reflect the service's purpose.
• Workload identities: identities associated with applications, containers, jobs, or services running in cloud or other environments.
• Application identities and service principals: records that allow an application to authenticate and request access in an identity platform.
• Bots and automation: scripts, CI/CD processes, robotic process automation, or integrations that perform tasks without a person signing in for each action.
• Devices: servers or connected devices may have identities used for authentication and communication, depending on the organization's terminology.
• AI agents: an agent that accesses data, tools, or business applications may need an identifiable principal and defined authorization.

These examples describe common usage, not a universal classification. Microsoft, for example, describes machine identities as a specialized type of non-human identity, while other sources may organize the categories differently. The exact meaning should be checked in the relevant standard or platform documentation.

A human identity represents a person. A non-human identity represents an application, workload, service, device, or other non-human principal. That distinction matters because automated entities cannot use the same interactive authentication flows as people and may need credentials issued and managed through different mechanisms.

Machine identity and workload identity do not have one consistent relationship to NHI across the industry. Machine identity may refer to device or service identities; workload identity usually describes an identity assigned to a running application or software workload. Microsoft, for example, treats machine identities as a specialized type of NHI. Other sources may group the terms differently, so treating them as exact synonyms can obscure what entity is actually being identified.

In all cases, keep the principal separate from its credential. A token or certificate is a way to authenticate; it is not necessarily the identity itself.

NHIs can be difficult to govern when an organization does not know which identities exist, what they access, or who is responsible for them. An application may continue to use a service account after its original owner leaves or the integration is no longer needed. If that identity retains broad access, an attacker who obtains its credential may be able to reach resources beyond the application's current purpose.

Credentials also create risk when they are long-lived, shared, or exposed in source code, configuration files, logs, or chat. OWASP's Non-Human Identities Top 10 includes risks such as improper offboarding and secret leakage. These are examples of risk categories, not evidence that every organization experiences them at the same rate.

AI agents can add questions about identity and accountability when they access multiple tools or data sources. NIST's 2026 concept paper on identity and authorization of software and AI agents discusses identification, authorization, auditing, and accountability as issues for further work. It does not establish a universal agent identity standard.

NHI management is an identity lifecycle problem, not only a secrets-storage problem. At a high level, an organization needs to discover the identities it uses, connect each one to an owner and purpose, and understand which resources it can access.

Permissions should be limited to what the entity needs. Credentials should be issued and protected through controlled mechanisms, with shorter lifetimes where the system supports them. Teams can monitor usage and changes, review permissions as applications evolve, and revoke access when an identity is no longer required. This work depends on reliable ownership information: without it, teams may hesitate to remove an identity that appears unused but still supports a critical process.

These are lifecycle principles, not a step-by-step implementation guide. The exact controls vary across platforms, workloads, and organizational requirements. Cloud-native security provides a broader context for identities operating across dynamic cloud systems.

An AI agent that can call tools or access business systems needs an identity and permissions that make its actions distinguishable from anonymous or shared activity. Depending on the workflow, it may act for a user, a service, or a specific task. The system should make clear which principal initiated the action, what access was approved, and how that access can be changed or revoked.

Agents can choose actions dynamically and may interact with several systems during one task. That makes ownership and auditability important, but it does not mean every agent needs the same identity model. The design should reflect the agent's role, the systems it touches, and the level of human oversight. For more on access controls and broader risks, see Mad Devs' article on: