MCP Security: Should You Give Claude or Cursor Direct Database Access?

Let me start with a scenario that's becoming common in 2026. You've been using Claude or Cursor to write your app. Someone (maybe me, in an earlier post) suggests connecting the AI to your database over MCP so it can answer questions about your real data, set up views, even manage schema. It's genuinely useful — I use it every day. But before you wire an AI assistant to a production database, there's a question you should answer deliberately rather than by default:

What are you actually granting, and to whom?

The honest answer is that "MCP database access" isn't one thing. It's a spectrum from "harmless read-only exploration of a dev database" to "credentials to your production database flowing through a third party's infrastructure." The security posture of your setup depends on three variables, and you should be able to name all three before you connect anything.

Variable 1: Where Does the AI's Connection Actually Live?

This is the single biggest decision, and it's the one most people get wrong because the options look identical from the outside.

Direct connection (credentials in the MCP config). The most common setup: you run an MCP server process that connects straight to your database using a connection string stored in your config file — claude_desktop_config.json or .cursor/mcp.json. When the AI calls a tool, the server runs the query. The connection is local, but your database credentials sit in a plaintext config file, and the MCP server process itself has an open, privileged connection to your database for as long as it runs. If that process is compromised — or if the AI is tricked into a destructive tool call — there's nothing between the AI and your data.

Cloud relay (credentials on their server). Some "connect your database to ChatGPT/Claude" services don't run locally at all. You hand them your connection details through a web dashboard, they connect to your database from their infrastructure, and your AI client talks to their cloud service. Now your credentials and your data are on someone else's server. This is the worst of both worlds and the hardest to justify.

Local app with a managed MCP server (credentials never leave your machine). The setup I built Basevolt around: a desktop app holds your database connections, and it exposes an MCP server on localhost that your AI client connects to. The AI never sees your credentials — it talks to the local app, and the app talks to the database. The credential file problem disappears, and you get a layer where access can actually be controlled.

The rule of thumb: the AI should never hold your database credentials, and your credentials should never leave your machine. If either of those is true in your setup, you're on the risky end of the spectrum.

Variable 2: What Can the AI Actually Do?

"MCP database access" can mean anything from "run SELECT queries" to "drop tables." The scope of what the AI can do is a security decision you're making, whether you realize it or not. The question to ask is: what's the worst thing this setup could do, and do I have a control that stops it?

The controls, in rough order of importance:

Read-only mode. If the MCP server supports it, the single highest-value control. The AI can query and describe the schema but cannot write, alter, or delete. For production databases, this is the difference between "AI as an analyst" and "AI with a loaded gun." If you're connecting an assistant to anything with real data, start read-only.

Scoping to specific data sources or tables. You probably have more than one database connected — a production one and a scratch one, or several projects. Being able to choose which ones the AI can touch means a mistake in one place doesn't reach everything.

No direct SQL execution. Some MCP setups expose structured operations instead of raw SQL — "create a view", "set a field type", "list tables" — rather than "run this arbitrary query string." That's a meaningful safety improvement: the AI can do useful things without being able to run anything it can dream up.

Access revocation. The ability to cut off the AI's access instantly — close the app, disconnect the base, toggle the server off — matters more than you'd think. With a local app it's a button; with a cloud relay, you're relying on their admin panel and their timing.

Variable 3: Where Does Your Data Go When the AI Reads It?

Here's the part people forget. Even in a fully local setup, when the AI answers a question about your data, the query results are sent to the AI provider — that's how the AI can read them and respond. That's fundamental to how these tools work; the model needs to see the data to talk about it.

So the real question isn't "does my data leave my machine?" — with any AI assistant, the data you ask about goes to the model. The question is what data are you asking about, and do you have the right to send it there? If you're exploring a local dev database with synthetic data, this is a non-issue. If you're connecting an assistant to a production database with customer PII, you're sending that data to a third party's model infrastructure — which may be fine under your policies, or may be a GDPR/contract compliance problem. Know which one you're in before you connect, not after.

The Setup I'd Actually Recommend

Let me give you a concrete posture, not just principles. This is the configuration I run for my own projects:

A local app (or local MCP server) holds the connections — never a cloud relay, and never credentials sitting in the AI client's config file.
Production databases start read-only. If you want the AI to write, point it at a staging or scratch copy first. The "helpful agent that renames a column on the wrong table" story is not hypothetical.
Scope the AI to the bases it needs. If the MCP server lets you choose which data sources it exposes, expose the minimum.
Assume everything you ask about goes to the model. So don't ask the assistant about data you shouldn't be sending to a third party. This is the rule that catches people: the architecture is fine, the data is the problem.

That last point deserves emphasis, because it's where most "MCP security" discussions quietly end: the protocol can be local, the credentials can be safe, and you can still leak customer data simply by asking the right question. The safety of MCP database access is three parts architecture and one part judgment — and the judgment part is yours.

The Questions to Ask Before You Connect

If you're about to wire up MCP database access, run through these:

Where do the credentials live? If the answer is "in the AI client's config file" or "on a relay's server," fix that first.
What's the worst query the AI could run? If the answer is "delete everything," you need read-only mode or a scoped database before you proceed.
What data will I ask about? If any of it is customer data, check what your policies say about sending it to a model provider.
How do I revoke access? If it's not instant and local, that's a gap.

These aren't exotic questions — they're the same ones you'd ask about any integration that can touch your database. The difference with MCP is that the surface is bigger: an AI assistant is more capable, more creative, and harder to predict than a cron job. That's exactly why it's worth being deliberate.

Where This Leaves You

MCP database access is one of the most useful things to come out of the AI tooling wave — I use it daily, and I've written about setting it up locally and comparing the architectural options. But "useful" and "safe" aren't the same thing, and the gap between them is your responsibility.

The good news: the safe version is not harder than the unsafe version. A local MCP server with credentials held by your own app, read-only for anything important, scoped to the databases it needs, and a habit of asking "would I be comfortable sending this data to a model?" before every conversation — that setup gets you most of the value with almost none of the risk. The dangerous version isn't the one with a misconfigured firewall; it's the one where someone connected a capable AI to a production database and never asked these questions at all.