Back to Blog

Why Read-Only AI Database Access Matters

MCP doesn't make database access safe. Read-only at the gateway and SELECT-only credentials do. Why AI write access is uniquely risky — and how to verify your connector can't mutate data.

Most teams who hesitate to connect ChatGPT, Claude, or Cursor to a database are thinking about one failure mode: what if it changes something?

Right fear. Incomplete picture. Read-only isn't a chat UI toggle and MCP doesn't promise it. It's how you configure the connector and the database user. Skip that, and AI-driven SQL is worse than a junior with a SQL client — the model doesn't wait for you to click "run."

This post covers why write access is uniquely risky with AI connectors, what "read-only" has to mean in practice, and what it still won't save you from. For where to point the connector first: Staging First. For the broader "is live access real" overview: Can AI Actually See Your Data?.

What goes wrong when the AI can write

A human with write access still has friction: open a client, type SQL, hit execute, watch the row count. An agent can generate SQL, call a tool, and keep going in the same turn — including retries when the first attempt "didn't work."

Common failure modes:

  • Confident cleanup. "I'll remove the test rows" becomes a DELETE with a WHERE that's slightly wrong.
  • Migration improvisation. The model "helps" by running ALTER TABLE or DROP INDEX because the chat asked how to fix a schema mismatch.
  • Retry loops. First UPDATE hits a constraint; the agent rewrites and tries again — three times — while you're looking at a different pane.
  • Wrong environment, full permissions. Staging string was supposed to be in the connector; production was. With SELECT-only that's embarrassing. With write access it's an incident.

None of that needs malice. The model treats SQL like any other tool call.

MCP does not mean read-only

Said plainly, because product pages muddy it:

MCP = how the client discovers tools and calls them.
Read-only = what those tools are allowed to do to your database.

You can install an MCP server that runs DELETE FROM users without complaint. You can also put a managed gateway in front that rejects anything that isn't a SELECT (and related read forms) before it reaches Postgres, MySQL, or SQL Server.

On Synra, destructive keywords are blocked at the gateway by default. That's a Synra choice — not something you get from "using MCP" or pasting a URL into Cursor. Self-host a connector with the app's migration user and the protocol will not save you.

Two layers that actually enforce it

1. Database grants

Create a dedicated login with SELECT only (or db_datareader on SQL Server) on the schemas the AI should see. Not the app user. Not the owner role.

If the connector is misconfigured tomorrow, the database still refuses writes. Boring. Correct.

2. Gateway / connector policy

Parse or classify statements and reject INSERT, UPDATE, DELETE, DROP, ALTER, TRUNCATE, CREATE, GRANT, and friends before they hit the wire.

That catches the "we reused a stronger password just for testing" case, and writes the grants would have blocked anyway — you want the failure loud in the tool error, not quiet in the table.

Use both when the data matters. Staging first is the third layer: a perfect read-only stack still shouldn't start on production main.

What read-only does not fix

Read-only is not a privacy product. It stops mutation. It does not decide what you're allowed to see.

  • Wide reads — SELECT * on a huge table, or columns you never meant in a chat (tokens, message bodies, government IDs).
  • Wrong audience — anyone with the MCP endpoint URL can run the same reads you can.
  • Business-logic mistakes — wrong join, wrong definition of "active," counting the wrong status. Schema truth helps (why models invent your schema); it doesn't define your metrics.
  • Load — heavy analytical SQL against a hot primary still hurts even when it's SELECT-only. Prefer staging or a replica.

If your fear is "Claude might drop the table," read-only addresses that. If your fear is "Claude might see the table," you need environment choice, table allowlists, and judgment about what belongs in a chat product at all.

A 60-second verification test

Do this once per new connection, before you share the endpoint with the team.

  1. Ask: "How many rows are in <a table you know>?" — should succeed with a real number.
  2. Ask: "Run UPDATE <that table> SET <some column> = <some column> WHERE false" or a similarly harmless-looking write — should fail at the gateway or with a permission error.
  3. Open the audit log (or your connector logs). Confirm the SELECT landed and the write was rejected.

If step 2 succeeds, disconnect the endpoint and fix grants/settings before anyone else uses it. Don't argue about policy while write access is live.

When people ask for write access anyway

Sometimes the request is honest: "I want the agent to apply the migration."

Don't put that on the same chat connector you use for "how many signups yesterday." Migrations go through your normal path — PR, CI, expand/contract. If you ever enable writes on a connector:

  • Separate connection, separate credentials, short-lived
  • Staging only
  • Someone watching the session
  • Flip back to read-only when done

Day-to-day AI database access should stay dull: list tables, describe columns, run SELECTs, argue about definitions. Dull is the point.

Cursor, Claude, ChatGPT — same rule

The client matters less than the connector config. Composer, Claude connectors, and ChatGPT custom MCP tools all call whatever the server exposes. Setup guides:

In each case: confirm read-only (and a SELECT-only DB user if you can) before you treat the chat as a source of truth.

Read-only won't make AI database access risk-free. It stops the failure mode where a wrong assumption becomes a data incident. Pair it with staging-first and the write-rejection test above — that covers what most teams actually lose sleep over.

Start a free trial at mcpserver.design (gateway read-only by default), run the verification test on staging, then invite the rest of the team.

Related reading:

← Back to Blog