Note: the scenarios in this post are hypothetical — assembled from common credential-management patterns, not accounts of any real company.
Here's a setup we keep running into: a team with seven agents in production, all calling the same CRM, the same email API, the same model provider — and all of them using the same API keys. One Stripe key. One OpenAI key. One CRM token. Pasted into every agent's config, committed to who-knows-how-many repos, sitting in a contractor's laptop from the pilot phase. It works fine. It works fine right up until it doesn't, and then it's a 2 AM scramble.
The scenario that usually ends it: a support agent's logs get pasted into a public debugging thread. Not the key itself — the agent's error output, which included the full request headers. Someone spots the pattern, extracts the CRM token, and starts poking around. The team finds out when the CRM's anomaly alerts fire at 1:40 AM. Now they have to rotate the token. And because every agent shares it, rotating means touching seven agents, three of which are running long jobs that will die mid-flight, plus the contractor's laptop, plus the staging environment that borrowed production creds "temporarily" six months ago. One leak, and the whole fleet's access gets rebuilt by hand in the dark.
Identity is the join key for everything else
There's a deeper problem than the scramble, and it's the reason per-agent credentials matter even if you never have a leak. Every governance control we've written about on this blog — per-agent budgets, allowlists, approval queues, kill switches — assumes the gateway can tell agents apart. A budget caps an agent. An allowlist permits an agent to call certain tools. An audit log records what an agent did.
With a shared key, none of that attaches to anything real. Seven agents presenting the same credential look like one actor with expensive habits. Which agent burned the $1,900? The logs say "the CRM token did it." Which agent should be killed right now? You can't — the kill switch has no identity to target, so your choices are kill everything or kill nothing. The shared key doesn't just create a rotation problem. It makes the entire governance stack anonymous, and anonymous agents can't be governed. They can only be trusted. Trust is not a control.
What per-agent credentials look like in practice
The idea is simple; the discipline is the hard part. Each agent gets its own credential, issued by the gateway, and presents it on every call that goes through the proxy. The proxy maps the credential to the agent's identity — and from there, to its budget, its allowlist, its approval policy, its kill-switch state. The real third-party API keys (the Stripe key, the model provider key) live only in the proxy. The agents never see them. An agent's credential lets it ask the proxy to act; it never lets the agent act directly.
Issuing one should be boring. Register the agent, name its owner (no name, no agent in production — same rule as budgets), attach its policy, and the gateway mints a credential scoped to that agent. The walkthrough in our docs shows the full flow, but the shape of it is: one agent, one credential, one policy, one human responsible.
Scoping is where per-agent credentials pay for themselves twice. The credential doesn't just identify the agent — it carries what the agent is allowed to touch. The triage bot's credential can reach the CRM's read endpoints and the ticket API. It cannot reach billing endpoints, even if the agent tries, because the credential doesn't grant them. This is defense in depth: the allowlist says what the agent may do, and the credential scope says what the agent can do even if the allowlist has a hole. Two different mechanisms, same answer.
Rotation without the scramble
Back to the 1:40 AM scenario, but with per-agent credentials. The leaked token belongs to one agent: the support bot. The runbook is three steps. Revoke the credential. The agent's next proxied call comes back denied with a clear reason:
{
"verdict": "deny",
"reason": "credential_revoked",
"agent": "support-bot",
"revoked_at": "2026-10-13T01:52:00Z"
}Reissue a fresh credential for that agent. The agent picks it up (or gets restarted with it — ninety seconds of downtime for one bot). The other six agents never notice. No fleet-wide rebuild, no touching the contractor's laptop at 2 AM, no killing long-running jobs. The blast radius of a leak is exactly one agent, because the credential was scoped to exactly one agent.
This is also why credential lifetimes matter. Long-lived credentials are convenient and dangerous; short-lived ones are safer and annoying. The middle ground we recommend: credentials with a 90-day TTL and automated rotation, plus immediate revocation on any anomaly signal — spend spike, denied-attempt burst, off-hours behavior change. The gateway watches for those anyway for budget and anomaly purposes; wiring them to credential revocation is one step further. An agent that suddenly behaves strangely shouldn't just get a budget alert. It should lose its credentials until a human says otherwise.
The migration: how to get there from one shared key
Nobody gets to start from a green field. You're migrating, which means doing this without breaking production. The order that works:
First, inventory. List every key and token your agents share, and which agents use which. This takes longer than you think — the staging environment borrowing production creds, the contractor's laptop, the cron job someone set up nine months ago. You can't scope what you haven't found.
Second, put the proxy in front and move the real keys into it, but keep the agents' existing configs working. The proxy accepts the old shared credential temporarily and logs which agent (by source, by behavior, by anything you have) each call came from. This is your mapping phase. It usually takes a week or two, and the logs from it become your per-agent policy drafts — which tools each agent actually touches, what its spend looks like, what its normal hours are.
Third, issue per-agent credentials and cut each agent over one at a time, starting with the least critical. Each cutover is: mint credential, attach the policy you drafted from the mapping logs, swap the agent's config, revoke the old shared key for that agent's paths. If something breaks, the blast radius is one agent, and you can roll that one agent back.
Fourth, kill the shared keys. All of them. The staging ones, the contractor's copy, the one in the wiki page nobody admits to writing. A shared key that still works is a backdoor around everything you just built. This step is the one teams postpone, and it's the one that matters most. Set a date. Send the calendar invite. Rotate on the date even if it's inconvenient — especially if it's inconvenient, because attackers don't check your calendar.
The honest caveats
Per-agent credentials are overhead. There's a registry to maintain, rotations to run, and one more thing that can break at 2 AM (though it breaks far more gracefully than a shared key does). For a team with one agent and one developer, this is overkill — a single agent with a single credential is per-agent credentials, and you're already done. The machinery earns its keep around agent three or four, when "which agent did this" becomes a question you ask more than once a month.
Credentials also don't fix a compromised agent, only a compromised key. If the agent itself is behaving maliciously — prompt-injected, say — its valid credential will happily present itself to the proxy while the agent does bad things. That's what the allowlist, the budget, and the kill switch are for. Credentials answer "who is asking." The rest of the stack answers "and should they be allowed to." No single control does both jobs.
And finally: the proxy holding all the real keys is a concentration of trust. It has to be — that's the whole architecture. Which means the proxy's own key storage needs to be the most boring, most audited, most locked-down part of your setup: secrets manager, not env files; rotation on a schedule; access logs. If the proxy's key vault is a sticky note, you've built a very sophisticated sticky note.
The short version
One shared key for the fleet means one leak rebuilds everything, and it makes every governance control anonymous. Per-agent credentials give each agent an identity that budgets, allowlists, approval queues, and kill switches can actually attach to. Scope each credential to what its agent needs, rotate on a schedule plus on anomaly, and migrate one agent at a time. The 2 AM scramble becomes a three-step runbook for one bot.
You can watch credential-scoped verdicts in action in our policy playground — the same decision engine the production proxy runs, no signup.