Glossary / AI securityAlso: NHI

Non-Human Identity

The term is written both ways, non-human identity and nonhuman identity, and abbreviated NHI. It covers anything that authenticates and acts without being a person: service accounts, API keys, OAuth tokens, CI runners, scheduled jobs, RPA bots, and now AI agents. If it can log in and change something, and it does not have a manager, it is one of these.

CyberArk's 2025 identity research found machine identities outnumber human ones by more than 82 to 1, with a large share holding privileged access, yet most organizations still define a privileged user as human only. That definitional gap is the whole problem: access reviews, joiner-mover-leaver processes and privileged-access tooling were all designed around employees, so the identities that now do most of the acting are the ones nobody reviews.

AI agents make this sharper than earlier automation did, because an agent decides what to do rather than replaying a fixed script. A service account running a nightly sync can only ever do the one thing it was written to do. An agent holding the same credentials can do anything those credentials permit, including things nobody anticipated when the access was granted.

The fix for AI agents specifically is to give each agent its own scoped identity rather than a shared service account or a borrowed human login. That makes every action attributable, lets you disable one agent without locking out a person, and keeps its permissions reasonable. Each identity should also have a named human owner, credentials that expire rather than live forever, and a place in the same access reviews that cover staff. How we implement that is in scoped agent identity.

Why does an AI agent need its own identity?

Attribution. If an agent acts using a person credentials, then in every log it touches its actions are that person actions, and after an incident you cannot separate what the human did from what the software did. Its own identity also means its access can be scoped, reviewed, and revoked independently, none of which is possible when it is borrowing someone else account.

What goes wrong when several agents share one service account?

You lose the ability to act on any one of them. Revoking access to stop a misbehaving agent takes down every other process using the same account, so in practice nobody revokes it. Permissions drift upward to the union of everything that account has ever needed. And when something writes a bad record, the log tells you which account did it and not which job, which is the question you actually need answered.

How should non-human identities be governed?

The same way privileged human accounts are, with the additions that machines need: a named human owner for each one, credentials scoped to a single job, rotation and expiry rather than permanent keys, and inclusion in access reviews. The common failure is that access-review processes were written with employees in mind and quietly exclude the identities that now outnumber them.

From definition to a working system

Mindlyft is the approval and audit layer over your AI GTM agents, every action drafted, human-approved, reversible, and logged. Start with a free 30-minute GTM Engineering Review.

Get your free review

Free GTM Engineering Review

Thirty minutes on your GTM engine.Free. No pitch deck.

A working session, not a sales call. We map where your company's knowledge lives, where promises leak, and the first systems we would build, and we tell you straight if it is not worth doing yet.

Or pick a time