How should an AI agent store and use API keys for MCP servers and skills?

Short answer: have the owner create one key per agent per service, with the smallest scope the job needs (read-only, search-only, test or paper mode first). Keep it in an environment variable or the client's secret store, never in a committed config, SKILL.md or chat. Prefer vendor OAuth when it is offered, pass each MCP server only the variables it needs, and revoke the key when the tool is removed. In our scan of 115 curated skill repos and MCP servers, 18.3% had committed secret-like strings and 14.8% had a file that reads credentials and makes a network call, both at medium or higher.

Every MCP server that reaches a paid or private system needs a credential, and the agent holds it. A key pasted into a project file, an owner's personal token reused by a bot, or a server handed the whole environment is how a small mistake becomes a leak or a bill.

This guide uses numbers from our agent skill security research and item facts (maker, cost, scan result, commit) from the Upskill library build of 2026-11-09. We have not measured key-leak incidents; see the last section for what we do not know.

Why MCP servers need more care than skills

A skill is mostly instructions, so many need no key at all. An MCP server exists to give the agent access, so most do. The flagged files are not proof of theft. In the two manual reviews quoted here, the hits were ordinary: Nango's "env passing" hits are its sandbox handing environment variables to user scripts, and its secret-like strings are documentation placeholders such as sk_test_…. Composio's credentials-plus-network high was in a test file. A scanner cannot tell intent, so the rules below limit what any one tool sees.

Credential patterns in tools we have vetted

All 11 are at pass for the commits or file hashes on their pages; 2 are house prompts from Avatar 8 LLC, which runs this site. In the library, 19 catalog items are tagged auth & identity (16 pass) and 9 payments & credential separation.

Seven rules for agent API keys

1. The owner creates the key; the agent asks

The agent should not sign into the owner's dashboards to mint keys. It asks once, naming the key, scope and reason. Owner-blocker batching protocol folds those requests into one short daily message, and Credential and entity separation checklist checks that the account, email and card on the path belong to the right entity before anything is used.

2. One key per agent, per service

Never the owner's personal key, never one key shared across agents. Separate keys can be scoped to one job, show up separately in vendor logs, and can be revoked alone. One email vendor makes the same point publicly: give each agent its own key and let the key's permission level decide which MCP tools it gets (@lettr_com, 2026-10-22).

3. Smallest scope, and practice modes first

Turn on the narrowest mode a tool offers before anything else: Pipedrive MCP Server (community, Nubiia) has PIPEDRIVE_READ_ONLY=true, Attio MCP Server (community) has a search-only tool mode, Stripe AI (official MCP + skills) should start in test mode, and Kraken CLI (official, built-in MCP) runs in paper mode with no key at all. Live keys come after a clean practice run the owner has seen.

4. Environment variables, not config files

Reference keys from config; do not write them into it. A project-scoped MCP config is meant to be committed, so a pasted key in it goes to the repo. One builder's summary for Claude Code: keep secrets out with ${VAR}, and put personal servers in user scope (@toirant, 2026-10-24). When importing a setup from another agent, check that keys landed in env vars rather than plain text (@Madeactual). Never put a key in a SKILL.md, a prompt or chat history.

5. Prefer vendor OAuth; treat managed auth as a vault

When the vendor runs its own OAuth, as with HubSpot MCP plugins (official) and Stripe AI (official MCP + skills), the owner approves scopes in the vendor's screen and can revoke them in one place. Pick single-product grants: Google Calendar MCP asks for Calendar only. Managed layers like Composio and Nango remove per-app key handoffs and refresh tokens for you, but one account then holds grants to many apps. Connect only what the job needs.

6. Give each server only the variables it needs

An MCP server inherits whatever environment you start it with. Pass the one or two variables it needs rather than your whole shell. Logged-in browser sessions are credentials too: we keep LinkedIn MCP Server (community) at review because it imports the owner's personal LinkedIn session, a policy risk on top of the access it grants. In daily vetting since 2026-10-17, 26 of 191 rejections were security findings not cleared on review.

7. Revoke when the tool goes

Removing an MCP server from config does not revoke its key. When a tool is dropped under our keep-or-remove rules, revoke or delete its key or OAuth grant the same day, and rotate any key that was ever pasted into a file or chat.

What the scan says, and what it cannot

Across 115 repos, 42.6% had at least one medium-or-higher automated finding and 9.6% a high or critical one. A static scan cannot see what a hosted server does with your key, and repos change after the commit we checked, so pin what you reviewed.

What builders are asking

Of the 198 public posts about skills and MCP servers we collected on 2026-10-25, 18 mention API keys, secrets, credentials, OAuth or private keys; reading them, 5 are about how agents should hold credentials. The others use the words in passing. A small sample: a hint, not demand data. One of them asks teams to send each MCP server a garbage token and confirm a 401 comes back (@rocklambros).

What we have not measured

We have no data on how often agent keys leak or how fast teams rotate them, and we have not tried to exfiltrate keys from any tool listed. Scope details come from each tool's README.

Let a coach pick and prune

Agent Coach matches vetted tools to your agent's job, checks in daily on what it used, and says what to keep or remove, so unused keys get revoked. It is free. REST and MCP details are in the developer docs. Paste one line into your agent:

Read https://upskill.coach/start and follow it.

Related: CRM access rules, how to vet a skill or MCP server.

FAQ

Where should an AI agent store API keys for MCP servers?

In environment variables or the agent client's own secret store, referenced from config (for example ${VAR} in an MCP config file), never as plain text in a committed config, a SKILL.md, a prompt or a chat message. In our scan, 21 of 115 curated repos (18.3%) had committed secret-like strings flagged at medium or higher.

Should each agent get its own API key?

Yes. One key per agent per service lets you scope it to that agent's job, see what it did in the vendor's logs and revoke it without breaking anything else. Sharing the owner's personal key means one leak or one bad tool call is charged to the owner's whole account.

Is OAuth safer than an API key for an agent?

Usually, when the vendor offers it: the owner approves scopes in the vendor's own screen, nothing is pasted into config, and the grant can be revoked in one place. HubSpot MCP plugins (official) and Stripe AI (official MCP + skills) use vendor OAuth on hosted MCP servers. OAuth is still only as narrow as the scopes approved, so read the consent screen.

Are managed auth layers like Composio or Nango a good idea?

They remove per-app key handoffs and handle token refresh, which is why both are in our catalog. The trade-off is concentration: one account holds grants to many apps, so protect it like a password manager, connect only the apps the job needs, and remove unused connections.

Can an MCP server steal my API keys?

It runs with whatever environment you give it, so a malicious one could. Our scanner flags files that read credentials or environment variables and make a network call in the same file: 8 of 32 (25%) MCP servers and 3 of 37 (8.1%) skills had such a finding at medium or higher. In the manual reviews we quote (Nango, Composio) the hits were ordinary env passing, docs placeholders or test files, but you only know after reading them. Pass each server only the variables it needs.

Questions or corrections: ops@avatar33.com.