Most identity programs are built around people.
An employee joins, receives access, changes roles, and eventually leaves. Ideally, their permissions follow the same lifecycle.
Machines are less cooperative.
Applications, automation pipelines, cloud workloads, bots, integrations and AI agents also need access to systems. They authenticate, receive permissions and interact with sensitive resources, but they rarely submit an offboarding request when the project that created them disappears.
Welcome to the world of Non-Human Identities.
What Is a Non-Human Identity?
A Non-Human Identity, or NHI, represents a software component or machine that needs to authenticate and access another system without a person directly performing the action.
Examples include service accounts, applications, CI/CD pipelines, cloud workloads, bots and AI agents.
These identities usually authenticate through credentials such as API keys, tokens or certificates. The distinction matters: the workload is the identity, while the token or key is the credential proving that identity.
For example:
Payment Service -> Service Identity -> Temporary Credential -> Payment Database
Standards such as SPIFFE were created specifically to provide cryptographic identities to workloads across distributed environments. (spiffe.io)
Why Non-Human Identities Are Different
Human identities usually have obvious owners and lifecycle events.
Someone joins the company, changes departments or leaves.
A service account created for a deployment script may simply continue existing.
Now multiply that across cloud environments, Kubernetes clusters, SaaS integrations, pipelines and internal services.
The problem becomes less about creating identities and more about answering basic questions:
Who owns this identity? Why does it exist? What can it access? Is it still being used?
If nobody can answer those questions, the identity has effectively become an invisible user with permissions.
The Main Security Risks
One of the biggest problems is long-lived credentials.
An API key created once and stored in a configuration file may remain valid for years. If it leaks through source code, logs, backups or a compromised system, an attacker may inherit the same access as the application.
Excessive privilege creates another problem. A workload that only needs to read one storage bucket may receive broad cloud permissions because configuring precise access takes more effort.
And unlike employees, machine identities are easily forgotten.
A project can be retired while its credentials, service accounts and permissions remain active.
AI agents make the problem even more important. In 2026, NIST began work specifically around identity and authorization for software and AI agents, highlighting the risks created when autonomous software receives access to applications, tools and data. NIST’s software and AI agent identity initiative (NIST Segurança Computacional)
Why Human-Centric IAM Processes Are Not Enough
Traditional IAM practices often revolve around employee lifecycle:
Join -> Access -> Role change -> Offboarding
Non-human identities need the same lifecycle discipline, but their events are different.
A workload may be deployed, replaced, migrated or permanently removed. Its identity and permissions should change with it.
This means NHI management cannot depend on someone eventually remembering to delete an old service account.
Ownership and expiration must be designed from the beginning.
What Good NHI Security Looks Like
A useful rule is simple:
Every non-human identity should have an owner, purpose, scope and lifecycle.
Organizations should maintain an inventory of machine identities and connect each one to the workload or service that requires it. Permissions should follow least privilege, limiting access to exactly what the workload needs.
Whenever possible, static credentials should also be replaced by short-lived credentials.
AWS, for example, recommends temporary credentials for workloads instead of distributing long-term access keys. Temporary credentials automatically expire, reducing how long a stolen credential remains useful. AWS IAM security best practices (AWS Docs)
Machine identities should also be monitored like human accounts. Unexpected access patterns, unusual resources and unused identities can all indicate that something is wrong.
Finally, when the workload disappears, its identity should disappear with it.
Conclusion
Non-Human Identities are not a new type of exotic attack. They are a consequence of modern systems becoming increasingly automated.
Every application, workload, bot and AI agent that accesses something important needs an identity. And every identity eventually becomes a security problem if nobody knows why it exists.
Human employees usually get an exit interview.
That forgotten service account created three years ago does not.
Unfortunately, it may still have administrator access.