Machine & Agent Identity

Non-Human Identity (NHI)

Non-Human Identity (NHI) is the umbrella term for service accounts, API keys, OAuth tokens, certificates, secrets, workload identities, and AI agent identities — every identity in the environment that isn't a person.

Last reviewed 5/30/2026

Key points

  • NHIs outnumber human identities by 30:1 to 80:1 in most modern environments.
  • They're disproportionately involved in breaches because they live long, hold broad scopes, and have no MFA.
  • Coverage spans: service accounts, API keys, OAuth tokens, SSH keys, certs, workload identities, secrets, agent identities.
  • The emerging NHI security category (Astrix, Entro, Oasis, Clutch, Aembit, GitGuardian) is consolidating these concerns.
  • Treat every NHI like a privileged account: scope it, rotate it, audit it, kill-switch it.

What is non-human identity?

Non-Human Identity (NHI) is the umbrella for everything in your environment that authenticates and acts but isn't a person:

  • Service accounts in your IdP, AD, Salesforce, Snowflake.
  • API keys and OAuth tokens issued to apps, SaaS integrations, and AI agents.
  • Workload identities (Kubernetes service accounts, AWS IAM roles, Azure managed identities, GCP service accounts).
  • Machine certificates for mTLS and code signing.
  • SSH keys and CI/CD deploy keys.
  • Secrets in vaults, env vars, and (still) source code.
  • AI agents and bots acting on behalf of users or systems.

In most environments NHIs outnumber humans by an order of magnitude or two. They're also disproportionately involved in breaches: long-lived, broadly scoped, almost never MFA-protected, and easy to leak into source code or logs.

Why NHI is now its own category

Each of the items above used to be owned by a different team and a different tool — secrets in Vault, certificates in PKI, service accounts in AD, API keys in SaaS admin consoles. The new NHI security category (Astrix, Entro, Oasis, Clutch, Aembit, GitGuardian, Britive, Token) treats them as a single attack surface that needs:

  • Discovery — find every NHI, including the ones nobody documented.
  • Posture — who created it, who owns it, what scope, when was it last rotated, when was it last used?
  • Lifecycle — who can issue new NHIs, who approves, when do they expire?
  • Detection — anomalous use, leaked credentials, stale tokens still authenticating.
  • Governance — periodic review of every NHI, just like user access review.

When buyers care

You need an NHI strategy when:

  • You can't answer "how many service accounts and API keys do we have?" within an order of magnitude.
  • A breach traces back to a leaked CI/CD token or a forgotten OAuth integration.
  • You're rolling out AI agents and realize each one is a long-lived credential.
  • Auditors start asking the same questions about non-human access they ask about human access.

Common pitfalls

  • Owning NHI only in PAM — most NHIs are SaaS API keys and cloud workload identities that traditional PAM doesn't cover.
  • No ownership — accounts created by a contractor in 2020, still active, no current owner.
  • No rotation — keys created on day one, used in production for years.

FAQ

Is NHI the same as service accounts?

Service accounts are a subset. NHI is broader — every non-human credential or identity, regardless of where it lives.

Where does AI agent identity fit?

AI agent identity is a subset of NHI with extra requirements around delegation, scope, and dynamic lifecycle.