Stop Pasting API Keys into Agent Configs
Somewhere on a laptop in your team there is a config file with a stack of API keys in plaintext. If you have connected AI agents to real tools this year, you know the file: the MCP config, the .env next to it, the notes doc where keys live "temporarily". Pasting API keys into agent configs is how nearly everyone starts, and it is an anti-pattern that compounds with every tool you add.
Why API keys and AI agents mix badly
An API key on its own is not evil. It is a fine credential for one server talking to one service: minted deliberately, stored in a secrets manager, rotated on a schedule. The problem is that agent setups have none of those properties.
- Agents multiply keys. Every tool your agent touches wants its own credential. Ten tools means ten long-lived secrets sitting in one JSON file.
- The file travels. Agent configs get synced in dotfiles, pasted into chat to help a colleague, shared on screen, and occasionally committed to a repo. Every copy is a full credential.
- Keys are account-scoped, not task-scoped. An agent that only needs to read support tickets usually holds a key that can delete them, because that is the only kind of key the service issues.
- Nobody rotates them. Rotation breaks the agent, and nobody remembers where all the copies live. The honest answer to "when was this last rotated" is usually "never".
- There is no identity behind the call. The SaaS logs "the key did it", not "the agent, acting for this person, did it". When something goes wrong, the log tells you nothing useful.
Most advice on MCP API key security focuses on transport: use HTTPS, keep secrets out of the repo. Necessary, but it misses the structural point. The credential itself has the wrong shape for the job. (For the protocol-level view, transports and auth flows, see [MCP security basics](/blog/mcp-security-basics).)
A realistic failure, no drama required
A contractor helps you wire up an agent workflow in March. To make it work, someone sends them the CRM key in a chat message. They paste it into the config on their machine, the project ships, the contract ends.
It is July now. That key still works. It still has full account access, because the CRM only issues full-access keys on your plan. It exists in a chat thread, on a laptop you do not control, and in a config file the contractor has forgotten about. Nobody has done anything wrong yet, and that is the uncomfortable part. There is no breach to detect. There is just standing access with no owner, no expiry, and no way to see whether it is being used.
Most key incidents look like this. Not a hack you can point to, but access nobody remembers granting.
OAuth vs API keys for agents
The alternative is not exotic. It is the same flow you use when an app asks to see your calendar: sign in with the provider, read a consent screen, approve specific scopes.
| Question | Pasted API key | OAuth connection |
|---|---|---|
| Who approved it? | Whoever pasted it, no record | A consent screen, tied to a user |
| What can it do? | Whatever the account can | The scopes granted, nothing more |
| Where does the secret live? | Plaintext, in every copy of the file | Server-side, as a revocable token |
| How does it die? | Someone remembers to delete it | One click revokes that connection |
| What does the log show? | "The key did it" | Which connection, for which user |
OAuth tokens can leak too; this is not magic. The difference is lifecycle. Consent at mint, scope at grant, revocation at will. A pasted key has none of that by default, and no amount of careful handling adds it later.
What good looks like: consent, vault, revocation
Consent, not paste. Every connection starts with a consent screen that names the scopes. The person approving sees exactly what the agent will get, and the grant is recorded against their identity instead of floating free.
A vault, not a file. Secrets, whether OAuth tokens or the API keys you genuinely cannot avoid, live encrypted server-side and are decrypted only at the moment of a call. They never sit on laptops, in dotfiles, or in repos. When a key is the only thing a provider offers, one copy in a vault beats five copies in config files.
Revocation with a trail. You can kill one connection without rotating everything else, and there is an [audit trail of what the agent actually called](/blog/ai-agent-audit-trail), so "what did this credential do" gets answered with a list instead of a shrug.
Where a gateway fits
This is the main practical argument for putting an [MCP gateway](/gateway) between your agents and your tools: the credential problem gets solved once, centrally, instead of once per config file. You connect each tool a single time, by OAuth where the provider supports it, by API key into an encrypted vault where it does not. Agents talk to one endpoint, and every connection stays individually revocable. We walked through the wider model in [how an MCP gateway changes your security posture](/blog/mcp-gateway-security).
This is also the model we built Tulimoa's gateway around: OAuth sign-in, a per-secret encrypted vault, secrets used only at the moment of a call, and per-connection revocation. It is in early beta and not self-serve yet, so take the pattern rather than the pitch. Any setup that gives you consent, a vault, and revocation beats a folder full of pasted keys, whoever builds it.
Do this today
You do not need new infrastructure to start. You need an inventory.
Step 1: Open every agent config on your machines and count the credentials, .env files included.
Step 2: For each key, answer four questions: who created it, what can it access, when was it last rotated, and how would you kill it in the next five minutes if you had to?
Step 3: Any key with an "I don't know" attached is your first move. Rotate it, scope it down if the provider allows, and put the replacement somewhere encrypted with a named owner.
The keys you cannot answer for are not hypothetical risk. They are standing access, today, on machines you may not control. Start there.