Service accounts never offboard

When a person leaves a company, a process runs. It is often late and occasionally embarrassing, but it exists: accounts disabled, sessions revoked, a checklist someone signs. Human identities have a life cycle because payroll forces one — you cannot forget to stop paying someone.

Nothing forces a life cycle onto a service account. It is created for an integration, granted a scope that was slightly too broad because the narrow one didn’t work on a Friday afternoon, and then it simply persists. The engineer who created it changes teams. The vendor it talked to gets replaced. The account remains — authenticated, authorized, and absent from every conversation about access.

Why reviews don’t catch them

Access reviews are organized around people, because that is what auditors historically asked about and what review tooling was built for. The review walks the org chart: here are Kim’s permissions, here are Lee’s, does their manager confirm they still need them?

Service accounts have no manager. They hang off a team, a project, or nothing at all. In many directories they are not even the same kind of object — they live in a separate list that the review process was never pointed at. So the quarterly ritual that is supposed to shrink standing privilege systematically skips the identities whose privilege grows the fastest.

And it does grow. A human’s access is trimmed by role changes and offboarding. A machine identity’s access only accumulates: each incident where it lacked a permission ends with the permission granted, and no event ever ends with one removed. Privilege ages upward while accountability ages downward, until you have credentials with production-write access whose purpose nobody can state from memory.

The keys make it worse

Human authentication got better — passkeys, hardware-backed, phishing-resistant. Machine authentication mostly still means a long-lived secret in an environment variable. These keys are copied into CI configs, laptops, and chat threads. They do not expire unless someone chose an expiry, and choosing one means signing up for a future outage, so mostly nobody does.

Which produces the standard incident shape: a key minted years ago, scoped to everything because scoping was hard, held by a person who no longer works there, leaks from a build log. No login anomaly fires, because there is no login — the key is the session, forever.

Agentic software raises the stakes further. AI agents acting on delegated authority are multiplying the population of non-human actors, and they act with more autonomy than a cron job ever did. If the existing machine-identity discipline is “create and forget,” extending it to agents means forgetting things that make decisions.

What a real life cycle looks like

The fix is not a new product category so much as a refusal to treat machines as exceptions:

A named human owner. Not a team alias. When the owner offboards, the account enters review automatically — the leaving day it never had.
An issue date and an expiry. Renewal is a moment where someone must restate why this exists. The outage risk of expiry is the mechanism, not a bug: things that nobody will renew are things that should stop.
Scopes granted like loans, not gifts. Recorded, reviewed on the same schedule as human access, in the same tool, in front of the same reviewer.
An audit trail of what it actually did. Most service accounts are over-provisioned precisely because nobody can see what they use. Usage data turns “probably needs it” into a diff.

The ten-second test

Find your oldest active service-account credential. Two questions: who owns it, and what breaks if it is revoked today?

If the first answer is a person who left, or the second answer is a shrug, that credential is not infrastructure. It is an unlocked door with a good reputation.

Axowl issues machine and AI actors the same kind of identity humans get — owned, scoped, expiring, and audited in one place. See how it works.