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.
Top comments (0)