A non-human identity is not a new thing in your environment. It is a thing you already have, in numbers you have probably never counted, and the secrets leaking out of your code and your SaaS tools are the clearest evidence of where those identities are and what they can do.

The term arrives before the concept does

Ask a security team how many non-human identities they have and you will usually get a pause. Ask the same team how many service accounts, API keys, CI/CD tokens, bots, scripts and integrations are running in their environment, and the pause turns into a different kind of answer: a lot, and nobody has the full list.

That gap is the whole problem with the phrase. The industry adopted a category name faster than most practitioners adopted the concept, so the term lands as a new product to evaluate rather than a description of something already running in production.

It is not a new thing to buy. It is a population you already have.

Three parts, and most people only see one

A non-human identity is any identity that acts on a system without a person sitting behind it. The deploy pipeline that pushes to production. The script that pulls from the data warehouse at 3am. The agent that files a ticket when a check fails. The integration that reads a Slack channel.

Each one has three parts, and they get collapsed together in conversation even though they behave very differently:

The permissions sit with the identity. The secret is what proves you are allowed to use them. That distinction matters because it explains why a leaked secret is not a code cleanliness problem. Removing the secret from a file changes nothing about the identity it authenticates or the access that identity still holds.

It also explains the scale. Palo Alto Networks put the ratio at 109 non-human identities for every human one. Every organization is running a workforce it never hired and mostly never inventoried.

Nobody built the inventory, so the leaks have to serve as one

Human identities arrive through a process. Someone is hired, an account is provisioned, access is reviewed, and the account is removed when they leave. Non-human identities arrive when an engineer needs something to work. A key is generated, pasted where it is needed, and the thing starts running. There is no joiner process, no review cycle, and frequently no record of who created it or why.

This is why secrets are the most useful evidence available. A secret is the one part of a non-human identity that leaves a trail in places you can actually search. It gets committed, pasted into a ticket, dropped in a Slack thread, baked into a container image, written to a CI log.

Attackers have noticed. The NHI Mgmt Group analyzed more than 200 breaches involving non-human identities and found that secrets and passwords were the most exploited identity type, showing up in 84 of them. In September we found a GitLab token in a public CI artifact that held Owner access to 55 projects, including GnuTLS and Nettle. We also found 768 leaked corporate AWS keys with full administrative rights that were still active.

Every one of those is a pointer to an identity. Follow the secret and you find a thing that is running, holds access, and was not on anyone’s list.

Three questions turn a finding into a priority

A list of exposed secrets with no further information is not a priority list. Every entry looks the same, so teams either work it top to bottom or stop working it at all. Three questions separate the items that matter:

Is it live? A secret that no longer authenticates anything is a housekeeping item. A secret that still works is an open door. This is the difference between a finding and an exposure, and it is answerable: call the provider and see whether the secret still works. Everything found still gets surfaced. What liveness changes is what you get alerted on.

What can the identity do? Read access to one bucket and administrative rights across an organization produce the same looking string. The permissions sit with the identity, so the answer comes from resolving the identity behind the secret and reading its access. That is what separates an urgent item from a routine one.

Who can revoke it? The person who leaked a secret is often not the person who created the identity, and only the owner can rotate it. Notify the wrong person and you tend to get a scrubbed commit rather than a revoked key, which looks like remediation and is not.

Answer those three and prioritization stops being a judgment call about which findings look scary. It becomes a ranking of identities by what they can reach.

Revocation is what ends it

There is one action that removes a non-human identity’s exposure, and it is revoking the secret that authenticates it. Deleting a line of code does not do it. Rewriting history does not do it. Closing the ticket certainly does not do it, and we have measured how often teams believe otherwise: in more than half the cases where developers removed the file exposing a secret, they never rotated the key. A deleted commit stays reachable through the GitHub API, so the secret keeps working while the ticket shows closed.

So the proof is a test, not a closed ticket: check the secret again after the fix and confirm it no longer authenticates.

This is also why the AI conversation and the non-human identity conversation are the same conversation. Agents are non-human identities. Non-human identities run on secrets. When Anthropic documented a campaign where an AI system executed 80 to 90% of the operations autonomously, what the system was using to move through environments was the same thing every automated process uses: a secret that still worked.

So the practical starting point is not a new inventory project. It is the secrets you are already finding, treated as what they are: evidence of identities that are running, hold access, and need an owner and an off switch.

TruffleHog Enterprise is built around that sequence. Find the secrets across code, SaaS, CI/CD and cloud, confirm which ones are live, resolve the identity and permissions behind them, route them to the person who can revoke them, and verify the revocation happened.