Non-Human Identities: The Accounts Nobody Owns

Non-human identities (NHIs) are the credentials and accounts that software uses to authenticate: service accounts, API keys, OAuth tokens, certificates, cloud workload identities, bots and, increasingly, AI agents. They outnumber human identities in almost every environment, they usually have more access than they need, and most of them don’t have a clear owner.

That last part is the real problem. Human accounts have a lifecycle tied to HR: someone joins, moves, leaves, and access follows (in theory). A service account created for a project in 2017 has no manager, no termination date and no one who gets an email when it misbehaves. It just keeps working, with whatever access it was given on the day someone needed the project to go live.

What counts as a non-human identity?

The category is broad, which is part of why it gets neglected. Here’s how I break it down:

Type	Examples	Typical credential
Service accounts	AD accounts running Windows services, scheduled tasks, application pools, database connections	Password, often never rotated
API keys and tokens	SaaS integrations, CI/CD pipelines, monitoring tools, OAuth apps granted access to a tenant	Static key or long-lived refresh token
Certificates and keys	TLS certificates, device certificates, SSH keys, code signing keys	Private key
Cloud workload identities	AWS IAM roles, Azure managed identities, GCP service accounts, Kubernetes service accounts	Short-lived tokens issued by the platform (when done well), static keys (when not)
Bots and RPA	Robotic process automation running finance or HR processes, chatbots, scripts	Often a human-style account with a password
AI agents	Assistants and agents that call tools and APIs on a user’s or organization’s behalf	API keys, OAuth tokens, or delegated user credentials

The term “machine identity” overlaps heavily. Some people use it narrowly for certificates and keys, others as a synonym for NHI. I don’t think the distinction matters much in practice. What matters is that each of these is something that authenticates, holds access and can be stolen.

Why do non-human identities outnumber humans?

Every application, integration, pipeline, container and microservice needs to authenticate to something. One new SaaS tool can create several API connections. One Kubernetes cluster can have hundreds of service accounts. Cloud adoption, DevOps and automation all multiply NHIs faster than anyone can catalog them.

You’ll see vendor estimates of the ratio ranging from tens to one to well over a hundred to one. I’d take the specific numbers with some skepticism, since they come from companies selling NHI tools, but the direction isn’t in dispute. In any environment with real cloud and automation footprint, the non-human identities are the majority, and nobody’s reviewing them in access certifications.

A common version of this: Picture a service account named for a project that ended years ago, with a password that never expires and logons every night from a server nobody recognizes. Nobody claims it, so someone proposes disabling it, and the room goes quiet because nobody can rule out that it runs payroll. That hesitation is how these accounts survive for a decade. The way out is covered below: monitor its use, announce a date, disable rather than delete, and let the owner come forward.

What are the risks of machine identities?

The risks are mostly the same ones we’ve fought with human accounts for years, just with fewer controls in place.

Long-lived secrets. A service account password set once and never changed. An API key created three years ago and still valid. A refresh token that doesn’t expire. Static secrets that never rotate are exactly what attackers want, because a stolen one keeps working indefinitely.

Over-permission. NHIs are granted access during a project, often under deadline pressure, and “give it admin and we’ll scope it down later” is a sentence I’ve heard more than once. Later rarely comes. Service accounts in Domain Admins, cloud roles with wildcard permissions and OAuth apps with tenant-wide read access are all common.

Secrets in code and config. Credentials hardcoded in scripts, committed to source repositories, baked into container images, pasted into CI variables or sitting in a config file on a shared drive. Secret scanning tools exist because this happens constantly.

No MFA, no behavioral baseline. NHIs can’t respond to a push prompt. Many identity controls built for people simply don’t apply, so the credential itself is the only thing standing between an attacker and the access.

No owner. When nobody owns an identity, nobody reviews it, nobody rotates it, and nobody notices when it’s used from somewhere new. Ownership is the control everything else depends on.

Weak service account passwords in AD. Worth calling out on its own. Service accounts with SPNs are the target of Kerberoasting, which I covered in What Is ITDR?. A long, random, regularly rotated password defeats it; a password someone chose in 2015 doesn’t.

How do you manage the non-human identity lifecycle?

Treat NHIs like you treat people, adjusted for the fact that they don’t have managers.

