Most identity programs were built around a simple picture: a person logs in, gets provisioned, gets recertified once a year, and eventually gets deprovisioned when they leave. That picture no longer describes most of the identities in a modern enterprise.
Service accounts, API keys, CI/CD pipeline credentials, bots, and now AI agents routinely outnumber human users in any reasonably sized organization. Almost none of them go through the access reviews, offboarding, or least-privilege discipline a human account gets. That gap has a name now: non-human identity, or NHI, security.
Why non-human identities slipped through
They were never built with a lifecycle in mind. A service account often gets created to unblock a project, works, and then nobody revisits it. There’s no equivalent of an HR system triggering offboarding when the thing that created it is retired.
Credentials are long-lived by default. Where a human might be forced into periodic password resets and MFA, a service account’s API key is frequently set once and never rotated, because rotating it risks breaking whatever depends on it, and nobody wants to be the one who breaks production.
Ownership is unclear. A human identity has an obvious owner: the person. A service account or API key is often “owned” by a team that has since reorganized, or by an employee who has long since left, leaving a credential with real access and no accountable owner.
They scale faster than review processes can keep up. Every new integration, pipeline, and now every new AI agent or MCP connection can mint its own credential. The growth rate of non-human identities is outpacing any manual review cycle built around annual recertification.
Over-permissioning is the default, not the exception. It’s faster to grant broad access once than to scope it precisely and revisit it later, so non-human identities frequently accumulate permissions well beyond what they actually use.
Why this matters more now, specifically because of AI
AI agents and automations are a new, fast-growing category of non-human identity, and they tend to inherit the worst habits of the category: broad standing access, unclear ownership, and no consistent registration process. An agent built to summarize data from a CRM can end up with read access to far more than a CRM if nobody scoped the credential carefully, and an unregistered agent with that access is both a shadow AI problem and an identity governance problem at the same time. Our post on shadow AI covers the discovery side of this; the identity side is what decides what that agent can actually do once it exists.
What governing non-human identities actually requires
A real inventory first. The same principle that applies to shadow AI applies here: you cannot govern an identity you don’t know exists. That means enumerating service accounts, API keys, pipeline credentials, and agent identities with the same rigor applied to human accounts, not treating them as infrastructure noise.
Ownership assigned to every credential. Every non-human identity should trace back to an accountable owner or system, not sit in a shared vault nobody feels responsible for.
Rotation and expiry, not permanence. Long-lived, never-rotated credentials are the exception that should require justification, not the default. Where rotation isn’t automated, it should at least be scheduled and tracked.
Least privilege scoped to actual use, not convenience. A non-human identity’s permissions should match what it actually does, reviewed against real usage rather than the broad grant it was given on day one.
The same audit trail as a human user. Every action a service account or agent takes should be attributable and reviewable after the fact, the same way a human user’s actions are.
Recertification that actually happens. An access review cycle that only covers human accounts is reviewing a shrinking share of the organization’s actual identity surface. Non-human identities need to be in that cycle too.
A single identity picture, not two
The underlying problem with most identity programs isn’t that non-human identities are ungoverned, it’s that they’re governed by a different, weaker process than human identities, when the risk they carry is often higher. A compromised service account with standing database access can do more damage, faster, than a compromised human account with MFA in front of it. Treating human and non-human identity as one governed population, in one system, with one consistent lifecycle, closes that gap rather than managing it as two separate problems with two different levels of rigor.
What to ask before trusting an identity security claim
- Does it inventory service accounts, API keys, and AI agent identities with the same completeness as human accounts?
- Does every non-human identity have a traceable, accountable owner?
- Is credential rotation tracked and enforced, or left to whoever set it up originally?
- Are permissions reviewed against actual usage, or just granted once and left alone?
- Does the audit trail cover non-human identity actions as thoroughly as human ones?
- Are AI agents and MCP connections included in the same governance model, or treated as a separate, newer problem?
Where Ilantus and Rainier fit
Ilantus brings twenty years of IAM heritage to this problem, extending single sign-on, access governance, and privileged access management to cover AI and agent identity alongside human users, so non-human identities get rotated, audited, and revoked with the same rigor as everyone else, not managed as an afterthought in a spreadsheet. On the detection side, Rainier correlates identity signals directly with SIEM and EDR alerts, so unusual activity from a service account or an agent surfaces in the same triage pipeline as any other threat, rather than in a separate identity console nobody’s watching in real time. For the deeper evidence-backed inventory of agents, their identities, and what they connect to, see our post on Denali.
Want to know how many non-human identities are actually running unmanaged in your environment? Talk to Network Intelligence.
