How to store credentials for MCP servers: separate identity, secrets, and scope
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.
MCP server credentials are production access. They need the same discipline as any other path into a database or API.
Separate the four identities
Teams often talk about “the MCP credential” as if it is one thing. In production, it is usually four things: the human user, the AI client session, the MCP server identity, and the downstream database or API role.
If those layers collapse into one shared secret, audit trails become vague and permission changes become risky.
Related: Temporary credentials for AI database agents.
Keep secrets out of prompts and config snippets
Credentials should live in a secret manager, vault, platform secret store, or managed identity system. The model should never see raw secrets, and users should not paste them into a chat or shared agent config.
The MCP server should receive only what it needs to request scoped access.
Related: AI database access review checklist.
Use scoped downstream roles
A database credential for an MCP server should not be the owner account. Start with read-only roles, approved schemas, tenant filters, row limits, and column-level restrictions where needed.
For example, a revenue summary tool may need access to approved reporting views, not every raw invoice, customer, and payment table.
Related: Column-level permissions for AI database agents.
Make credential use observable
When a tool call uses a credential, the audit trail should show user, workspace, tenant, MCP tool, downstream role, source system, time, and result shape. That record is what lets teams debug access later.
Without it, every AI answer becomes harder to explain than the dashboard it replaced.
Related: Audit logging for MCP workflows.
Rotate by design
Credential rotation should not break every AI workflow. Keep secrets centrally managed, avoid long-lived local tokens, and prefer temporary credentials when the platform supports them.
If rotation requires editing prompts or redistributing config files, the credential model is too manual.
Where Conexor fits
Conexor is MCP infrastructure for teams connecting AI clients to databases and APIs. Credential handling is one part of making that access controlled, scoped, and inspectable.