The first way anyone gives an agent access is the obvious one: create an API key at the vendor, paste it into the agent's config, done.
It works. It keeps working right up until the point where you have four agents, six vendors and no idea which credential is where — and by then, unwinding it is a project.
What the per-agent-key model actually costs
A quadratic number of credentials. Four agents that each need five apps is twenty credentials to create, store, rotate and eventually revoke. Nobody maintains that grid; they maintain the parts they remember.
Credentials in configuration files. An API key in .cursor/mcp.json is a key
one git add -A from being committed, one screen-share from being read aloud,
and one laptop from being somewhere it should not be. Everyone knows this.
Everyone does it anyway, because the alternative is more work at the moment you
just want the thing to run.
No attribution. A vendor API key is not a person. When something surprising happens, the vendor's audit log says the key did it. Which agent? On whose behalf? Prompted by whom? The key does not know and cannot say.
Offboarding is archaeology. Someone leaves. Their agents keep working, because a key does not know about your workspace membership. Finding every place that key was pasted is now someone's afternoon, and being sure you found them all is impossible.
Permissions are whatever the vendor's scopes are. Vendor scopes are broad by
design — gmail.modify covers trashing threads, drive means your Drive. If you
want "read anything, delete nothing" and the vendor has no scope shaped like
that, you do not get it. Your only remaining control is asking the model nicely.
Rotation nobody does. Rotating a key means finding every config that has it, updating them together, and not breaking anything mid-flight. So it does not happen, and keys live for years.
What one gateway changes
The agent gets a single URL and a single credential. Everything behind it — which vendors, which accounts, which scopes — is configuration in one place rather than secrets in many.
Connect once, per app, not per agent. You authorise Gmail once through Google's own consent screen. Every agent that is allowed to reach it, does. Add a fifth agent and there is nothing to distribute.
Credentials you never handle. The authorisation goes into an encrypted vault that only the server role can decrypt, and is refreshed before it expires. There is no token in a config file because there is nothing for one to hold.
Better: often no credential at all. Clients that can open a browser — Claude, ChatGPT, Codex — authorise as you, over OAuth. Their configuration contains a URL and nothing else. A config with no secret in it cannot leak a secret.
Attribution that survives. Every call in the activity log carries who it acted as, which client made it, which connection it used and what came back. Not "the key did it" — a name.
Offboarding is one action. Workspace membership is re-checked on every single call, so removing a person stops their agents on the very next request. Not when a token expires. Not when someone remembers.
Permissions the vendor does not offer. Read, write and destructive per app, enforced at the gateway before the call goes anywhere. "This agent may read anything and delete nothing" is a rule you can actually have, even though no vendor sells a scope shaped like it.
Side by side
| An API key per agent | One gateway | |
|---|---|---|
| Credentials to manage | Agents × vendors | One per person |
| Where secrets live | Config files, on laptops | Encrypted vault, or nowhere |
| Adding an agent | Distribute every key again | Nothing to do |
| Attribution | The key did it | A named person, per call |
| Offboarding | Find every pasted key | Remove the member |
| Permission granularity | Whatever the vendor's scopes are | Read / write / destructive, per app |
| Rotation | Manual, so never | Replace one credential |
| Blast radius of a leak | That vendor, until noticed | Scoped, and revocable in one place |
The objection worth taking seriously
A single gateway is a single point of failure, and a single credential is a single thing to steal. Both are true.
The failure point is real and worth planning for. The credential is a weaker objection than it looks: one credential you can rotate in one action, that is scoped to a person, that can be revoked centrally and whose every use is logged, is a materially better position than twenty you cannot find. Concentration is only bad when the concentrated thing is unmanaged.
The version we would actually recommend
Use the browser flow wherever the client supports it, so the strongest configurations have no credential in them at all. Use a key only where a client cannot open a browser. Set read/write/destructive per app before any agent gets access, not after. And read the activity log once, after the first real task — it is the fastest way to find out what your agents actually do.