How to
How to connect Claude to a database safely
Pointing Claude at a database is the easy part. Doing it so it cannot read more than it should, cannot drop a table on a bad prompt, and cannot write without a human in the loop takes a connector built for that.
Connect Claude to a database safely with a custom MCP connector that authenticates as your own database account, exposes scoped read and write tools, and gates destructive actions like deletes behind a confirmation you approve. Claude works inside a conversation you start and never gets more access than the account it runs as.
Key takeaways
- A safe connection runs as a real database account with its own permissions, not a shared admin login.
- Read tools and write tools are separate, so Claude can query without being able to change anything until you allow it.
- Create and update can flow in a conversation, while deletes and bulk operations are gated behind a confirmation.
- The connector exposes named tools for named tasks, not a raw SQL prompt that can run anything.
- It works for hosted databases and for in-house ones running on-prem behind a firewall.
What does connecting Claude to a database actually mean?
Connecting Claude to a database means giving it an MCP connector that exposes specific tools, like search a table or update a row, rather than a direct line to your database. Claude calls those tools inside a conversation you start, and each tool runs a defined query against the database as a real account.
Claude does not get a database password or an open shell. It gets a set of tools you decide on, and each tool maps to a known operation:
- Read these rows.
- Write this record.
- Update that field.
Because the connector sits in the middle, you control the surface. Setting it up works like this:
- 1We build a custom connector against your database as a real account, not a shared admin login.
- 2You decide on the set of tools it exposes, and each tool maps to a known operation like read these rows, write this record, or update that field.
- 3Claude calls those tools inside a conversation you start, and each one runs its defined query against the database.
Claude can only do what the tools allow, which is very different from handing a model a connection string and hoping for the best.
How do you give Claude database access without over-granting?
Give Claude database access without over-granting by running the connector as a dedicated account with least-privilege permissions, scoped to the specific tables and columns it needs. Claude inherits exactly that account's rights, so it can never read or change data the account itself cannot reach.
We provision a database role for the connector rather than reusing an admin login. That role gets read access to the tables Claude should see and write access only where you want it, down to the column level if your database supports it.
Sensitive columns, like password hashes or fields under a compliance boundary, can be left out of the role entirely. If the account cannot select them, no prompt can talk Claude into surfacing them.
How do you stop Claude from deleting or corrupting data?
Stop Claude from deleting or corrupting data by separating read and write tools and gating destructive actions behind a human confirmation. Create and update can run in a conversation, while deletes, drops, and bulk updates pause and wait for you to approve the exact operation before it touches the database.
The connector exposes named tools for named tasks instead of a free-form SQL tool. A tool called update_order_status can set one field on one record. There is no tool that can run arbitrary SQL, so there is no path to a stray DROP or an UPDATE with no WHERE clause.
For the actions that are genuinely irreversible, the confirmation step shows you what Claude is about to do, on which records, before anything runs. You decide which operations are automatic and which always need that approval.
Deletes are gated
Destructive tools like delete and bulk update pause and show you the exact operation and the records it touches, so nothing irreversible runs without your approval.
Can Claude connect to a private or in-house database?
Yes, Claude can connect to a private or in-house database, including one that runs on-prem behind a firewall with no public endpoint. We build the connector against your database directly and deploy it where it can reach the database, so Claude talks to it through scoped tools without the database ever being exposed to the internet.
This is the common case for internal systems: a Postgres or MySQL instance, a data warehouse, or a legacy database that no directory connector will ever cover. A custom connector is built specifically for that schema.
Access still flows through the same account and tool scoping, so a private deployment is no less locked down than a hosted one. Claude reads and writes only what its role and its tools permit.