AI Agents Rerun the Service-Account Mistake: The Governance Gap Nobody Sized

The security industry already ran this experiment once, with service accounts. Agents are the rerun — same failure, an order of magnitude faster.

We've Seen This Movie

Human identity got the good infrastructure. SSO matured, IdPs took over provisioning, SCIM wired up joiner-mover-leaver, and two decades of refinement turned "who is this person and what can they touch" into a mostly solved problem. Machine identity got none of that. Service accounts, API keys, and tokens accumulated in the gaps between systems, owned by a spreadsheet that was wrong the day it was written, and the industry has spent the last fifteen years building a whole product category — ours included — to clean up the sprawl after the fact.

Now agents arrive, and they inherit the machine-identity failure mode at human-identity scale and machine speed. Every time an agent reads a file, queries a database, posts to Slack, opens a pull request, or calls a third-party API, it authenticates with a credential — a token, an API key, an OAuth grant, a short-lived cert. Every agent action is a credential action. So the population of non-human identities inside the enterprise is expanding faster than any inventory process built for human cadence can keep up with, and it's expanding in exactly the ungoverned way service accounts did, except the loop that used to take a quarter now takes an afternoon.

The reflex is to treat this as a provisioning problem — issue agents credentials, rotate them, log them. That reflex is why we're about to repeat the mistake. The service-account sprawl wasn't a provisioning failure. It was a governance vacuum that provisioning tools papered over. Agents widen the same vacuum, and the tooling reflex papers over it again.

The Assumption Agents Break

Here is the thing the standard remedies keep stepping around. Every identity system in production assumes a human decides at the moment of access. OAuth's consent screen, the approval workflow, the just-in-time access request, the "are you sure" — all of it is built on a person being present to exercise judgment when the credential is used. That assumption is load-bearing, and agents remove it.

An agent authenticates hundreds of times an hour with no human in the loop at the moment of any single call. The consent happened once, at deploy time, for a class of actions the operator could only partly anticipate. Everything after that is the agent exercising delegated authority at machine speed, and the identity layer has no way to tell a reasonable action from a compromised one because the entity that used to make that call — the human — is gone.

This is why bolting agent authentication onto OAuth 2.1 is the identity-layer version of running an autonomous agent on a legacy desktop OS: you are asking a permission model designed for one kind of actor to govern a fundamentally different one, and hoping the impedance mismatch stays small. It won't. The mismatch is the whole problem.

Why the Standard Fixes Are Patches

None of what follows is wrong. Each is necessary. But it's worth being honest that every one of them manages the symptom and leaves the assumption intact.

Short-lived credentials shrink the blast radius — if a leaked token dies in minutes, most of the damage window closes with it. This is the one pattern we'd call non-negotiable, because it's the only one whose benefit doesn't depend on a human being present. The catch: not every downstream accepts short-lived tokens, and an agent touching dozens of APIs will hit at least one that demands a static key. It's a direction, not an absolute, and the fallback where a long-lived key is unavoidable needs an owner, not a shrug.

OAuth 2.1 profiles for agents — dynamic client registration, tight audience binding, short lifetimes by default — are real progress, and Clutch Security has done visible work spelling out what the adaptation looks like inside MCP. But richer binding is still binding a token to an agent, not restoring judgment to the moment of access. It reduces replay; it does not answer "should this action happen right now." And the team that owns token issuance now owns agent identity too, a scope expansion nobody staffed for.

Human-in-the-loop for sensitive actions is the only pattern that actually puts the human back — which is exactly why it's reserved for the narrow set of actions worth gating (spending money, granting access, moving data out). It's an admission, encoded in policy, that the assumption mattered. It also blunts the entire value proposition of automation for whatever it gates, so it can never be the default. The interesting question is which actions earn it, and most teams haven't drawn that line deliberately.

A central agent registry — one source of truth for which agents exist, who owns them, what they can reach — is where every "let's get organized" instinct lands. In practice it starts as a spreadsheet, becomes a wiki, and wants to be a service with an API. A stale registry is worse than none, because it manufactures a false sense of inventory. The only thing that keeps it honest is automated discovery feeding it, which loops the problem straight back to detection — which is to say, back to the category we sell into. We'd rather say that plainly than pretend the registry maintains itself.

No single one of these fixes agent identity. The combination is survivable, and short-lived credentials are the floor. But a security program that adopts all four and believes it has solved the problem has mistaken a set of patches for a governance model.

What Actually Changes in Your Inventory

Set the patches aside and look at the inventory itself. Four shifts are concrete enough to treat as their own categories.

Agents are a distinct NHI class. They don't fit the existing buckets. An agent is an actor with goals, which feels like a human user, but it holds credentials like a service account and gets instantiated programmatically like a machine identity. Logging it as "application" erases exactly the fields that make it risky. Give it its own class — machine-identity defaults (short-lived, scoped) plus agent-specific fields: what model runs it, which human deployed it, what tools it can reach, what policy engine sits in front of it.

