Connect a SQL database to Claude or ChatGPT: a safe-setup checklist

Last verified: 17 October 2026

Short answer

Claude and ChatGPT cannot reach into a database by themselves. They call a connector that sits in front of it, and that connector must be reachable from Anthropic's cloud over the public internet or, for ChatGPT, over a public HTTPS address or OpenAI's Secure MCP Tunnel. To connect safely, give the connector a dedicated read-only database user, expose a small set of views instead of raw tables, point it at a replica or copy rather than the live system, and keep a log of every query.

How the pieces fit

Three parts are involved. The assistant, Claude or ChatGPT, runs in its vendor's cloud. The connector is a small service that receives the assistant's request and turns it into a database query. The database holds your data. Most connectors today use MCP, the Model Context Protocol, which its maintainers describe as an open-source standard for connecting AI applications to external systems.

The assistant never connects to the database. It calls the connector, and the connector runs queries with a database user you create. That gives you three places to set limits: what the database user can do, what the connector exposes, and who can reach the connector. Most of this checklist is about the first, because it is the one that still protects you when something else goes wrong.

The checklist

Use a replica or a reporting copy, not the live database. A mistake or a heavy query then cannot slow down your shop or your POS. A PostgreSQL hot standby accepts read-only connections, and its documentation notes that the standby can cancel queries that conflict with updates from the main server, which is one more reason to keep AI queries short. A nightly copy into a separate reporting database is simpler and often enough. Ask your hosting provider which read replicas they offer.
Create a dedicated read-only user. One user for each connector, never your administrator login. Give it a long random password stored in the connector's secret settings, not typed into a chat. Grant it permission to read only the views from step 3, and no permission to create or change anything.
Expose views, not tables. A view is a saved query that shows chosen columns and rows. Create views such as sales by branch and day, stock by product, or open invoices, and give the user access to those views only. In PostgreSQL, a view reads its underlying tables with its owner's permissions by default, so the AI user needs no access to the raw tables. Other databases have similar options; ask your administrator.
Leave out or mask personal data. Do not expose names, phone numbers, national ID numbers or addresses unless a question truly needs them. Use a customer code, or summarise: sales per customer segment instead of per person. If you do share personal data, check Saudi personal-data rules with your legal adviser first. The assistant vendors process data in their own cloud.
Limit rows, time and connections. Cap the number of rows the connector returns, for example a few hundred to a few thousand, and summarise inside the view. Set a timeout on the user: in PostgreSQL, statement_timeout stops any statement that runs too long. Limit simultaneous connections for the user too. On the tunnel route, OpenAI's tunnel page lists a 120-second request deadline, so very slow queries fail anyway.
Control network exposure. The assistants call from the vendor's cloud, so the connector must be reachable. The database should not be. See the next section.
Test on a copy or fake data first. Ask things that should fail: "show every customer's phone number", "delete orders older than a year", "list every table". The refusal should come from the database permissions, not from the assistant being polite.
Leave writes off. If you later want the assistant to change data, do it with a separate user and a step where a named person approves each change.
Log and review. Keep a log of each query: who asked, when, which view, how many rows. Turn on logging for the AI user in the database too. Review it every week at first and watch for unusual volume. A log held only by the assistant's vendor is not a log you control.

Network: why a firewalled database does not connect

Claude and ChatGPT do not call your connector from your office. They call it from the vendor's cloud, so a connector on a private network cannot be reached unless you arrange it.

Claude. Anthropic's article says connections come from Anthropic's cloud, the server must be reachable over the public internet from Anthropic's IP ranges, and a server behind a VPN or firewall will not connect unless you allow those addresses. The outbound range for MCP tool calls is 160.79.104.0/21, listed on Anthropic's IP addresses page. If you allowed the five older 34.162.x.x addresses, remove them, because Anthropic no longer uses them.

ChatGPT. Full custom servers are for Business and Enterprise/Edu workspaces, and Pro is limited to read and fetch, according to OpenAI's help article. OpenAI's setup page accepts a public HTTPS endpoint or a Secure MCP Tunnel. With a tunnel, a small program you run inside your network connects out to OpenAI, so the server needs no public address and no inbound access. Setting it up is a job for a developer or IT person, and OpenAI notes that the sign-in (OAuth) server is not tunnelled, so it must still be reachable.

Put the connector on the internet, never the database. A database that accepts connections from anywhere can be probed by anyone, and then a password is the only barrier. The safer pattern is a connector on a small server with HTTPS and sign-in, allowing only the vendor's addresses, that talks to a database on a private network. The MCP project's security guidance adds two rules for whoever builds the connector: ask for the narrowest permissions that work, and never accept sign-in tokens that were not issued for that server.

One short example

These are PostgreSQL commands, run by an administrator. MySQL, SQL Server and others have equivalents; ask your database administrator. Replace the names and the password.

