The first step is always to discover. NHIs live spread across cloud tenants, secret managers, SaaS connectors, deployment pipelines and source code. Without a consolidated inventory, any governance attempt starts blind.
What NHI is
NHI (Non-Human Identities) is the set of identities systems use to talk to each other: service accounts, application tokens, API keys, machine certificates, CI/CD pipeline identities, SaaS connectors and, increasingly, autonomous agents based on AI. In any organisation with some technological maturity, non-human identities outnumber human ones by ratios that range from 20 to 1 up to over 50 to 1. Despite that ratio, they tend to be worse governed: hardcoded secrets in repositories, keys not rotated for years, inherited permissions no one reviews and diffuse ownership between teams. NHI is the concept that puts focus on governing them as a first-class identity asset and not as a deployment detail.
Why it matters
When a serious incident touches the identity plane, the victim is usually a non-human identity: a token leaked in a public repository, an API key from a SaaS integration compromised at a vendor, a service account with tenant-wide permissions and no rotation. For an attacker, NHIs are privileged targets: they hold broad permissions, do not use MFA, do not rotate, do not flag anomalous use and tend to be forgotten in the inventory. For a security team, governing them requires discovering them, assigning ownership, rotating secrets, applying least privilege and monitoring usage. For frameworks like NIS2, DORA or ISO 27001 that require identity and access controls, ignoring NHIs leaves one of the most-used doors wide open.
Key points
Each NHI must have an explicit, named human owner. Without an owner, findings on rotation, least privilege or revocation have no recipient. Ownership should be reviewed at least once a year and trigger immediate reassignment when the responsible person changes role.
Credential rotation is one of the most critical and most overlooked controls. Any token, API key or secret must have an expiry date and an automated rotation mechanism. Manual rotation does not work at scale.
Using a secrets manager is necessary but not sufficient. An NHI whose token sits in the manager but is also hardcoded in five repositories is still vulnerable. The correct integration is 'from the manager only' and validated with continuous secret scanning.
Least privilege is particularly important for NHIs because their permissions go unchallenged in periodic reviews. Well-applied CIEM platforms significantly reduce effective permissions of service identities by comparing what is granted with what is used in logs.
Autonomous AI agents are the most recent generation of NHI and the fastest-growing one. They inherit the same problems (broad permissions, no rotation, diffuse ownership) and add a new one: they make action decisions on their own, which means every granted permission has amplified consequences.
Example: NHI governance programme in a cloud-first company
A cloud-first organisation with several critical SaaS integrations and CI/CD pipelines that deploy twenty times a day decides to apply a non-human identity governance programme. The first sweep — combining cloud provider inventories, secret managers, SaaS connectors and secret scanning across repositories — discovers 2,300 active non-human identities. Of those, 420 have broad permissions over critical data, 180 have not been rotated in over 12 months, 90 are secrets hardcoded in code and 30 are accounts inherited from employees no longer at the company.
The team sets three immediate actions: revocation of the 30 orphan accounts with notification to affected teams, replacement of the 90 hardcoded secrets with consumption from the manager with automated rotation, and a reduction plan over the 420 over-permissioned identities using CIEM based on real usage. Three months in, the inventory has explicit ownership for 98 per cent of the NHIs, rotation is automated for 85 per cent and effective permissions have been reduced by 60 per cent. The headline metric delivered to the committee is no longer 'we have a secrets manager' but 'average credential age is 28 days and shrinking'.
Common mistakes
- Treating non-human identities as a deployment detail. While human ones go through formal processes (provisioning, deprovisioning, periodic review), NHIs tend to be born in a script and die in another. Without explicit governance, they end up as the most used door in serious incidents.
- Trusting that the secrets manager is enough. A secret in the manager that also lives hardcoded in repositories is not a secret. The integration must be exclusive ('from the manager only') and validated with continuous secret scanning in code.
- Not assigning a human owner. Without a named responsible per NHI, findings stay in a list. Ownership must be reviewed at least annually and reassigned immediately when the responsible person changes role.
- Applying manual rotation. Any rotation that depends on a human remembering to do it will not happen. Rotation must be automated and the success metric is average credential age.
- Forgetting that AI agents are also NHIs. More and more permissions are being granted to autonomous agents and, often, without ownership, rotation or proper privilege constraints. The consequences of an over-permissioned, poorly governed agent are greater than those of a traditional NHI because agents make action decisions.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
How many non-human identities does a typical company have?
It depends on technological maturity, but in organisations with cloud presence, several integrated SaaS and active CI/CD pipelines, non-human identities usually outnumber human ones by ratios of 20 to 1 up to 50 to 1. A first honest estimate only comes after a discovery exercise that crosses cloud inventory, secret managers, SaaS connectors and secret scanning in repositories.
Why are they a preferred target for attackers?
Because they combine broad permissions, no MFA, no rotation, diffuse ownership and poor monitoring. Compromising a service account or application token is equivalent to logging in as an administrative human user without anyone noticing anything unusual. It is the most efficient way to move through an environment without triggering alerts.
What role does CIEM play in NHI governance?
CIEM focuses on effective permissions in the cloud and compares what is granted with what is actually used in logs. For non-human identities that comparison is especially useful, because they rarely justify the broad permissions they were originally granted. A good NHI governance programme uses CIEM as the engine for least-privilege reduction.
How do you govern an AI agent as a non-human identity?
AI-based agents are still non-human identities and are governed with the same principles: explicit owner, secrets in a manager with automated rotation, least privilege based on real usage and behaviour monitoring. The key difference is that they execute actions autonomously, so any excessive permission amplifies potential damage. The operational rule is 'grant only what the agent needs for that specific decision and for the right time window'.