A non-human identity is access without a person attached. Every organization runs on them: the account the backup job uses, the key the deployment pipeline holds, the token a marketing tool was granted to read the CRM. The bot posting alerts into a channel is one, and so is the AI agent an engineer connected to production last month. Each one authenticates, each one holds permissions, and none of them has a manager, an employment record or a day on which HR says they have left.
identities
|
+---------------+----------------+
| |
people non-human
(HR record, manager, (no record, no manager,
a leaving date) no leaving date)
|
+----------------+-----------------+----------------+-------------+
| | | | |
service accounts API keys and OAuth apps bots AI agents
(the backup job, tokens (the (approved with (alerts in (decide at
the sync user) deploy key) one click) a channel) runtime)What counts as a non-human identity?
Five kinds cover most of what a company will find, and each is found in a different place and revoked in a different way.
| Kind | What it is | Where it is created | How it authenticates | How it is revoked |
|---|---|---|---|---|
| Service account | An account inside a system, created for a process rather than a person | The directory, the cloud console, the database, the application | Password, key or certificate | Disable the account; rotate or delete the secret |
| API key or token | A credential with no account behind it, issued to a script or integration | The application's developer settings, often by one engineer | The key itself, on every request | Revoke the key in the application that issued it |
| OAuth grant | A third-party application an employee authorized with a consent screen | The identity provider or workspace suite, by any employee who clicks accept | A refresh token holding a delegated slice of the employee's access | Revoke the grant in the workspace admin console |
| Bot | An automated account in a chat or collaboration tool | The tool's app directory or admin console | A bot token | Uninstall the app or revoke the token |
| AI agent | Software that decides at runtime which of its permissions to use | A coding tool, an automation platform, a chat platform, an internal deployment | Whatever it was given: a service account, keys, grants, or the creator's own session | Every credential it holds, individually |
Service accounts
Accounts inside a system, created for a process rather than a person. They range from the directory account a scanner uses to the integration user in the data warehouse. They are the oldest kind and the most familiar, and a thread on the subject shows how divided practitioners are about them:
Something I don't understand is the absolute phobia of service accounts. There are things that need to happen regardless of who is doing it. Emails need to get sent every day with reports, for example.
API keys and tokens
Credentials without an account behind them, issued to a script or an integration and often pasted into a configuration file once and forgotten. They are the kind most likely to be long-lived, because nothing expires them and nothing prompts anyone to.
Literally every single "security" framework uses God-mode long-lived tokens for non-human identities.
OAuth grants
Third-party applications an employee authorized with a consent screen, holding a delegated slice of that employee's access. Each grant survives a password reset, and many survive the employee leaving, because the token belongs to the grant and not to the session.
Bots
The automated accounts in chat and collaboration tools. Most are harmless. The ones that can read every channel or act on behalf of the workspace are not.
AI agents
The newest kind, and the most demanding, because an agent decides at runtime which of its permissions to use. The scope of its access is therefore the primary control rather than one control among several. A commenter on a thread about a coding agent that wiped a machine put the governing principle in one line:
Treat each agent like a non human identity, give it just enough privilege to perform its task and monitor its behavior.
Machine identity and workload identity are narrower terms from infrastructure security, covering the certificates and keys that servers, containers and devices use to prove who they are. For a company whose systems are mostly SaaS, the NHIs that matter are the SaaS kinds: service accounts, tokens, grants, bots and agents.
Why do ordinary controls miss them?
Every lifecycle control assumes a person, and each assumption fails in a specific way for a non-human identity.
| Control | The assumption | Why it misses an NHI |
|---|---|---|
| Onboarding | Access starts from an HR record | An NHI is created by an engineer solving a problem on a Tuesday, with no record anywhere |
| Offboarding | Access ends on a termination date | An NHI has no termination date, and nothing connects it to the employment of whoever created it |
| Access review | Each row routes to a manager | An NHI has no manager, so the row is skipped or routed to nobody |
| MFA | A human answers a prompt on a phone | There is no human and no phone |
| Dormancy check | Last login shows disuse | Most systems record no last login for a token or a service account |
| Password expiry | A person changes it when prompted | Expiry is usually disabled so the job does not break at 3 a.m. |
The assumption underneath all six
Every control in the table rests on one of two things: an HR event that opens or closes the identity, or a human who can be asked about it. A non-human identity offers neither, and the gap starts at the beginning of its life. Its creation event is an engineer solving a problem on a Tuesday, recorded nowhere except in the configuration file that now holds the secret. Its closing event does not exist at all, because nothing in the company calendar corresponds to a job that no longer needs an account. The identity therefore enters the stack below the level any lifecycle process can see, and stays there until something goes wrong or an auditor samples it.
Where the misses concentrate
The result is the pattern the OWASP Non-Human Identities Top 10 ranks first: improper offboarding, meaning NHIs that outlive their purpose and their owner. The concentration has a mechanical cause rather than a cultural one. A departure checklist covers what the person held, and a non-human identity is something the person created, which is a different relationship and one no system records. Reconciling accounts against the HR roster finds the leaver's own logins and never flags the token they issued, the bot they installed or the integration they authorized, because none of those carries their employment record. The population that survives a departure is therefore the population nobody was looking for.
Where do NHIs live in a SaaS stack?
The inventory is spread across every admin console rather than sitting in one place.
The places to look
- The identity provider holds its own API tokens and the service accounts that sync directories.
- The workspace suite holds service accounts, enterprise applications and the OAuth grants employees have consented to.
- The chat and collaboration tools hold bots and installed apps.
- The code host holds machine users, deploy keys and personal access tokens.
- The data warehouse and the databases hold users with no email address.
- The cloud consoles hold roles, keys and workload identities.
- The automation platforms hold connections that carry a real person's credentials.
- The AI tooling holds agent configurations, each with whatever credentials were pasted in.
Why the exports do not add up
Listing them means visiting each of those places, and the visit is the first step most companies have not taken. The second step is harder, because the exports do not share a key. A service account has an email address in one system and only a numeric identifier in another. An API key has a label, a creation date and no subject at all. An OAuth grant is filed against the employee who consented rather than against the application that received the access. One integration can therefore appear three times, as a bot in the chat tool, a grant in the workspace suite and a machine user in the code host, while appearing nowhere as a single thing with a single owner. Deduplicating that by hand is why the count of non-human identities is usually quoted as a range rather than a number.
Iden's Identities screen tabs every identity as human or non-human and lists service accounts, integration users and agent tokens in the same table as employees, each with a team, an owner and the applications it can reach. The inventory this page says most companies have never taken is the default view, read from each connected application rather than from the identity provider. The feature behind it is Service accounts, API keys and agents.
433 identities. 321 human, 112 not. cc_github and the MCP token sit in the same table as Amy Lee, with the same columns and the same offboarding states.
What does governing them require?
Three things, applied to every NHI without exception.
1An owner
A named human who can say what the identity is for and who is asked when it is reviewed. An identity with no owner is by definition orphaned, and it is removed. The owner is usually the owner of the process the identity serves, not whoever created it.
2A scope and an expiry
The smallest access the job needs, and a date on which the identity is re-justified or dies. Standing access with no end is where creep and compromise both start. Short-lived, narrowly scoped credentials issued on demand remove the rotation problem by removing the thing that needs rotating.
3A place in the lifecycle
The identity is created through the same path as a person's access and appears in the same review. It is revoked or reassigned when its owner leaves. Every departure triggers a check of what that person created, not only what they held.
How does SCIM treat non-human identities?
It does not, and that is the whole problem.
What the protocol models
SCIM defines two resource types, users and groups, and provisions them from a directory into applications that expose an endpoint. The schema has no resource for a credential, a delegated grant or an agent, so nothing in the protocol describes the population this page is about. That is not an oversight in the specification. SCIM is a synchronisation channel between a directory and an application, and it carries what the directory holds, which is people and the collections people belong to.
What that leaves to be done another way
Service accounts, tokens, grants and agents are created inside applications by other paths and never pass through the identity provider, which is why they are invisible to it. Governing them therefore means connecting to each application directly and reading its account list, its tokens and its authorized apps, whether or not the application has SCIM. The read has to be the application's own view rather than the directory's, because the directory can only report the assignments it made, and every identity on this page was created without asking it.