Every company has more identities than employees. Most of them are not people. They are the service account a backup job signs in with, the API key pasted into a pipeline, the OAuth app someone approved during a trial, and now the AI agent that a developer connected to the repository last week.
These are non-human identities. They act, they hold access, and in most companies nobody can say in one sentence what all of them can reach. AI agents make that gap more expensive, because an agent decides at runtime what to do with the access it was given.
In this piece, we will cover:
- What counts as a non-human identity, and where each kind tends to go wrong
- Why AI agents change the problem and do not just add to it
- Three questions that turn a list of identities into something useful
- Where to start this week
What counts as a non-human identity
A non-human identity is any account, key, token or grant that software uses to act on its own. The common kinds look similar from the outside, but they fail in different ways.
| Type | What it is | Acts on behalf of | Where it tends to go wrong |
|---|---|---|---|
| Service account | A non-person account that software uses to sign in. | An application or job | Broad permissions and no named owner |
| API key | A secret string that grants access to an API. | Whoever holds the key | Long-lived and copied into code or chat |
| OAuth app | An app a person has granted access to their data. | The person who clicked yes | A grant that outlives the need for it |
| AI agent | Software that decides and acts with the access it is given. | A person or team | Reaches more than its task requires |
| MCP server | A service that gives agents tools and data access. | The agents that connect to it | Holds credentials and may have no owner |
Notice the third column. A human identity acts for one person. A non-human identity often acts for whoever happens to hold it, and that is the root of most surprises.
Why the number keeps growing
Nobody sets out to create hundreds of machine identities. They accumulate. Every integration needs a credential. Every automation needs an account. Every tool a person tries leaves a grant behind. Nothing in that process asks who will own the result in a year.
Human identities have a lifecycle that someone manages: they join, change teams and leave. Non-human identities usually have none. The key created for a project that ended two years ago still works, because nothing ever told it to stop.
Why AI agents change the problem
An AI agent is a non-human identity, but three things make it different from a script.
- It decides at runtime. A script does what it was written to do. An agent chooses its next step. The access you granted is the limit of what it can do, not a description of what it will do.
- It chains tools. An agent calls other systems, often through MCP servers, and each of them holds credentials of its own. Reach is the sum of the whole chain.
- It borrows access. A coding agent works with the keys and roles of the developer or the pipeline that started it. Nobody granted the agent anything. It inherited it.
This is why counting agents tells you little. What matters is what each one can reach, through which role, and how that changes with the next change you make.
Three questions that make an inventory useful
A list of identities is not yet a security tool. Three questions turn it into one.
- Who owns it? If nobody has claimed an identity, nobody will notice when it changes or when it is no longer needed. Unowned agents are what we call shadow agents.
- What can it reach? Not what it was meant to reach. What the roles, keys and grants it holds actually open, including the ones it gets by assuming another role.
- What changed since the last time we looked? Access drifts. A snapshot is out of date the day after you take it.
These are exactly the questions nerl0 tracks. They ship as suggested questions that you activate, and each one is measured again with every scan, so the answer is a trend and not a one-off.
From inventory to authority
The useful unit is not the identity. It is the path. An agent holds a token, the token can assume a role, the role can read a data store. No single step is wrong on its own. Together they form a route to your most sensitive data, and that route exists whether or not anyone has used it.
In the Security Graph, every hop is an observed relationship: holds, can assume, can read. The path ends at a crown jewel, a data store you have classified as one that matters most. You can read more about how to follow one in How to read the Security Graph.
Where to start this week
- List every agent and MCP server in the platforms you use. Start with the code platform, the identity provider and the cloud account.
- Find the ones nobody owns. Assign an owner or switch them off.
- Name your crown jewels. Pick the few data stores whose exposure would hurt most.
- Trace the routes to them. Fix the shortest route first, then check that it is gone.
Summary
Non-human identities are accounts, keys, tokens and grants that act without a person. AI agents are the newest kind, and the first one that chooses its own steps. An inventory by itself does not help. Ownership, reach and change over time do. Start with the unowned ones and the routes to your crown jewels.
Sascha writes about what AI agents and non-human identities can reach, and builds nerl0 to keep that visible.