Service Accounts Outnumber Staff 82 to 1. Nobody Owns Them.

In assessments, one question reliably stops a room:

“Who owns service account SA-prod-04?”

Silence. Then someone offers “maybe infrastructure?” Nobody writes their name down. The account keeps its administrative rights, and it will still have them next year.

What counts as a non-human identity

A non-human identity is any credential that authenticates something other than a person: service accounts, API keys, OAuth tokens, machine certificates, workload identities, and the credentials held by AI agents.

They authenticate, hold entitlements, and take actions exactly as human accounts do. The difference is procedural, not technical — they are created outside the joiner-mover-leaver process, usually by an engineer solving a problem at the time, and so they never enter the lifecycle that governs everything else.

That procedural gap is the entire problem. Nothing about a service account is harder to govern than a human account. It is simply that no process was ever pointed at it.

Why inventories rot

Spreadsheets go stale before they are finished. A point-in-time list is out of date before the project that produced it closes, because accounts are created faster than reviews run.

Discovery without consequence decays. Tooling that emails a report to a distribution list produces awareness, not governance. Nothing in that loop deletes an account. A scanner that finds 3,000 credentials and assigns none of them to anyone has converted an unknown problem into a known one, which is progress exactly once.

Ownership reconstructed is ownership refused. When you work out who owns something after the fact, the creator has left, the purpose is undocumented, and nobody will accept accountability for deleting it. So it survives — with whatever rights it was born with.

That third failure is the one that matters, and it explains why organisations run the same discovery exercise every two years without the population ever shrinking. Each cycle produces a list. No cycle produces a decision, because deleting an account whose purpose nobody can state is a risk an individual has to absorb personally, and nobody volunteers.

Discovery-first versus ownership-first

What AI agents change

An ordinary service account has a fixed purpose and a static set of entitlements. You can write down what it reaches, and the note stays true.

An AI agent does not work that way. It acquires permissions at runtime, invokes external APIs, chains actions across systems, and in some architectures spawns sub-agents that need credentials of their own. The practical consequence is that a static inventory cannot describe what an agent can reach, because the answer is decided during execution rather than at provisioning.

This does not call for a new category of governance. It raises the stakes on the one already described here. Three things stop being optional:

Scoping at issuance. An agent credential should be issued with the narrowest set of entitlements that lets it do its job, because nothing downstream will narrow it later. The habit of granting broad access and reviewing it at the next certification cycle fails outright when the credential is used autonomously thousands of times between cycles.

Expiry by default. Short lifetimes with automatic rotation are the only control that reliably bounds an agent credential’s blast radius, because no human is watching each use.

A named human owner. Not the team that deployed the agent — a person who can be asked what it is for and who is accountable for retiring it. An agent whose owner is “the platform team” is an agent nobody will turn off.

The survey finding worth holding onto here is the gap between concern and action: most security leaders now describe governing AI agents as critical, while a minority have implemented any policy for it. That gap is where the next several years of findings will come from.

Why this reaches compliance, not just security

Access certification generally assumes a human reviewer confirming a human’s access. Machine accounts fall outside that, which is precisely why they persist — and increasingly why they are sampled.

For SOC 2, an auditor asking how access is reviewed will not accept a scope that silently excludes the majority of credentials. For a production service account, expect to show why it exists, who approved it, what it can reach, and how it is rotated or revoked.

Under HIPAA, Section 164.312(a)(1) covers persons or software programs granted access rights. A service account reaching patient records is subject to the same access control standard as a clinician, including unique identification — which shared service accounts cannot satisfy.

In banking, an unowned account with production rights is a segregation-of-duties question waiting to be asked. If a credential can both initiate and approve a consequential action and no person is accountable for it, the control gap is not theoretical.

The useful framing is not “we should inventory our service accounts.” It is: every credential has an owner, a purpose and an expiry, or it does not get created.

What it actually takes

The trap is trying to govern all of them at once. With one security engineer, this order works.

1. 1

   Scope to what can reach production

   3–5 days

   Not every machine account matters equally. Start with those holding write access to production, payment paths, or systems with regulated data. This is usually a tenth of the population and most of the risk.

2. 2

   Assign an owner to each one, by name

   2–3 weeks

   A person, not a team mailbox. Teams reorganize; people can be asked a question. Expect this to be the slow part, because it is the part that requires conversations rather than tooling.

3. 3

   Make an owner mandatory at creation

   1–2 weeks

   Enforce it wherever accounts are actually created — the cloud console, the secrets manager, the pipeline. This is the step that stops the problem regenerating, and skipping it means repeating steps one and two next year.

4. 4

   Attach an expiry to every credential

   2–4 weeks

   Default lifetimes with automatic rotation. An account that must live forever becomes a documented exception with a named approver, rather than the norm.

5. 5

   Scope agent credentials at issuance

   1–2 weeks

   For anything autonomous, grant the narrowest entitlements that let it work and set a short lifetime. Nothing downstream will narrow an over-scoped agent credential, because no human reviews each use.

6. 6

   Put owner departure into the leaver process

   1 week

   When someone leaves, their machine accounts should surface for reassignment alongside their own access. Without this the model decays quietly, one resignation at a time.

The objection worth answering

Engineers push back on mandatory ownership for a reason that is usually correct: it adds friction to creating a credential, and creating credentials is on the critical path for shipping.

The answer is not to insist the friction is worth it. It is to make the owned path faster than the unowned one — a template that issues a scoped, expiring credential with the requester recorded as owner, in less time than it takes to create an unmanaged one by hand. Ownership then becomes a side effect of the convenient route rather than a tax on the correct one.

Every implementation of this that we have seen fail, failed the same way: the governed path was slower, so it was routed around, and the population kept growing underneath a policy that technically existed.

Where vaultIAM fits

Machine identity is one of the ten categories we score, and it carries heavy weight outside banking because that population is where under-resourced teams are furthest behind.

We enumerate machine accounts read-only through each platform’s own admin interface, identify which can reach production and regulated data, and give you the ownership gaps ranked by what closing each one actually reduces.