Answer target
Who holds the credentials an MCP server uses, and how should they be managed?
Updated June 25, 2026
Short answer
The MCP specification covers client-to-server authorisation through OAuth 2.1. It says nothing about downstream credential custody: where the API keys and tokens an MCP server uses to reach other systems are stored, what can read them, or how they are revoked. Locally, those credentials usually sit in plaintext env blocks in claude_desktop_config.json or .mcp.json. Remotely, every hosted vendor improvises. MCP credential management is the practice of storing those credentials centrally, granting each server only what it needs, resolving values at runtime, and logging every access.
What to do now
MCP secrets management and MCP credential management describe the same job: deciding where an MCP server's downstream credentials live and what can read them. Start by finding every place a server's keys sit today.
- List the env blocks in claude_desktop_config.json and .mcp.json that hold real API keys.
- Note which remote MCP servers you have handed tokens or keys to, and how.
- Separate non-sensitive settings from live credentials.
- Decide which servers genuinely need a live downstream credential at all.
Better pattern
The best MCP credential management pattern keeps downstream credentials out of static config. Store each credential once, grant an MCP server only the secrets it needs, resolve the value at runtime, and keep a log of every access. Config describes tools and routing; it should not become a credential store.
Avoid
Avoid one shared key reused across every MCP server, production credentials pasted into local JSON config, downstream keys passed in URL query strings, and treating the MCP OAuth handshake as if it also protected the credentials the server uses downstream.
Example
A GitHub MCP server for one repository should resolve only that repository's token. It should not sit in a config file next to your Stripe, database, and analytics keys, where any process reading the file inherits all of them.
What the MCP specification actually covers
The Model Context Protocol defines how an MCP client authorises to an MCP server. The current authorisation model is built on OAuth 2.1, with the server acting as an OAuth resource server and the client obtaining scoped access tokens. That protects the channel between the client and the server. It does not describe custody of the credentials the server then uses to reach GitHub, a database, a payment provider, or any other downstream system. Those downstream credentials are out of scope for the spec, which leaves each implementer to decide how they are held.
Local reality: plaintext keys in config
For local MCP servers, the common setup puts credentials in an env block inside claude_desktop_config.json or a project .mcp.json. These are plaintext files on disk. Every server defined in them, and often any process that can read the file, inherits those values. There is no scoping between servers and no record of what read what. This is convenient, and it is also the widest blast radius.
- Credentials sit in plaintext env blocks on disk.
- One file often holds keys for several unrelated servers.
- There is no per-server scoping and no access log.
Remote reality: every hosted vendor improvises
Hosted and remote MCP servers turn the vendor into a credential custodian, and the spec gives no guidance on how to do that. Patterns seen in public documentation include attaching an end user's token to a server instance through an API, passing API keys as URL query parameters, and setting keys as environment variables on the host. Some hosting products market token lifecycle management as a feature. The point is not that any one approach is wrong; it is that there is no shared standard, so custody quality varies from vendor to vendor.
How to store credentials for MCP servers
Store each downstream credential once under its provider. Give each MCP server a named identity and grant it only the specific secrets it needs. Resolve those values at runtime, when a tool call needs them, rather than baking them into reusable config. Keep non-sensitive settings such as endpoints and flags in config, and keep real keys out of it. This keeps the credential usable without leaving it readable in a shared file.
Is a dedicated MCP secret vault the answer?
An MCP secret vault helps, but storage alone is not the whole problem. A vault that only encrypts values still needs to answer which server can resolve which credential, in which project, and how an operator revokes that access after an incident. The useful unit is not the encrypted blob; it is the grant: a specific server allowed to resolve a specific credential, with expiry, revocation, and an access record.
Short-lived and ephemeral credentials for MCP servers
Short-lived credentials expire quickly, so a leaked value is only useful for a short window. Ephemeral credentials go further: they are minted per session or per task and are not meant to persist. Whether an MCP server can use them depends on the downstream provider. OAuth-based providers can issue short access tokens with refresh; many API-key providers still issue long-lived static keys with no expiry, which no amount of tooling can shorten. Be honest about which case you are in before promising short-lived access.
- Short-lived: the credential expires on a timer, limiting the window of a leak.
- Ephemeral: the credential is minted per session or task and not stored long term.
- Feasibility is provider-dependent, not something a custody layer can force onto a static key.
Practical workflow
- 1Inventory server credentialsList every credential each local and remote MCP server can currently reach.
- 2Separate config from secretsKeep endpoints and flags in config; move live keys into managed custody.
- 3Grant per serverGive each server a named identity and grant only the credentials it needs.
- 4Resolve and log at runtimeResolve values when a tool call needs them and keep a record of each access.
Keys in MCP config vs Scoped runtime custody
Frequently asked questions
Does the MCP specification say how to store server credentials?
No. The specification defines client-to-server authorisation using OAuth 2.1. Custody of the downstream credentials an MCP server uses is out of scope, so each implementation decides where those keys live and what can read them.
Where do local MCP server credentials live by default?
Usually in plaintext env blocks inside claude_desktop_config.json or a project .mcp.json. They are readable files on disk, shared across the servers defined in them, with no per-server scoping or access log.
Can MCP servers use short-lived credentials?
Sometimes, and it depends on the downstream provider. OAuth providers can issue short access tokens; many API-key providers only offer long-lived static keys. A custody layer can scope and revoke access to a key, but it cannot make a static key expire on its own.
Get the field notes: how 17 AI products handle customer credentials
Leave your email and we will send the field notes, compiled from public docs with sources. Alan, the founder, may ask one question about how your product holds credentials today. No list, no spam.
Where ScopeHold fits
ScopeHold treats an MCP server as a named agent identity. It stores each downstream credential with KMS-wrapped envelope encryption, grants a server only the secrets it needs with expiry and revocation, resolves the value at runtime through scopehold run, and logs every access including denials. Truly short-lived, provider-minted credentials are provider-dependent and remain on the roadmap rather than shipped today.