Does Synra send my whole database to OpenAI or Anthropic?

No. Synra runs the SQL you (via the AI client) request and returns that result set to the client. The model provider sees the rows in that response for the conversation — not a bulk export of every table.

Is this different from pasting a CSV into ChatGPT?

Same class of exposure for the rows that appear in the chat. The difference is convenience and freshness: the model can pull new slices without you exporting. Staging and table allowlists matter more because it's easy to over-query.

Does 'we don't train on your data' mean results never leave my VPC?

No. That's usually about training use, not about whether results are processed to generate the next reply. Read the provider's current terms. Assume chat context can include query output.

What does Synra store?

Encrypted credentials, connection config, and usage metadata (tool, connection, status, duration, time). Treat the Usage log as operational history, not a warehouse of every cell returned.

How do I reduce what can show up in chat?

Staging or sanitized data, SELECT-only user, table allowlists, prefer aggregates in prompts, and don't connect tables full of secrets. Verify with known-answer checks before you invite the team.

Where AI Database Query Results Go | Privacy

“Is it safe to connect AI to a database?” usually means writes. Use read-only for that.

Second question: when the model answers from live rows, who else saw those rows?

The result set goes back to the AI client, then to the model provider for the next reply. Same class of exposure as pasting a spreadsheet into ChatGPT — just easier to repeat.

Data-flow picture, not legal advice. Also: staging first, table allowlists, when not to connect.

The path of one question

You ask Claude / Cursor / ChatGPT something about the business.
The client calls your MCP tools (list_tables, execute_sql, …).
The gateway (Synra or otherwise) runs read-only SQL against your database.
Rows (or an error) return to the client.
Those rows sit in the conversation context so the model can summarize them.
You see the answer in chat.

Your database still holds the source of truth. A copy of that slice is now in the chat stack. Follow-ups may pull more slices.

What Synra sees vs what the model sees

| Layer | Typically sees | |--------|----------------| | Your database | Whatever the DB user can SELECT | | Synra gateway | Credentials (encrypted), the SQL/tool call, success/error, timing — see audit logs | | AI client + model provider | Tool results needed to answer — including row samples or aggregates you queried |

Synra’s job is to sit between client and DB with read-only defaults and logging. It is not a private VPC for OpenAI or Anthropic. If that bar is required, you need a different architecture (private models, approved vendors, legal review) — not a smaller marketing claim.

“We don’t train on your data”

Providers publish policies about training and retention. Those change; read the current ones for your plan (consumer vs business/enterprise often differ).

Even when training is off, processing for inference still means the model uses the tool output to generate the reply. Don’t confuse “not used to train” with “never left my laptop.”

Why this matters more with a live connector

Paste workflows are clumsy — that clumsiness limits how much PII you shove into chat.

A live connector makes “just pull users” one sentence away. Recurring Claude Code reports amplify that: every Monday can re-send fresh slices into a new context.

So the controls that matter for read exposure:

Environment — staging / sanitized branch before prod PII
Tables — analytics yes, identity dumps no
Prompts — ask for counts and distributions; say “don’t print emails”
Endpoint — treat the URL like a password; anyone with it can pull the same reads into their chat

A practical rule of thumb

Ask: Would I paste this result into a free ChatGPT window?

If no, don’t put that table on the connector — or don’t connect that database yet. If yes, you’re accepting the same tradeoff with less friction.

Enterprise buyers: involve security early. Consumer Plus + production customer table is a different conversation than staging + aggregates.

Checklist before you invite the team

[ ] Staging (or sanitized) for the first weeks
[ ] SELECT-only DB user + gateway read-only
[ ] Table allowlist without raw secrets / full inbox tables
[ ] Prompts prefer aggregates
[ ] Someone owns Usage in week one
[ ] You’ve read your model provider’s data terms for your plan

Fresh results are the point of live access. They’re still chat-context results. Plan for that.

Read-only staging connection: mcpserver.design (7-day Solo trial).

Related reading:

Can AI Actually See Your Data? — cost, safety, what’s real
Don't Give Your AI Access to Every Table — shrink the read surface
Staging First — where results should come from first
When Not to Connect AI to Your Database — when paste or BI is enough
What Your AI Query Audit Log Is For — what the gateway records
Treat Your MCP Endpoint Like a Password — who can trigger those reads