Is it safe to connect an MCP server to a production database?
Updated · DBShifts
Short answer
It depends on what the MCP server exposes. A server that offers a 'run SQL' tool backed by full credentials is only as safe as the model's choices. A safe setup uses a read-only user, structured tools instead of raw SQL, a token per client, server-side PII masking, volume limits and a log of every tool call.
Key facts
- MCP (Model Context Protocol) standardises how AI clients discover and call tools; it does not decide what a tool may access.
- The security of a database MCP server lives in its tools and the credentials behind them.
- With a generic SQL tool, the shape of every query is decided by the model.
- Structured tools such as list, filter, aggregate and follow-a-foreign-key bound the query shape by construction.
- Tool results go straight into the model's context, so they need prompt-injection scanning like any other untrusted input.
What MCP does, and what it doesn't
MCP gives AI clients like Claude Desktop and Cursor one way to find and call tools on a server. It is a protocol, like HTTP: it carries requests, it does not judge them. Whether a call is allowed is the server's job.
The risk lives in the tools
A common pattern is a single tool that runs whatever SQL the model writes. That hands the model the full power of the database user: any join, any scan, and writes if the user allows them. Narrow tools are less flexible, and that is the point — each one can be checked against a policy before it runs.
Local versus remote servers
A local MCP server usually keeps the database password in a config file on someone's laptop. A remote server keeps credentials in one place and puts every client behind the same policy and the same log, which is what makes access reviewable.
Checklist
- 1
List every tool the server exposes and what each can reach
- 2
Remove or restrict any tool that accepts raw SQL
- 3
Back the server with a read-only database user
- 4
Give each client its own revocable token
- 5
Mask sensitive columns on the server
- 6
Cap rows per call, calls per minute and reads per day
- 7
Log every tool call and scan results for injected instructions
Common mistakes
The database password in the client config
Client config files get copied, synced and shared. Put a revocable token there instead, and keep the real credential on the server.
One server, one credential, every team
Without per-client identity you cannot see who asked for what, or narrow one team's access without narrowing everyone's.
Trusting tool output
Text in a row can address the model. Treat results as data, flag what looks like instructions, and tell the client so.
How DBShifts does it
- The DBShifts MCP endpoint exposes 26 tools: reads (list_tables, query_table, list_views, query_view, aggregate_table, query_related), governed retrieval for RAG (list_search_indexes, search), governed metrics (list_metrics, query_metric), background jobs (submit_job, get_job, list_jobs, cancel_job), change feeds (list_feeds, subscribe_changes, poll_changes, unsubscribe_changes), history (list_history, diff_history, query_at_commit), access requests (request_access, list_access_requests) and approval-gated writes (list_actions, propose_action, propose_action_plan). None accepts raw SQL.
- The client config holds a scoped agt_ token, never a database password.
- Every tool call is checked against the gateway's policy and logged; a result that looks like prompt injection arrives with a warning block before the data.
Questions people also ask
Does MCP encrypt the data?
Encryption comes from the transport — HTTPS for a remote server. MCP itself defines how tools are discovered and called, not how they are protected.
Can Claude Desktop and Cursor share one gateway?
Yes. Give each client its own token so you can see them separately in the log and revoke one without affecting the other.
Related questions
Give AI agents data access you can defend
Scoped tokens, PII masked on the server, every request audited. Free to start.
Start free18 answers in this series. See all.