CREATE ROLE ai_reader LOGIN PASSWORD 'replace-with-a-long-random-password';
CREATE SCHEMA ai_reporting;
CREATE VIEW ai_reporting.sales_by_branch AS SELECT branch_code, sale_date, SUM(net_amount) AS net_sales FROM sales GROUP BY branch_code, sale_date;
GRANT USAGE ON SCHEMA ai_reporting TO ai_reader;
GRANT SELECT ON ai_reporting.sales_by_branch TO ai_reader;
ALTER ROLE ai_reader SET statement_timeout = '15s';
ALTER ROLE ai_reader SET default_transaction_read_only = on;
ALTER ROLE ai_reader CONNECTION LIMIT 5;

The settings on a role apply to new sessions at login. The read-only setting is only a default for new transactions, not a lock, so the real protection is that the user has no permission to write. After you run the commands, sign in as ai_reader and try to read a raw table, change a row and create a table. All three should fail.

Options for the connector

Option	Good for	Watch out for
An open-source connector you run	A developer on your side who wants control. Two examples, not endorsements: Google's MCP Toolbox for Databases (open source, supports PostgreSQL, MySQL, SQL Server and others) and Microsoft's SQL MCP Server in Data API builder (open source and free, exposes only the tables and views you list, with permissions per object).	You run, patch, secure and monitor it, and it must be reachable (see Network). Ready-made tools that run any SQL are only as safe as the database user behind them, so the read-only user still matters.
A hosted connector service	No developer, and no vendor connector for your database.	Your data passes through another company. Ask what it stores, who can see it, what it logs and where it runs.
A reporting tool with AI features	Teams that already have a reporting tool and want to ask questions inside it.	Features, plans and data handling differ by tool. Check the vendor's page, and check that it respects the same limits.
A governed layer run for you	Several systems, not just one database, with one set of roles, approvals and logs, and no technical team to run it.	Ask who runs it, what it logs and where the data is processed.

Microsoft's SQL MCP Server documentation says it intentionally does not turn natural language into free-form SQL, because models are not deterministic and complex queries are the ones most likely to hide subtle errors. Whatever you choose, treat free-form SQL written by an assistant as something to check, not to trust.

Keep it safe

Read-only is not harmless. A read-only user can still read everything you grant it, and can still run an expensive query. That is why steps 3 to 5 matter as much as step 2.
Treat stored text as untrusted. Product descriptions, customer notes and reviews are read by the assistant. Anthropic warns that a malicious server can hide instructions meant to trigger unintended actions, and OpenAI warns about prompt injection from untrusted servers. Do not give one connector both access to untrusted text and the power to change data.
Review approvals. Claude asks you to approve tool use, and "Allow always" removes that check. ChatGPT may ask for confirmation before write actions.
Use named access where you can. If the connector supports sign-in per person, use it rather than one shared key for everyone.

More in Is it safe to connect company data to AI? and AI that asks before it changes anything. SDAIA publishes Saudi personal-data rules on its National Data Governance Platform.

Common problems

The assistant cannot reach the connector

The usual cause is a firewall or private network. For Claude, allow the outbound range above. For ChatGPT, use a Secure MCP Tunnel, or test your public address with MCP Inspector, as OpenAI suggests.

Queries time out

Point the view at a summary, such as one row per branch per day, instead of every transaction. Shorter queries finish inside the timeout, and they are cheaper for the database.

The answers look wrong

Ask the assistant to show the query it ran, and compare the total with a report you already trust. Often the cause is a definition, such as whether net sales includes returns. Our guide on one report for all branches and channels covers that.

It works for me but not for my colleagues

On Claude's Team and Enterprise plans, an owner adds the connector and then each member connects individually. See connecting company data to AI.

Questions people ask

Do we need a developer?

For your own database, yes, or a provider who runs it for you. A ready-made connector from a software vendor, such as Salla's, needs only a sign-in, but it covers that product alone.

Is a read-only user enough?

No. It stops changes, but you still need to limit what it can see, how heavy its queries can be, who can reach the connector, and what is logged.

Can we connect our live production database?

It can be done, but we would not. A replica or copy keeps a runaway query from slowing your shop or POS, and it limits the damage if a credential leaks.

Which assistant should we use?

See Claude, ChatGPT or Microsoft Copilot for company data for what each can connect to and on which plan.

Where Vootlabs fits

Most companies without a data team should not run database-facing software themselves. Vootlabs is designed to take that work off your hands: it connects the systems a business runs on, databases included, to AI tools like Claude, ChatGPT and Microsoft Copilot, with access by role, approval before any change, and a full audit trail.

We are onboarding a limited number of companies in a design-partner programme. If you have a database you would like to ask questions of, safely, we would like to hear about it.

Book a demo Join the design-partner programme

Sources

Plans, menu names and limits change. Check the live page before you act. All pages below were read on 17 October 2026.

By the Vootlabs team. Last verified 17 October 2026.