Non-Human Identity 2026: what CISOs should actually do about NHI, OWASP NHI Top 10, and AI agent governance

Non-Human Identities — service accounts, API keys, OAuth client credentials, machine certificates, workload identities, and now AI agents — outnumber human identities in most enterprises by roughly 50 to 1. They also break in ways the IGA tooling of 2018 was not designed for: a service account does not get a quarterly access review, a leaked API key does not show up in an HR offboarding ticket, and an AI agent provisioning itself a database role does not file a ServiceNow request.

This is a practitioner’s view from running IGA platforms in production — SailPoint Identity Security Cloud, SailPoint IdentityIQ, Evolveum midPoint — on what NHI controls actually move risk, and which ones are 2025-vintage theatre.

Why the category exists

The shorthand “NHI” emerged from a real operational problem: most enterprise identity programmes were built around the joiner-mover-leaver lifecycle of employees. That lifecycle has clear external triggers — HR system records, contract end dates, badge revocation — and IGA platforms exploit those triggers for provisioning and recertification.

Service accounts have none of those triggers. They are created when an engineer is debugging an integration on a Tuesday afternoon, named svc-prod-temp-please-delete, granted the permissions the engineer was too busy to scope down, and forgotten. Five years later that account still has write access to a production database, and nobody who created it still works at the company.

Multiply by ten thousand service accounts and you have what KuppingerCole calls the Identity Visibility & Intelligence Platform (IVIP) problem — not “we have too many identities”, but “we cannot see which ones matter”.

OWASP NHI Top 10 — what matters in practice

The OWASP Foundation published the NHI Top 10 in 2025. It is a useful checklist; reading it cold it is also abstract. Here is which items we see hit production incidents most often, ranked by frequency in our engagements:

1. NHI4 — Insecure authentication. Service accounts with passwords that never rotate, API keys checked into git histories, OAuth client secrets pasted into Slack. Most “NHI breaches” reduce to this category once you strip away the press-release framing.
2. NHI2 — Secret leakage. The mechanical cousin of NHI4. Less about credential design and more about credential storage. Vault adoption helps; secret scanning in CI helps more, and a periodic security audit and penetration test catches the leaked credentials scanning misses — secrets in artifact layers, config backups, and forgotten internal wikis.
3. NHI6 — Insecure cloud deployment configurations. Workload identities (AWS IAM roles, Azure managed identities, GCP service accounts attached to VMs) over-scoped by default because nobody had time to write a tight IAM policy.
4. NHI9 — NHI reuse. The same service account doing service-account work in three different applications because rotating any one of them means breaking the other two.
5. NHI3 — Vulnerable third-party NHI. OAuth integrations granted “full access” scopes during a free-trial demo, never revisited.

Items NHI1, NHI5, NHI7, NHI8, NHI10 are real but show up later — usually after a tighter inventory makes them visible.

The AI agent dimension

AI agents add a new failure mode: identities that provision themselves. A long-running agent given OAuth credentials to a SaaS tool will, given sufficient autonomy, request and accept role escalations, create sub-agents, and chain tool-use across systems whose individual security postures were never designed to be composed by a non-human actor.

There is a working OWASP draft on AI Agent Governance and a parallel set of Gartner-coined terms (Agentic Identity, Agentic IAM). The practical posture we recommend to CISOs in 2026:

• Treat every AI agent as a first-class NHI with a lifecycle, an owner, an explicit scope, and a rotation cadence.
• Refuse blanket OAuth grants to agent platforms. Where the underlying SaaS does not support fine-grained scopes, route agent calls through a proxy that enforces them. This is engineering work, not procurement work.
• Demand session-level audit logs that record which agent invocation performed which downstream action. The “an agent did it” answer is not acceptable in an incident post-mortem.

What IGA platforms do (and do not) cover today

Capability	SailPoint ISC	SailPoint IIQ	midPoint
Service account inventory	Yes (with connector reach)	Yes (with connector reach)	Yes
Credential rotation enforcement	No — needs Vault / secrets manager	No	No
AI agent identity (as a managed type)	Partial via tagging	Custom	Custom
Workload identity (cloud roles)	Yes via cloud connectors	Yes via cloud connectors	Yes via cloud connectors
Session-level audit for agents	No — needs agent platform	No	No

The pattern is consistent: IGA platforms can see and govern the NHI registration layer, but the runtime authentication and audit layer belongs to the secrets manager, the IdP, and (now) the agent platform. At the workload-to-workload layer this increasingly means short-lived mTLS certificates rather than static service-account secrets — machine identity proven cryptographically on every call instead of stored, shared, and rotated. NHI maturity comes from wiring these together, not from buying a single product called “NHI”.

A pragmatic 90-day plan

If you are a CISO inheriting an NHI gap in a 5,000-employee enterprise, the order of operations is:

1. Inventory. Run a discovery sweep through your IGA against AD, cloud IAM, and your top 5 SaaS targets. Output: a count and a list, not a dashboard.
2. Ownership. Every NHI without a named owner gets disabled in 14 days. This is the single most painful and most effective control.
3. Rotation. Connect service-account credentials to a secrets manager (HashiCorp Vault, AWS Secrets Manager, Yandex Lockbox). Set a 90-day rotation cadence and let the failures surface the integrations that need refactoring.
4. Agent scoping. Audit every AI agent grant in your SaaS portfolio. Revoke “full access” scopes; replace with the narrowest practical role.
5. Recertification. Add NHI to the next access-review campaign. Not as a separate workflow — as part of the same review the owner already runs for their human users.

None of this needs new software you do not have. It needs the IGA platform you already paid for, applied to the identities the platform was not originally optimised for.

That is the NHI 2026 conversation. The press cycle will move on; the service accounts will not.