Non-Human Identities Already Outnumber Your Humans. Did Anyone Provision the Agents?

Identity programmes are built around people. Joiner, mover, and leaver processes, access reviews, manager attestations, and multi-factor prompts all assume a human who starts a job, changes roles, and eventually leaves. Autonomous agents break that assumption quietly, because an agent does not request an account the way a person does. A developer wires one up in an afternoon, it needs credentials to do anything useful, and those credentials come from wherever was easiest.

The result is a population of identities that grows with enthusiasm rather than process. In many environments, machine credentials already outnumber human accounts, and agents add a faster-growing, less predictable category on top: identities created by people, pipelines, and sometimes other agents, with no step at which anyone asked who would own them.

The population you didn't plan for

In many cloud and CI estates the humans are already a minority: service accounts, API keys, tokens, certificates, workload identities, and bot users accumulate faster than staff do. Each was created for a reason that made sense at the time, by someone who may have moved on since. Agents accelerate this in three ways. They are numerous, because a useful pattern gets copied across teams and use cases. They are temporary in intent but long-lived in practice, because a prototype's credential is rarely removed when the prototype is promoted or abandoned. And they are created by non-specialists, often outside the platform team's view, with whatever credential was within reach.

The consequence is not just volume but invisibility. A directory lists employees; nothing lists the credentials held by a fleet of agents, who authorised each, or whether the thing it was created for still exists. You cannot govern a population you cannot enumerate, and in many organisations the first honest answer to the question of how many agent identities exist is a shrug.

An agent is a privileged identity

It is tempting to file an agent credential under service accounts and move on. That undersells it. A conventional service account runs fixed code that does one predictable thing. An agent chooses what to do at runtime, from instructions it reads, using whatever its credentials permit. Its authority is exercised by a component that can be persuaded, which is the property that makes a phished privileged account dangerous, now present in an identity that never sleeps and never grows suspicious.

How a single agent's authority should be bounded is a topic of its own. The point here concerns the fleet: every agent is a privileged identity, so a fleet of them is a privileged-access estate, usually without the privileged-access controls. There is no vaulting, no approval workflow, no recertification. No organisation would knowingly hand out administrator accounts by pasting a token into a configuration file, yet agent credentials routinely arrive exactly that way.

Lifecycle: who owns it, and when does it die

Human identities have an end-of-life process because people leave and someone eventually notices. Agent identities have no equivalent trigger. Nobody resigns. The project that created the agent is cancelled, the team reorganises, the experiment is superseded, and the credential carries on, valid and unwatched. Without a named owner and a defined expiry, an identity has no point at which anyone is obliged to decide whether it should still exist.

The diagram shows where lifecycles tend to stall. The steps that deliver value get built. Rotation and revocation deliver nothing visible until they are needed, so they stay manual, aspirational, or absent. The fix is to make the end of life part of the beginning: an identity is not created without a named accountable owner, a recorded purpose, and an expiry date, and the expiry is enforced by the issuing system rather than by someone's calendar reminder. An owner who leaves triggers the same review a departing employee's accounts would.

Over-permissioned and long-lived by default

Agent credentials start broad for an understandable reason. Nobody knows in advance which calls the agent will make, and a narrow role that blocks the demo costs more, in the moment, than a wide one that merely carries risk. So the agent runs with an administrator role, a shared service account, or a developer's personal token, and the permissions are never revisited. Over time the gap between what the agent needs and what it can do widens, and that gap is exactly the authority available to anyone who manages to steer it.

The same logic produces secret sprawl. Long-lived keys get pasted into environment files, notebooks, container images, pipeline variables, chat threads, and agent configuration, then copied again when the next agent is built. Each copy sits outside any rotation scheme, because rotating a secret that lives in a dozen places breaks something, and so nobody does. Prefer credentials that expire on their own: short-lived tokens issued at runtime, bound to a workload identity, scoped to the task, and gone within minutes or hours. Where a long-lived secret is unavoidable, hold it in a managed vault, scope it to one agent, and rotate it on a schedule you have actually tested. A credential a model can read is one it can be talked into revealing, so keep secrets outside the context altogether.

Attributing an action to an agent

When something goes wrong, the first question is who did it. For agents the honest answer is often a shared account, and the log says only that a service principal made the call. If five agents share one identity, the audit trail cannot separate them, let alone distinguish the agent's own decision from an action taken on behalf of a particular user. That ambiguity is a governance problem long before it is a forensic one: nobody can be held accountable for activity that cannot be attributed.

Give each agent its own identity, so that every log line names a specific agent rather than a team's shared account. Record, where the system allows, the delegation chain: which person or process initiated the task, which agent acted, which tool it called, and under what scope. Tie each identity to its owner in an inventory so that an alert about an unusual call reaches someone who can answer it. Attribution is also what makes revocation surgical: you can disable one agent without taking down everything that shared its key.

Governing non-human identity

None of this requires new theory. It requires applying to agents the controls that privileged human accounts already receive, adapted to a population that grows faster than a ticket queue can process. A workable programme rests on a few properties that can be enforced at creation time and checked continuously.

• Inventory — A maintained list of every agent identity and credential, built by scanning the estate rather than relying on teams to self-report.
• Owner — A named person or team accountable for each identity, and a process that reassigns or retires it when that owner moves on.
• Expiry — Every identity and credential carries an end date enforced by the issuer, and renewal takes a deliberate act.
• Least privilege — Scopes set per agent and per task, reviewed on a schedule, with unused permissions removed.
• Short-lived credentials — Runtime-issued, narrowly scoped tokens in place of static keys wherever the platform supports them.
• Attribution — A unique identity per agent, with logs that tie each action to that agent and the delegation behind it.

An agent credential without an owner and an expiry is not a managed identity; it is a standing grant that nobody is responsible for ending.

Review keeps the rest honest. Recertify agent identities the way you recertify privileged accounts, and treat an unowned identity, or one that is expired but still valid, as a finding rather than a housekeeping note. Automate what can be automated, since the population will outgrow any manual review.

When 6QURE reviews an agentic deployment, identity is one of the first threads we pull: how many agent identities exist, who owns each, what each can reach, when each credential was issued and when it will stop working, and whether a log entry can be traced to one specific agent. The answers show whether the agents were provisioned or merely appeared.