1. Creation. Every new NHI gets a request, a purpose, a named human owner and a backup owner. No exceptions for “just a quick test.”
2. Provisioning. Grant the minimum access needed for the stated purpose. Prefer platform-issued, short-lived credentials (managed identities, workload identity federation) over static secrets.
3. Review. Include NHIs in access reviews, with the owner attesting that the identity is still needed and its access still appropriate. If your IGA platform supports non-human account types, use it; if not, at least track them in the same inventory.
4. Rotation. Rotate secrets on a schedule and after any suspected exposure.
5. Ownership transfer. When an owner leaves or changes roles, their NHIs get reassigned as part of the mover/leaver process. This is the step almost everyone misses.
6. Decommissioning. When the application or integration goes away, so does the identity. Disable first, wait, then delete.

For an existing environment, the hard part is the backlog. You’ll find accounts nobody claims. My usual approach is to tag them, monitor their use, announce a disable date, and disable them on that date. The ones that matter tend to find their owners quickly.

Secrets management and vaulting for NHIs

Once you know what you have, get the secrets out of code and config and into a vault. This is where privileged access management and secrets management overlap.

• PAM vaults manage and rotate service account passwords, including updating the services and tasks that use them so rotation doesn’t break anything. This is one of the most valuable and least glamorous things a PAM program does.
• Secrets managers serve credentials to applications and pipelines at runtime, so the secret never lives in the code. Most PAM vendors offer one, and the major cloud providers have native options.
• Dynamic and short-lived credentials go further: the application gets a credential that’s valid for minutes or hours, issued on demand. Nothing static to steal.

The order I’d recommend: vault and rotate the highest-privileged service accounts first, then move application secrets out of code, then work toward short-lived credentials where the platform supports it.

Certificates are machine identities too

Certificates are NHIs too, and they bring their own lifecycle problem: they expire. An expired certificate on an internal service is an outage, and most organizations have a story about the one nobody knew about. An over-permissive certificate template is worse; it’s an attack path, as I covered in the post on AD CS attack paths and ESC1.

This is getting more pressing. Earlier this year the CA/Browser Forum approved a phased reduction in the maximum validity of public TLS certificates, starting in 2026 and reaching 47 days by 2029. Manual renewal won’t survive that schedule. If you don’t have a certificate inventory and automated renewal, now is the time to build them. The PKI post covers the fundamentals.

Are AI agents non-human identities?

Yes, and they’re the newest and least understood class of NHI. An AI agent that can read your email, query a database, open tickets or call APIs is authenticating to those systems with some credential. That makes it an identity, and it needs to be governed like one.

What makes agents different from a traditional service account:

• They act with some autonomy. A script does exactly what it was written to do. An agent decides what to do based on its instructions and inputs, which means its actual behavior is harder to predict and scope in advance.
• They often borrow a human’s access. Many agents run with delegated user permissions through OAuth, so they inherit everything that user can reach.
• They can be manipulated through their inputs. Prompt injection means content an agent reads can influence what it does with its access.

I’d keep this in proportion. Most organizations are still at the pilot stage with agents, and the tooling and standards for agent identity are early. But the basics already apply: give each agent its own identity rather than a shared or borrowed one, scope its permissions to the task, prefer short-lived tokens, log what it does, and make sure a named human owns it. If those principles are in place for your service accounts, extending them to agents is a much smaller step.

My advice: The first design question is whether an agent should act as the user or as itself. My answer: as itself wherever the platform allows it, with its own identity, a named owner, and permissions scoped to the task. Delegated user access is sometimes unavoidable, so when it is, keep the OAuth scopes narrow, the tokens short-lived and the logs on. And before approving any agent, ask what the worst thing it could do with its current access would be.

Where to start

You won’t fix NHI sprawl in a quarter. A practical first pass:

1. Inventory. Pull service accounts from AD, roles and service principals from each cloud, OAuth apps from your IdP and SaaS tenants, and certificates from your CAs. It won’t be complete. Start anyway.
2. Find the dangerous ones. Privileged NHIs, stale credentials, secrets older than a year, accounts with SPNs and weak passwords, and anything with no recent use.
3. Assign owners. Every NHI that stays gets a named human owner. The ones nobody claims go on the disable list.
4. Vault and rotate the privileged ones. Bring high-privilege service accounts under PAM and turn on rotation.
5. Get secrets out of code. Turn on secret scanning in your repositories and move what you find into a secrets manager.
6. Monitor. Baseline NHI behavior and alert on use from new locations or at unusual volumes.

Non-human identities are the accounts nobody owns, and that’s exactly why attackers like them. Give them owners, give them less access and shorter-lived credentials, and watch how they’re used. More at /topics/identity-security/ and /topics/ai-security/.