Count your employees. Now count your service accounts, CI runners, API keys, webhooks, OAuth apps, database users, signing certificates, and—as of the last eighteen months—your AI agents.
In every environment I’ve audited recently, the second number is between 20 and 100 times the first. We spend most of our security budget hardening the smaller number. Attackers, being rational, increasingly go after the larger one.
Machine identities don’t behave like people
Human identity security has matured enormously. MFA is normal. Phishing-resistant authentication is achievable. Offboarding is a process someone owns. We got good at this because humans are visible: they have managers, start dates, and desks.
Non-human identities have none of that, and they break every assumption underneath our controls:
- They can’t do MFA. Whatever secret they hold is the authentication.
- They rarely have an owner. The person who created the token left in 2023.
- They’re never offboarded, because nothing triggers offboarding for a token.
- They’re over-permissioned by default, because scoping precisely takes time and broad access makes the pipeline go green.
- Their credentials get copied—into a CI variable, a laptop, a Slack thread, a wiki page, a container image layer.
Put plainly: a leaked API key is a credential with no expiry, no second factor, no owner, and often no logging that distinguishes it from legitimate traffic. That’s not an edge case. That’s Tuesday.
The agentic multiplier
AI agents made this materially worse, in a way that’s easy to miss because it looks like normal automation.
A traditional service account does one predictable thing. It calls the same three endpoints in the same order forever, which means anomaly detection actually works—deviation is signal.
An agent’s whole value is that it decides what to do. Its access pattern is legitimately unpredictable. That destroys behavioral baselining as a primary control, and it means the blast radius of a compromised agent credential isn’t “the three endpoints”—it’s everything the token permits.
Worse, agents are frequently granted broad access precisely because nobody knows in advance what they’ll need. “Give it read access to everything and we’ll narrow it later” is the most common sentence in agent deployments, and “later” has a poor track record.
Four failure patterns I see over and over
These aren’t exotic. They’re present in most estates, including well-run ones.
- The immortal secret. A static credential created years ago, no rotation, no expiry, embedded in three systems nobody wants to touch.
- The shared workhorse. One service account used by six teams because requesting a new one takes two weeks. Now nothing it does is attributable.
- The scope creep account. Permissions added incrementally to fix outages, never removed. It started as a read-only reporting user and is now effectively an administrator.
- The orphan. Active, powerful, in constant use, and completely unowned. Nobody will approve deleting it because nobody knows what breaks.
Every one of these is an availability problem disguised as a security problem, which is why they persist. Fixing them feels risky. Leaving them is riskier, just less visibly.
What good actually looks like
The target state isn’t complicated to describe. It’s just work.
- Short-lived credentials by default. Minutes or hours, not years. If a leaked token is useless by dinner, half the threat model evaporates.
- Workload identity over stored secrets. Let the platform attest to what the workload is—OIDC federation, instance identity, mTLS—instead of handing it a string to keep safe.
- One identity per workload. No sharing. Attribution is impossible without it, and attribution is what makes incident response fast.
- Scoped to the job. Permissions that match the actual workflow, reviewed on a schedule, with a real removal process.
- Mandatory ownership metadata. Every identity has a named owner, a purpose, and an expiry date. No exceptions, including for the ones created during an incident.
- Revocation you’ve practiced. Not documented—practiced. Time it.
The question that exposes everything
If you want to know where you stand, ask your team one question and watch how long the answer takes:
“A credential leaked publicly twenty minutes ago. Which one is it, what can it reach, who owns it, and how fast can we kill it without taking down production?”
In a mature environment that’s a five-minute answer with a dashboard. In most environments it’s a war room, a spreadsheet, and a genuinely frightening amount of guessing. There’s no judgment in that—this stuff accumulated over a decade of moving fast—but knowing which answer you’d get is the beginning of the fix.
A 30/60/90 that actually moves
You don’t solve this with a program charter. You solve it by shrinking the problem in a specific order.
First 30 days — see it.
- Inventory every non-human identity across cloud, CI, SaaS, and internal systems.
- Flag the ones with no rotation in 12+ months and the ones with administrative scope.
- Turn on secret scanning across repos, images, and logs—including history.
Days 30–60 — stop the bleeding.
- Assign an owner to every high-privilege identity. Unowned plus privileged is the priority queue.
- Kill static credentials in CI/CD first—it’s the highest-value, most-federated target and usually the easiest migration.
- Require expiry on all newly created credentials. New sprawl stops today; old sprawl is a separate project.
Days 60–90 — make it structural.
- Move the top workloads to short-lived, federated identity.
- Right-size permissions on the worst offenders using actual access logs, not intent.
- Run a revocation drill on a real identity in a real environment. Measure it.
- Give AI agents dedicated, scoped, expiring identities—never a human’s token, never a shared account.
Why this is worth the effort
I’ve written before that the controls preventing real incidents are boring ones. This is the most boring and most load-bearing of them all. Machine identity isn’t a product you buy; it’s a property your platform either has or doesn’t.
And the timing matters. Every agent you deploy over the next year will need credentials. If your identity foundation is solid, that’s a routine provisioning step. If it isn’t, you’re about to multiply an existing problem by the number of agents you deploy—and agents scale a lot faster than security reviews do.
Fix the foundation now, while the count is still merely uncomfortable.