Claude or ChatGPT in SSMS without an API key

Disclosure: I work on SQL Sage, one of the tools mentioned at the end. This post is a how-to first — the approach works whether or not you ever install it.

If you live in SQL Server Management Studio, you have probably wanted an AI assistant in the editor — not in a browser tab you keep alt-tabbing to, pasting queries back and forth. The friction is not just the copy-paste. It is three real concerns that most “AI for SQL” setups do not answer well:

Who pays, and how? Raw model APIs bill per token against a key you have to create, store, and rotate.
What does the model actually see? If you paste a result set into a chat window, you have just sent production data to a third party.
Can it change my database? An assistant that can silently run UPDATE or DROP is a liability, not a copilot.

Here is how to get an in-editor AI copilot for SSMS while keeping all three under control.

1. Keyless beats API keys for most people

Most “connect AI to your tool” guides start with “generate an API key and paste it here.” That works, but it has costs:

You are now responsible for a secret. If it leaks from a config file or a screen-share, someone can spend your money.
You pay per token on top of whatever you already pay for ChatGPT or Claude.
Key rotation and billing become one more thing to manage.

Keyless flips this: you sign in with an account you already have — your Claude login (via Claude Code) or your ChatGPT/Codex login (via Codex CLI) — and the AI runs on that subscription. No new secret to store, no separate metered API bill. If you prefer a raw key (for example, your own Anthropic key), you can still use one — but it is an option, not a requirement.

Rule of thumb: if you do not have a specific reason to manage an API key, do not. One less secret is one less incident.

2. Read-only by default is the safety line that matters

An AI copilot is most useful when it can actually look at your schema and run the query it just wrote. But “can run queries” should not mean “can change your database.”

The pattern worth adopting — whatever tool you use:

SELECT runs immediately. Reading is safe and reversible.
UPDATE / DELETE / INSERT / DDL requires explicit confirmation. The assistant can propose a write, but a human approves it before it executes.

This keeps the loop fast for the 90% case (exploring, explaining, optimizing) while making destructive operations a deliberate act, not an accident. If your assistant runs writes without a confirmation step, treat that as a red flag.

3. Know exactly what leaves your machine

This is the part people skip, and it is the most important one.

To write a good query, an AI model needs your schema (table and column names, types, relationships) and the SQL text you are working on. It does not need the rows.

So the question to ask of any setup is: does my data leave the building?

A privacy-respecting default looks like this:

Schema + SQL text go to the model. That is enough context to generate, explain, and optimize queries.
Data rows do not. If you ever want the model to see sample rows (say, to debug a weird value), that should be an explicit, per-session opt-in — never the default.

If you are in a regulated environment, write this down and verify it before you connect anything. “The model can see my schema” is a very different risk profile from “the model can see my customers’ PII.”

4. The friction that kills adoption: migrating your workflow

Plenty of AI SQL tools are really new IDEs that happen to talk to databases. They are fine, but adopting one means leaving the tool your team already knows. For SSMS shops that is a hard sell — the muscle memory, the connections, the saved solutions all live in SSMS.

The lower-friction path is an AI layer inside the tool you already use, so there is zero IDE migration. You keep SSMS; the copilot shows up in the editor you are already in.

Putting it together

Combine the four points and you get a checklist for “AI in SSMS, done sanely”:

Signs in with an account you already have (keyless) — no new secret to manage
Read-only by default — writes need confirmation
Sends schema + SQL, never data rows (rows opt-in only)
Lives inside SSMS — no workflow migration

Where SQL Sage fits (the honest part)

I work on SQL Sage for SSMS, which is an add-in for SQL Server Management Studio 22 on Windows 10/11, built exactly around that checklist:

Keyless — sign in with your own Claude (Claude Code) or ChatGPT/Codex (Codex CLI); no separate API key with a Claude Code or Codex sign-in, or bring your own Anthropic key if you want to.
Read-only by default — SELECT runs; DML/DDL waits for your confirmation.
Schema + SQL only — data rows never leave your machine unless you opt in per session.
In-editor — it writes, explains, and optimizes SQL where you already work, so there is nothing to migrate.

For a closer look at how this works in the editor, see Claude in SSMS with SQL Sage. You can download SQL Sage and start a 30-day trial with no card, then a free tier; paid Personal plans start at $29/year or $39 lifetime, sold through Paddle. If you work in DBeaver instead of SSMS, there is a sibling plugin (Windows-only) — Claude and ChatGPT in DBeaver, no API key — covering PostgreSQL, MySQL/MariaDB, Oracle, SQL Server, and SQLite.

But the checklist above is the real takeaway — use it to evaluate any AI-for-SQL tool, including mine. If a tool cannot tell you what it sends to the model, that is your answer.

SQL Sage is made by LumaSoft (LUMA sp. z o.o.). Not affiliated with Microsoft, Anthropic, or OpenAI.