Here’s an uncomfortable audit you can run in about ten minutes. Pick any agent your org deployed this year. Find the credentials it authenticates with — to the model provider, to your internal APIs, to whatever tools it can call. Now answer three questions: Is that credential unique to this agent? When does it expire? If this specific agent went rogue in the next hour, could you revoke its access without breaking anything else?
If you got three yeses, this post is a victory lap. In most shops I’ve seen, the honest answers are: it’s the team’s shared key, it doesn’t, and no.
In agent sprawl is your next production incident I argued that agent fleets are recreating microservices sprawl with worse observability. This post is about the specific layer of that sprawl that security teams are now staring at: every agent is a non-human identity, and almost nobody is governing them like identities.
The numbers are worse than you think
The identity industry has been counting, and the counts are grim. Non-human identities — service accounts, CI runners, workloads, and now agents — outnumber human identities 25–50× in a typical enterprise, and that ratio predates the agent wave. Only a small fraction of organizations claim full visibility into their service accounts; the rest are governing what they can see, which is not what they have.
The leak side is uglier. Secret-scanning reports keep finding tens of millions of non-human credentials exposed on public GitHub in a single year — and the long-lived ones don’t die: a large share of secrets leaked years ago still worked when re-tested. A static API key doesn’t get tired, doesn’t get offboarded, and doesn’t show up in your leaver process.
Now add agents. Every agent you deploy is a new non-human identity — with runtime decision-making attached. A cron job with a leaked key does the one thing it was scripted to do. An agent with a leaked key does whatever the credential permits and the prompt suggests. The credential is the same kind of artifact; the actor behind it is categorically more capable. That’s the shift that makes the old service-account sloppiness newly dangerous.
What a shared key actually costs you
The failure isn’t hypothetical, and it isn’t really about leaks. A shared, long-lived key breaks three operational properties you already rely on everywhere else in production.
Attribution dies first. When six agents authenticate as the same principal, your audit log answers “what happened” but not “who did it.” The no anonymous inference endpoints principle applies on both sides of the agent: you should know which human or system an agent is acting for, and you should equally know which agent performed the action. During an incident, “one of the agents deleted the index” is not a line you want in the timeline. I’ve watched a team spend the better part of a day correlating tool-call timestamps against agent scheduler logs to figure out which of four agents had made a mess — information that a per-agent identity would have put in the first log line.
Scope becomes a fiction. Least privilege is meaningless when the privilege is pooled. Your careful read-only diagnostic agent and your remediation agent with restart authority hold the same token, which means your effective security posture is the union of everything any of them needs. Prompt injection turns this from untidy to hot: an attacker who hijacks the weakest agent in the fleet — the internal Slack summarizer nobody threat-modeled — inherits the strongest agent’s authority.
Revocation becomes an outage. The one clean kill switch you have — invalidate the credential — now takes down every agent at once. So in practice nobody pulls it, the same way nobody rotates the database password that fifteen services share. Your incident response option degrades from “demote the misbehaving agent” to “either tolerate it or take the fleet down.”
If you’ve read error budgets for autonomy, that last one should itch. The whole premise of budget-driven governance is that an agent’s authority can be mechanically narrowed when its track record degrades. The credential is where that narrowing has to land. A demotion policy that isn’t reflected in what the agent can authenticate to do is a dashboard, not a control.
Identity is the enforcement layer for everything else
This is the part I want to push on, because it reframes identity from a security checkbox to the substrate of agent governance.
Every governance mechanism the industry is converging on — autonomy ladders, action-class budgets, policy gates, human approval flows — ultimately has to answer one question at runtime: can this agent perform this action right now? Policy engines evaluate that question. But the identity is the input: who is asking, with what standing authority. And the credential is the output: what the answer physically permits.
Get identity wrong and the rest of the stack is decorative:
- A policy engine can’t distinguish agents that present the same principal.
- An autonomy budget can’t demote an agent whose credential scope never changes.
- An approval flow can’t bind an approval to an agent if any agent can replay it.
- An audit trail can’t support a blameless postmortem if the actor column is a shared name.
The inverse is also true, and it’s the good news: get identity right and the mechanisms you already have start working better. Your existing IAM policy language, your existing audit pipeline, your existing secret-rotation tooling — all of it applies, because agents stop being a weird new thing and become what they should have been from the start: workloads with identities, governed like workloads.
What good looks like
None of this requires new science. The workload-identity stack that platform teams built for microservices carries over almost unchanged.
One agent, one identity. Every agent instance — or at minimum every agent role — authenticates as its own principal. This is the non-negotiable. Everything else composes from it.
Short-lived, attested credentials instead of static secrets. SPIFFE/SPIRE-style certificates, cloud workload identity federation, or OAuth token exchange (RFC 8693 — the same mechanism I covered for MCP in no anonymous inference endpoints) issue the agent an identity derived from where and what it is, not from a secret someone pasted into an env var. Lifetimes in minutes to hours mean a leaked credential is a narrow window, not a standing capability. If your platform already does workload identity for services, extending it to agents is configuration, not architecture.
Scope credentials to action classes. If you’ve partitioned your agent’s action space by blast radius — read/diagnose, reversible mitigation, service-impacting change — mint credentials per class. The diagnostic loop runs on a read-only token; the remediation step exchanges it for a narrowly scoped, single-use elevation. This makes the autonomy ladder enforceable: a demoted agent’s next credential simply doesn’t include the revoked class.
Route agent traffic through a choke point that knows the identity. An MCP gateway or equivalent proxy is where identity, policy, and logging meet: one place that binds agent identity + tool call + decision into a single audit record. Sprawl governance needs a surface; this is it.
Make revocation a first-class runbook. Per-agent revocation should be one command, tested, with a known blast radius of exactly one agent. If you’ve never revoked an agent’s identity in anger or in a game day, you don’t know your mean time to de-authorize — and as with demotion, if the mechanism requires a meeting, it’s not a mechanism.
Honest caveats
Per-agent identity is not free. Identity issuance infrastructure (SPIRE servers, token-exchange services) becomes production-critical — if it’s down, your agents can’t authenticate, which is a new failure mode you’re trading for the old ones. Short-lived credentials add latency and a renewal loop that can itself fail; cache and monitor it. And scoping credentials per action class assumes you’ve defined action classes, which is the real work — the credential plumbing is the easy 20%.
There’s also a genuinely unsettled question: what’s the right identity granularity for ephemeral sub-agents that exist for ninety seconds inside a parent task? Per-instance identity for those can mean thousands of principals a day. The pragmatic answer today is identity-per-role with request-level attribution propagated in context — but I’d call that a current compromise, not a solved problem.
What to do Monday
- Inventory the credentials your agents actually hold. Not what the design doc says — what’s in the env vars, the secret manager, the config. Count how many agents share each one. That number is your identity blast radius.
- Kill the worst shared key first. The one held by the most agents with the widest scope. Split it, scope it, shorten it.
- Put expiry on everything. If your model-provider and internal API tokens can’t expire, put them behind a broker that can. Static forever-keys are the asbestos of agent infrastructure — fine until disturbed.
- Bind audit logs to agent identity. Every tool call, every inference request, every mutation should carry which agent, acting for whom. Your future incident timeline is built from this.
- Rehearse per-agent revocation. One agent, one command, nothing else breaks. If you can’t do that today, you’ve found this quarter’s platform work.
Security teams spent a decade learning that service accounts were the unguarded side door. Agents are service accounts that can improvise. The identity discipline we half-adopted for workloads is now the load-bearing wall of agent governance — and unlike most of the agent stack in 2026, this part isn’t experimental. The tools exist. The patterns are boring. Boring is exactly what you want holding up the blast radius.