Connect Claude to your company database — without handing it the keys
MCP made it trivial to wire Claude to a database. That is exactly the problem. Here is the difference between a connector and a governed connection — and what your security team will ask before anyone pastes a link.
The moment every company is in
Your leadership already asks their questions in chat. Since the Model Context Protocol (MCP) arrived, connecting Claude to a live database takes an afternoon: run a small server, hand it credentials, and Claude can list tables and run SQL. Thousands of teams have done it. Most of them did it the way you'd never let a new employee touch production.
What a raw MCP connector actually is
Strip the excitement away and a typical database MCP server is: your database credentials in a config file on one person's laptop, granting whatever scope those credentials carry — often the entire database — to whatever the model decides to run. Concretely:
- Scope is the credential's scope. If the connection string can read 400 tables, so can every question.
- There is no audit. Nobody can answer "what did the AI query last week, and how many rows came back?"
- There is no revocation story. The credential lives in local config; rotating it means finding every laptop.
- There are no limits. One badly-phrased question can trigger a full-table scan against production at 2 p.m.
- It serves one person. The setup is per-developer; your CFO will never run a local MCP server.
None of this is a flaw in MCP. MCP is a wire protocol, and a good one. These are the properties of connecting directly — the same reason companies stopped handing analysts raw production credentials fifteen years ago.
The governed pattern: a gateway the AI talks to instead
The fix is old-fashioned and boring, which is why it works: put a governed gateway between the AI and the databases. Claude speaks MCP to the gateway; the gateway speaks read-only SQL to your sources. Every property you lost comes back:
1. Read-only by construction. The gateway connects with read-only credentials you issue, and a query guard blocks writes and exfiltration patterns regardless of what SQL the model produces. Per-query timeouts and row caps mean a bad question is a slow answer, never an incident.
2. Scoped doors instead of one big key. Each person gets a revocable access link with a scope. A business-scoped link reaches only the curated datasets and tools you approved — raw tables are not queryable through it, by SQL or by the model. Engineers get a fuller door. Revoke either in one click, centrally.
3. Tools instead of freestyle SQL, where it matters. For recurring judgment questions — "is machine X's temperature normal?" — define a parameterized tool once: the SQL is yours, the model only supplies values, and values are bound, never interpolated. A malicious or confused input cannot become SQL.
4. Every question leaves a trace. Who asked, when, the exact SQL executed, and how many rows returned. Unusually heavy extraction gets flagged. This is the line item your security review will actually ask about.
5. Curation, so answers are right. The model only sees names and schemas — a guide that says "revenue means total_net_eur, one row per order" and a view named revenue_by_region_monthly do more for answer quality than any prompt engineering. (We wrote a separate guide on this.)
6. One link for the whole company. The gateway serves everyone: leadership pastes one link into Claude, finance points Excel at a CSV endpoint, engineers use SQL and REST. No per-laptop setup.
Being honest about the AI leg
One thing no gateway changes, and anyone selling you otherwise is lying: when a user asks a question in Claude, the rows returned for that answer transit Anthropic's service — under your organization's own Claude agreement, the same terms you accepted to use Claude at all. The gateway's job is to make sure only the right rows can ever be in that position: scoped, capped, audited. For your strictest data, curated-only scopes mean the model sees approved aggregates while underlying rows are never reachable. We keep a plain-language security architecture page for exactly this conversation.
What this looks like in practice
This pattern is what IOT Data Flow is: a single hardened binary on a dedicated box — never multi-tenant — that pulls from your PostgreSQL, MySQL, DuckDB, Parquet files and PDF manuals with read-only credentials, curates them into guides, KPI datasets and bound-parameter tools, and serves scoped MCP links plus Excel and REST. It runs a real machine fleet today: 3,900+ machines, hourly telemetry refresh, business users asking their questions in Claude since day one.
Bring a read-only credential; leave with your live data answering questions in Claude. We show it on your database, not a demo dataset.
Book a demo