Azure SQL AI assistant in SSMS, no API key

Most conversations about “AI for SQL Server” quietly assume a box SQL Server sitting on a machine you control. Plenty of real work no longer lives there. It lives in Azure SQL Database or Azure SQL Managed Instance, reached with a managed identity, signed into with your work account, governed by rules an on-prem instance never had. An AI assistant that only understands the on-prem case is an assistant you cannot use where half your databases actually are.

SQL Sage for SSMS is a pair-DBA that lives inside SQL Server Management Studio 22, and it is built to work the same way on Azure SQL as it does on the box — on your own AI account, without a second bill or a new secret to manage. This post is about what that means in practice, and we will be honest about where the free line sits. If you are still choosing a tool, the general guide to AI assistants for SSMS and the tradeoffs to check is a separate read — here we stay on Azure SQL.

Disclosure: this blog is published by LumaSoft (LUMA sp. z o.o.), and I work on the tool described here.

Edition-aware: it knows which SQL Server it is talking to

SQL Server is not one target. A box instance, an Azure SQL Database, and an Azure SQL Managed Instance differ in what they expose — most visibly in which server-level DMVs exist. A tool that assumes the on-prem surface everywhere either breaks on Azure or, worse, quietly reports nonsense.

SQL Sage is edition-aware. It recognizes whether it is connected to a box SQL Server, an Azure SQL Database, or an Azure SQL Managed Instance, and it degrades gracefully where a feature genuinely does not exist — for example, functionality that depends on a server-level DMV that Azure SQL Database does not offer. You do not get a confident answer built on data that was never there. You get the capability the edition actually supports, and a straight account of the rest.

It connects the way your query window already does

On Azure, how you authenticate is not an afterthought — it is the whole gate. SQL Sage connects the way your query window connects: SQL login, Microsoft Entra Password, or Service Principal. Whatever gets you into the database in SSMS is what SQL Sage uses, so a Managed Instance you reach with Entra is a Managed Instance SQL Sage can read.

It handles those credentials carefully. SQL Sage signs its own sessions with the credentials of your query window, held only in memory — never written into a connection string or a log. When a schema read fails, it tells you why instead of leaving you guessing, and when the server rejects a query, it shows you the real error from the server rather than inventing a theory about your login. On a cloud database, where a permission boundary or a firewall rule is often the actual cause, that honesty is the difference between a fix in one minute and an hour of folklore.

On your own AI account — no API key, no second token bill

The part that surprises people: there is no LUMA key in the middle, and no API key to create at all. SQL Sage runs the assistant on your own AI account — Claude through the Claude Code CLI, or ChatGPT / OpenAI Codex through the Codex CLI. When you sign in with Claude Code or Codex, no API key is required (an Anthropic key is optional if you prefer one), there is no per-token charge from LUMA, and the AI usage comes out of your own plan.

This is the same keyless design we wrote about in detail here: one fewer secret to store, rotate, and leak, and no metered API invoice stacked on top of a subscription you already pay for. On Azure, where cost governance is already a discipline, keeping the AI spend inside an account you control rather than routing it through a vendor is one less thing to reconcile.

Safe by default — SELECT runs, writes wait

An assistant that can touch a production Azure database has to be safe before it is clever. SQL Sage is safe by default, enforced by a ScriptDom gate that parses SQL before anything happens to it:

A SELECT runs on its own. Reading is the fast path.
DML and DDL stop for explicit confirmation, with the exact SQL in front of you before it executes. You approve the statement you can read, not a summary of it.
Queries that reach beyond the current database — linked servers, OPENQUERY, OPENROWSET/BULK, OPENDATASOURCE — always stop for confirmation, because they cross a boundary you should cross deliberately.
Run executes only in a new query window, and only after checking that the SQL, server, and database match — so a statement never fires against the wrong connection by accident.
It reads your schema and DMVs, keeps an audit log, and never sends query results to the model without explicit, per-session consent. Results you have shared with one provider are not sent to another if you switch.

The default mode is Agent: the AI may run read-only queries and SQL Sage’s own tools, and any write always asks first. If you want it stricter still, Ask mode answers only from the query you attached and the chat — it runs nothing at all. (The read-only-by-default line is the one we would use to judge any AI-for-SQL tool, including ours.)

Mask names: your identifiers never travel in the clear

Grounding an AI in your real schema is what makes it accurate — and what you send to get there deserves scrutiny, a point we unpack in what the AI actually sees. SQL Sage adds a second layer on top of the schema-not-rows boundary: Mask names. It swaps server, database, login, host, and file names for stable placeholders — <database2>, <login1>, and so on — in everything that reaches the AI: tool results, the conversation, and your own system prompt. The placeholders stay consistent for the whole chat, so the model can still reason about relationships without ever learning that <database2> is your production billing database. Since 0.35.1, inline completions are masked too: the suggestion gets the real names back on your own machine, and nothing is sent at all when SQL Sage cannot read the names from the server.

One honest caveat: table and column names are not masked. Those are usually the structure the model needs to help, and they are a far smaller surface than server and login names — but it is worth knowing where the line is drawn. Your chat history, meanwhile, is encrypted on disk (DPAPI) with a retention you set, or you can turn saving off entirely.

The honest part: what is free, and what needs a license

We will not pretend the AI is free forever. SQL Sage is a 30-day trial — all features, no card — and the clock starts from your first AI answer, or 14 days after you first open the panel, whichever comes first.

After the trial it keeps running as SQL Sage Free: the editor tools stay, with zero AI. The AI features and the Proven & Accountable layer require a license — buy once from $39, or subscribe from $29/year. (The full pricing lives on the site; check it there rather than trusting a number in a blog post.)

The takeaway

An AI assistant for SQL Server is only useful where your databases actually are, and increasingly that is Azure. SQL Sage for SSMS is edition-aware across box SQL Server, Azure SQL Database, and Azure SQL Managed Instance; it connects the way your query window does — SQL login, Entra, or Service Principal; it runs on your own Claude or ChatGPT account with no API key and no token bill from us; it is safe by default, so reads are fast and writes wait for you; and Mask names keeps your identifiers out of the model’s sight. See it on the SQL Sage for SSMS product page.

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