How to connect Claude, OpenAI or Cursor to your database safely over MCP

Give an AI assistant access to your database over MCP without giving it production write access: read-only roles, limits, masking and a review gate for writes.

AI & MCPUpdated October 25, 2026

What MCP gives an assistant

The Model Context Protocol (MCP) lets an AI assistant, such as Claude, an OpenAI-based agent, or Cursor, call tools you provide. A database MCP server turns your connection into tools like “list tables”, “describe table” and “run query”. The assistant decides when to call them and what SQL to send.

That is useful: it can look up the real schema, check data and test its own answers. It also means the assistant runs SQL on your database with whatever permissions you give it.

The risks

  • Writes: a confident but wrong UPDATE or DELETE, run without anyone reading it.
  • Load: an unbounded query against a large production table.
  • Data exposure: rows with personal or health data sent to the model provider as part of the conversation.
  • Instructions hidden in data: text stored in a row or a ticket that tells the assistant to do something else. The assistant may treat it as an instruction.
  • Credentials: connection strings with passwords left in configuration files or chat history.

None of these needs a malicious model. They follow from giving an automated tool more access than its job needs.

1. A read-only database login

Create a login used only by the assistant, with read access to what it needs and nothing else. The permission is the safety boundary; settings in the MCP server are a second layer.

Read-only rolePostgreSQL
CREATE ROLE mcp_reader LOGIN PASSWORD 'use-a-secret-store';
GRANT CONNECT ON DATABASE app TO mcp_reader;
GRANT USAGE ON SCHEMA public TO mcp_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_reader;
ALTER ROLE mcp_reader SET default_transaction_read_only = on;
Read-only userSQL Server
CREATE LOGIN mcp_reader WITH PASSWORD = 'use-a-secret-store';
USE app;
CREATE USER mcp_reader FOR LOGIN mcp_reader;
ALTER ROLE db_datareader ADD MEMBER mcp_reader;
Read-only userMySQL
CREATE USER 'mcp_reader'@'%' IDENTIFIED BY 'use-a-secret-store';
GRANT SELECT ON app.* TO 'mcp_reader'@'%';

2. Point it at the right place

  • A replica or a staging copy is the safest target for exploration.
  • If it must read production, connect to a read replica where one exists.
  • Never give the assistant the application's own login or an administrator account.

3. Limits on time and rows

Cap statement time for the rolePostgreSQL
ALTER ROLE mcp_reader SET statement_timeout = '15s';

Also cap the number of rows returned to the assistant in the MCP server's configuration if it offers one. A model rarely needs more than a few hundred rows to answer a question, and every row it receives is sent to the provider.

4. Keep sensitive data out

Give the assistant schema and safe summaries by default, and row values only when needed. Where it must read rows, grant it masked views instead of the base tables. Our guide on masking PII before using AI covers this step by step.

If you can, choose a model provider per workspace, or run a local model for sensitive environments.

5. Writes need a person

When you do want the assistant's help with a change, let it propose the SQL, and have a person run it with their own permissions after reading it:

  1. The assistant drafts the statement and explains why.
  2. A person checks the exact statement, the target database and the expected row count.
  3. The person runs it, ideally inside a transaction they can roll back, and checks the result.

Treat any text the assistant read from rows, tickets or documents as data, not instructions. If a proposal does something you didn't ask for, stop.

6. Credentials and logs

  • Keep the password in your operating system's keychain or a secret manager, not in a configuration file committed to a repository.
  • Keep a log of the queries the assistant ran, so you can answer “what did it look at?” later.
  • Rotate the password if it ever appears in a chat transcript.

Checklist

  • Separate login, SELECT only.
  • Replica or staging where possible.
  • Statement timeout and row limits.
  • Masked views for sensitive tables; schema-only by default.
  • Writes proposed by the assistant, run by a person.
  • Credentials in a secret store; queries logged.

The same rules in Quorum

Quorum exposes your connections as MCP tools for Claude, OpenAI, Cursor or your own agent, with a review gate: an assistant's writes wait in Quorum until you review them. The MCP server page lists every tool and the setup steps.

External request — MCPawaiting decision
◆ IDE assistantwants to write toOrdersDBprod
UPDATE dbo.Cases SET sample_ready = 0
WHERE OrderRef IN ('ORD-48213', 'ORD-48214');
RejectReview and run…no response = no write
An MCP write request waiting for review in Quorum. Illustrative, with synthetic data.
  • MCP review gate: pending requests show the client, reason, statement and target. No response means no write.
  • Masking on every path: MCP tool replies apply the same masking rules as the grid and exports.
  • Bring your own model: Anthropic, OpenAI, Azure OpenAI or fully offline Ollama. Schema by default; rows only when permitted.
  • Bounded and stoppable: budgets for tools, time, rows and cost. Hostile content in rows or tickets is treated as data, not instruction.

Do this in Quorum

Quorum keeps the query, the evidence and the change in one window, across SQL Server, PostgreSQL, MySQL, MongoDB and more. A free 14-day trial is coming soon; request access to hear first.