Non-human identity: governing the agents that act for you

Most identity programs are built around two assumptions that agents violate: the human lifecycle of joiners, movers and leavers, and interactive logins with a password and MFA. An agent has neither. It is created by a deployment rather than an HR process, it authenticates non-interactively against an API with a key or token, and it can keep running long after the team that built it has moved on, so there is no leaver event to trigger cleanup. Role-based models also assume a person sits behind each identity, whereas an agent may spin up many short-lived identities or share one across tasks. The practical consequence is that bolting agents onto a human-centric IAM leaves them ungoverned by default — created freely, rarely reviewed, never offboarded. They need ownership, scope, rotation and audit modelled for machines, which is what non-human identity management provides.

Scale combined with neglect. Organisations accumulate machine credentials far faster than human accounts — every service, integration and agent needs at least one — and because no joiner-mover-leaver process governs them, they tend to be long-lived, broadly scoped and owned by no one. Each of those properties is a liability on its own; together they are the classic breach enabler. A single leaked or compromised key grants an attacker exactly what the agent could do, which is usually far more than the immediate task required, and because the same credential is often reused across tools, one leak can cascade. The danger is amplified by invisibility: most teams cannot say how many machine identities they have or what each can reach, so a stale, over-privileged credential can sit unnoticed for months. The risk is rarely an exotic exploit; it is an ordinary forgotten key with too much power.

Inventory, without exception, because every later control depends on it. List every agent and service identity, the credentials each one holds, who owns it, what it can reach, and when it was last used. You cannot scope, rotate or revoke what you have never enumerated, and almost every organisation that runs this exercise finds surprises — keys with no owner, credentials that should have been revoked when a project ended, identities with far more access than anyone remembers granting. The inventory is also what converts a vague worry into a prioritised work list: once you can see the long-lived, over-scoped and unowned identities, you fix those first. It is unglamorous and often tedious, but naming what acts on your behalf is the prerequisite for governing it, and it usually pays for itself by surfacing a handful of genuinely dangerous credentials on the first pass.

A service account is one kind of non-human identity, but the term NHI is deliberately broader and reflects how much the landscape has changed. Classic service accounts were relatively few, long-lived and tied to a specific application, and many organisations managed them, however imperfectly, as a known set. Modern non-human identities include agents, workloads, CI jobs, functions and ephemeral tokens that are created and destroyed constantly, often automatically, and at a scale that dwarfs the old service-account inventory. Treating agents as just more service accounts tends to fail because the old manual processes do not survive the volume and churn. The NHI framing keeps the useful instinct — name an owner, scope tightly, rotate, audit — but assumes automation, short lifetimes and machine-speed creation as the norm. In short, every service account is an NHI, but not every NHI looks or behaves like the service accounts most IAM tools were designed around.