Attribution gets worse, not better. A service account had one owner and it was usually wrong. An agent's token could belong to the developer who wrote it, the user who invoked it, or the platform team that provisioned the substrate — and without a deliberate answer it belongs to no one, which is how it becomes a ghost key with no owner to call when it goes bad. Keys nobody owns don't get rotated, and the ephemeral pattern makes it worse: the agent terminates, its key stays valid, the next developer finds it in the vault and reuses it, and it ages into a credential with no living process attached.

Scope creep is the default, not the exception. An under-permissioned agent fails loudly — the user asks, the agent can't, the user complains. An over-permissioned agent succeeds silently until the day it doesn't. Every operational incentive pushes toward over-provisioning, and the residue is a steady pile of over-shared keys whose scope drifted far past what the agent ever needed.

Shadow agents are a laptop away. A developer running an MCP server locally, a marketing team wiring n8n to an OpenAI key, a support engineer pointing Claude at a Zendesk queue through a browser extension — each mints shadow credentials by construction that the central inventory never sees. The more frictionless the tooling, the more of them. Banning it drives it underground; the only durable answer is to make the sanctioned path the easy one and scan continuously for the rest. The new protocol surface — MCP servers, agent-to-agent calls, each a trust boundary bolted on after the prototype worked — is where most of these hide. We went deeper on that surface in our piece on MCP, A2A, and non-human identity.

Every pattern in the NHI Kill Chain we've been publishing applies here, usually more sharply than to ordinary service accounts. Agents don't invent new failure modes so much as run the existing ones at a faster clock.

What We Actually See

A caveat before the pattern: these are field observations from customer environments, not a controlled study, and we'd rather label them honestly than dress them up as research.

The clearest signal is a timing one. When an organization first turns on an MCP or agent integration in a serious way, secret-detection events climb, and they climb in the same shape every time — the integration goes live, developers move fast to wire agents to useful tools, and credentials land where the existing controls weren't looking. A personal access token in an MCP server config checked into a repo. An `OPENAI_API_KEY` in an `.env` committed because the thing was prototyped on a laptop and the prototype path never had production's hygiene. It isn't recklessness. It's that the population writing agent-integration code is wider than the population writing backend code, and the guardrails that caught the second group haven't reached the first.

The dominant story underneath is the convenience key. A developer wants an agent to do something useful; the fastest path is a long-lived key with broad scope. The agent runs fine. The key gets checked into a helper repo, shared with two more agents, and pasted into Slack so a teammate can reproduce the setup. Six weeks later the agent is forgotten and the key is still live, still broad, and sitting in several places, none of which is the vault. The agent was never the problem. The habits around agent development are what spread the credential — which is the whole argument in miniature: this is a governance gap, not a provisioning bug.

And the industry's own scoring hides it. The classification blind spots we wrote about in The Out-of-Scope Loophole hit agent-created credentials harder, because a bug-bounty program that already struggles to treat a leaked credential as in-scope has an even harder time pricing an agent-provisioned token as a real finding. The evaluation framework doesn't know what to do with it, so it defaults to "out of scope" — and the problem goes invisible in the exact place best positioned to catch it. Severity has to be judged by blast radius, not by where the credential came from.

What to Do Before the Sprawl Compounds

Fewer, sharper moves than the usual checklist, ordered by leverage.

Assume you already have agent credentials, and go find them. Start where they leak — code hosts, secret manager, CI/CD variable stores — and pull every key created in the last ninety days whose owner is an individual developer account rather than an application. A meaningful share of those are agent-adjacent, and they're already in your environment whether or not your inventory admits it.

Make "agent" a first-class class, then run the Kill Chain against it. The schema change is small; the payoff is that agent-specific risk stops being logged as "service account" and disappearing. Then run the audit you already run for service accounts — ghost, shadow, aged, over-shared — against your agent-bound credentials, and expect the findings to be worse, because the inventory is newer and the guardrails are still going up.

Make short-lived the default and static the signed exception. STS to call AWS, a call-time token with an audience binding to reach an internal service, and a fallback to a static key that someone has to explicitly approve. This is the one control whose value survives the missing human, which is why it's worth spending political capital on before the others.

Review what agents can do, not what they were designed to do — quarterly. Effective permissions drift as one-off grants pile up, and months after deployment the answer to "what can this agent actually reach" rarely matches the deploy ticket. The drift is where the next incident is currently incubating.

Where Cremit Fits

If you're nodding at the governance-vacuum framing and wondering how to operationalize it, that's the gap we built Argus to close: continuous scanning for agent-created credentials across the surfaces where they leak (code repos, CI/CD, agent config files, chat channels), ownership mapping that traces a found credential back to the agent that made it and the human who deployed it, and rotation built for the ephemeral cadence agents actually run at. See argus.cremit.io for how we approach it. We'll also say the honest thing: detection is necessary but not sufficient. It's the instrument that tells you how big the vacuum is. Closing it is a governance decision only your organization can make.

Every agent action is a credential action. The teams that treat that as a governance shift will spend the next two years extending an identity program they already trust. The teams that treat it as a provisioning task will spend those two years writing the service-account postmortem again, with a bigger number at the top.