A non-human identity (NHI) is an identity belonging to a service, workload, machine, or AI agent rather than a person. NHIs include service accounts, API keys, machine certificates, OAuth client identities, and now AI agents acting either on behalf of a user or autonomously.
- An identity belonging to a service, workload, machine, or AI agent
- Already outnumbers human identities in most mature enterprises
- Agents are the hard subset, because they exercise judgment a role cannot
- OWASP names the resulting risk excessive agency, LLM06
Why is non-human identity important?
Non-human identities already outnumber human identities in most mature enterprise environments, and the ratio climbs sharply wherever agents are being deployed. That shift matters because identity governance was designed around a population of people who join, change role, and leave on predictable cycles, reviewed by managers who know what the person does.
AI agents introduce a subset that breaks the model rather than merely enlarging it. A service account does what it was configured to do. An agent inherits the full permissions of the role it was given and then operates with judgment the identity system was never asked to evaluate. Nothing in an access review anticipates an identity that decides what to do next.
OWASP names the consequence directly as excessive agency, LLM06 in the Top 10 for LLM Applications: an agent granted more capability, permission, or autonomy than its task requires. It is consistently the failure mode behind serious agent incidents, because the agent reached something it should never have been able to reach.
What is a non-human identity?
A non-human identity is any principal that authenticates to a system without being a person. The category is older than AI and has grown considerably faster than the tooling built to manage it.
Five forms are common. Service accounts authenticate applications and background processes. API keys and tokens authenticate programmatic access, often with broad scope and no expiry. Machine and workload certificates authenticate infrastructure. OAuth client identities authenticate applications acting on a user's behalf. And AI agents authenticate to take actions, either under a user's delegated authority or under their own.
The last of those is where existing practice struggles. An agent may present a user-scoped credential, in which case its actions are indistinguishable from that user's in a log, or a service-scoped credential, in which case the actions are attributable to a system rather than to whoever set the agent running. Neither answers the question a security team actually needs answered.
Non-human identity is the broad category; agent identity is the specific discipline of giving agents distinct, traceable principals inside it.
Types of non-human identity
NHIs group usefully by how they authenticate and by how much autonomy they carry.
Static credentials cover long-lived API keys, tokens, and passwords held by services. They are the most common form and the hardest to govern, because they are frequently created outside any provisioning process and rarely retired.
Certificate-based identities cover workloads and infrastructure using cryptographic material with defined validity. They are better governed by design, since expiry forces renewal.
Delegated identities cover OAuth clients and agents acting on a user's behalf, where the difficulty is that authority is borrowed rather than held.
Autonomous identities cover agents acting under their own principal without a human in the request. These are the newest category and the only one where the identity makes decisions.
The distinguishing question across all four is not how the identity authenticates but whether anything evaluates what it does with the access once granted.
Non-human identity & Onyx
Onyx treats every agent as a distinct identity, separate from the user who initiated it. That separation is what makes the governance questions answerable: which agent acted, under whose authority, and with what scope.
Just-in-Time access then evaluates permissions at the request boundary rather than at role assignment. The difference is material for non-human identities specifically, because the standing-permission model is what turns an agent's inherited role into a blast radius. An agent granted access per request holds what a task requires and carries none of it into the next one, which addresses excessive agency at its source rather than detecting it afterward. Agent identity and access governance is where that is operated.
