How should MCP servers store credentials?

The fastest way to make an MCP demo work is to put a powerful credential close to the tool.

The fastest way to make an MCP deployment fragile is to leave it there.

For production MCP servers, I’d separate four identities:

• the human user
• the AI client session
• the MCP server identity
• the downstream database/API role

If those collapse into one shared secret, access control and audit trails get vague fast.

A safer pattern:

• keep secrets in a vault or managed secret store
• never expose raw credentials to the model
• use scoped downstream roles
• start read-only for database access
• log user/workspace/tenant/tool/source/result shape
• rotate centrally
• prefer temporary credentials where possible

The model should not “know” the secret. The MCP server should know how to request the narrow access needed for the tool call.

Longer version: How to store credentials for MCP servers

MCP credentials are not config trivia. They are production access.