How to connect a database to Claude safely

AI coding assistants are genuinely useful against a real database: they can draft a query, explain a slow plan, or pull the numbers behind a bug. The tempting way to enable that is also the dangerous one — paste a connection string into the assistant’s config and let it connect directly.

The moment you do, three things become true. The assistant (and every log, transcript, and telemetry hop behind it) can read your credentials. It can run any SQL the connecting role is allowed to run. And you have no record of what it actually did. For a throwaway dev database that might be fine. For anything with customer data — or anything you’ll eventually have to prove was handled correctly — it isn’t.

This post walks through a safer pattern for connecting a database to Claude, and how AccessVault implements it.

The core problem: the AI holds the keys

A direct connection collapses two things that should stay separate: the authority to reach the database and the decision about what to do with it. When the assistant holds the connection string, it holds both. There is no boundary where you can say “these operations are allowed, everything gets recorded, and the credentials never leave this machine.”

So that boundary is exactly what you want to build.

The pattern: a credential-isolating broker with a full audit trail

Instead of giving the AI the database, give it a narrow, audited door to the database. Three properties make the door safe:

1. The AI never receives the credentials. The connection string, password, and any SSH keys stay with a local component you control. The assistant only ever gets a token to talk to that component — never to the database itself.
2. The AI can’t open a database socket at all. The piece the AI talks to has no database driver in it. Its only capability is to forward requests to your local app, which is the one thing that actually connects.
3. Every operation is recorded before it runs. Access and audit are welded together: if the write to the audit log fails, the operation fails. There is no “ran but wasn’t logged” path.

How AccessVault implements it

AccessVault is a desktop app (macOS, Windows, Linux) that manages your database connections. To let Claude use one, it ships a bundled MCP sidecar — a small binary that speaks the Model Context Protocol to Claude on one side and plain local HTTP to the AccessVault app on the other.

The design decision that makes this safe: the sidecar has zero database dependencies. It contains no Postgres driver, no connection pool, no credentials. It literally cannot connect to your database. All it can do is make HTTP calls to the AccessVault app running on your machine, authenticated with a bearer token scoped to that local app. The app is the only process that holds credentials and the only one that opens a database connection.

Every AI-initiated request takes the same round trip:

Claude  →  MCP sidecar  →  local HTTP (loopback + bearer token)
        →  AccessVault app  →  PostgreSQL  →  back

Because that path always runs through the app, the app can enforce two guarantees on every single call.

1. Audit before execute

Before AccessVault runs a query on the AI’s behalf, it writes an audit entry. Each entry records the request id, which connection it targeted, which tool was called, the parameters, and the outcome. Crucially, the audit write happens first: if it can’t be recorded, the operation doesn’t run and the request fails. You never end up with an AI action that touched the database but left no trace.

The result is a queryable, append-only record of everything an assistant did — which is exactly the artifact an audit asks for.

2. You choose what the AI can call

The AI doesn’t run free-form SQL. Each connection has a catalog of named tools, and the assistant can only call the tools in that catalog. A tool is a fixed, reviewed SQL statement with typed parameters — so a tool that reads order totals can only read order totals. Columns you didn’t expose in a tool’s query never come back, because there’s no code path for the AI to ask for them.

Parameters are typed the whole way through: they travel from JSON to a typed parameter to the native driver type without ever being flattened into a string. A SQL NULL stays NULL; an integer stays an integer. That closes off a whole category of injection-flavoured and type-coercion bugs that string-built queries invite.

If the database sits behind an SSH bastion, the app manages the tunnel — the SSH session and private keys stay on your machine, and the assistant never sees them either.

Setting it up with Claude Code

Once you have a database connected in AccessVault, wiring up Claude takes about a minute:

1. Select the connected database and open its detail header.
2. Click Copy MCP Command. AccessVault builds a ready-to-run claude mcp add … command containing the sidecar’s path, the catalog for that specific connection, and an auth token for the local app.
3. Paste it into your terminal and run it to register the sidecar with Claude Code.
4. In any Claude session, the tools from that connection’s catalog are now available.

One thing to remember: AccessVault has to be running for Claude to reach the database. The sidecar talks to the app, and the app is what enforces auditing and holds the credentials — so if the app is closed, the door is simply shut.

Why this is the right default

Direct connections optimise for the first five minutes and cost you every day after. The broker pattern costs you one extra click at setup and buys three things that matter for real systems: credentials that never leave your control, an AI that can only take actions you’ve explicitly allowed, and a complete record of everything it did.

If you want that pattern without building the plumbing yourself, that’s what AccessVault is for. It’s launching soon for macOS, Windows, and Linux — grab early access and we’ll tell you the moment it’s ready.