Does read-only stop the AI from reading the users table?

No. Read-only blocks INSERT, UPDATE, DELETE, and similar. It does not block SELECT. If users is reachable, the model can read emails, phones, and whatever else is in those columns.

What's a table allowlist?

A list of tables the connector is allowed to list, describe, and query. Everything else is denied at the gateway. On Synra you set this per connection after you save the database.

Should I still use staging if I restrict tables?

Yes. Table limits shrink what can be read. Staging (or a branch/replica) shrinks where those reads land. Use both when the data matters.

Which tables should I allow first?

Start with the ones that answer your real questions — orders, events, signups, subscriptions — and leave identity and secrets tables off (users, accounts with tokens, raw message bodies, payment PANs).

Is this the same as column-level security?

No. An allowlist is table-level. If a table you allow still has sensitive columns, the model can still SELECT them. For that you need a view, a sanitized staging copy, or database grants that hide those columns.

Restrict AI Database Tables | Table Allowlists

Read-only stops DELETE. It does not stop SELECT email, phone FROM users.

If that table is on the connection, Cursor or Claude can read it — same as a human with a SQL client, just faster. I’ve noticed some people tick read-only, leave every table open (analytics and identity), then get surprised when a vague question pulls customer PII into the chat.

Don’t give the AI every table. Staging and endpoint hygiene still matter; this sits next to them:

Environment: Staging first
Writes: Why read-only matters
URL leaks: Treat your MCP endpoint like a password

The failure mode read-only doesn’t cover

You ask: “Who signed up last week?”

A careful model joins signups to users and returns names and emails. That’s often what you wanted.

You ask: “Summarize our customers.”

Same path, wider. Or the agent opens users “to understand the schema” and samples rows into the thread. Those rows go to the model provider for that turn — same exposure as pasting a CSV, except you didn’t pick the paste.

Gateway read-only doesn’t fix that. A SELECT-only Postgres role doesn’t either, if that role can still read users.

Shrink the surface: which tables this connector can see.

What to allow (and what to leave out)

No universal list. A sensible week-one default:

Often allow (if that’s what you’re asking about):
orders, order_items, products, events, signups, subscriptions, invoices (amounts, not card numbers), reporting tables you already use in BI.

Usually keep off:
users / accounts with emails and phones, API keys or session tokens, raw support message bodies, government IDs, payment card data, admin notes you wouldn’t put in Slack.

If a question needs identity, use staging with fake emails — or a view that only exposes user_id plus non-PII fields — not full production users on day one.

How this works in practice

Point the connector at staging (or a branch / replica), not production primary.
Turn on read-only at the gateway (Synra default) and prefer a SELECT-only DB user.
Restrict tables to the set that matches your questions.
Ask three known-answer questions and confirm the model isn’t inventing joins into denied tables.
Check the usage log in week one — what the audit log is for.

On Synra: after you save a connection, open table access and uncheck what the AI shouldn’t see. No restriction means all tables — the risky default. A short list means analytics yes, users no.

Name the connection after the environment (staging-analytics, not db) so you don’t reuse a wide production endpoint by mistake.

Limits of table allowlists

Table-level only. Allow customers and the model can still SELECT * on sensitive columns in that table. Use a view or sanitized staging data if you need finer cuts.

Allowlists also don’t answer “should we connect at all?” Sometimes paste or BI is better: When not to connect AI to your database.

And nothing is automatic. Someone has to uncheck users. The product can make that easy; it can’t want it for you.

A short checklist before you invite the team

[ ] Staging / branch / replica first
[ ] Read-only gateway + SELECT-only role
[ ] Allowlist set — identity and secrets tables off
[ ] Known-answer checks pass
[ ] Endpoint treated like a password
[ ] Someone owns Usage for week one

Read-only without an allowlist blocks the DROP and still leaves users open.

Fewer tables on the connector, less PII in the chat.

Staging connection at mcpserver.design (7-day Solo trial) — save the DB, restrict tables, ask something you already know the answer to.

Related reading:

Staging First — where to point before production
Why Read-Only AI Database Access Matters — mutation vs read risk
How to Create a SELECT-Only Postgres User for AI — grants at the database
What Your AI Query Audit Log Is For — week-one Usage habits
Treat Your MCP Endpoint Like a Password — URL as credential
When Not to Connect AI to Your Database — when paste or BI wins
Can AI Actually See Your Data? — live vs paste overview