The Azure SQL (MSSQL) MCP server lets Claude, Cursor, ChatGPT, and AI agents query SQL Server in plain English. Microsoft pulled its own sample as unsafe — here's the safe path, the real risks, and how to govern agent access with column-level redaction at the MCP layer.
.webp)
DropTable and UpdateData across the database. A privileged agent can also bypass Always Encrypted, Dynamic Data Masking, and Row-Level Security — masked columns come back in cleartext to the model.An Azure SQL MCP server is a Model Context Protocol implementation that exposes an Azure SQL Database or SQL Server instance to AI agents as a set of standardized tools — listing tables, describing schemas, reading rows, and (depending on the server) inserting, updating, and creating tables.
There isn't one canonical server, and the difference is a security decision:
MssqlMcp). This is the one most early adopters found and the one Microsoft deleted as unsafe. Forks of it still circulate — that's the risk.azure-sql tools are a different thing entirely: control-plane management (create, delete, scale databases, firewall rules, Entra admins), not table data.mssql_mcp_server and others) have their own tool surfaces and defaults — vet each one.From the user's seat, the agent suddenly understands the database — it answers questions about live data in T-SQL without anyone exporting a report. From the security seat, you've just handed an AI client query access to SQL Server, and possibly write and schema access too.
That's the value. It's also exactly where a control layer belongs.
Point an agent at an Azure SQL MCP server and it works the database directly, turning plain-English requests into T-SQL against the tables the connected principal can touch. Depending on the server, it can:
ReadData is universal; the removed sample also exposed InsertData, UpdateData, CreateTable, and DropTable.Every one of those runs through SQL Server's engine and the privileges of the principal you connected — which is what makes it useful, and exactly why the regulated data those queries return needs an inspection layer in the tool-call path.
Microsoft pulling its own sample is the loudest possible signal. Five categories every healthcare, fintech, and enterprise security team should price in:
1. Default-write, and the .NET sample had no read-only at all. The removed Node sample defaulted to write unless READONLY was set to exactly "true"; the .NET version registered every write tool with no read-only mode. Connect a db_owner Entra principal — common in dev — and the agent inherits UpdateData and DropTable across the entire database. This is the "wrong road" Microsoft cited.
2. A privileged agent bypasses your SQL-layer masking. Always Encrypted, Dynamic Data Masking, and Row-Level Security all assume a constrained application principal. An agent connected with broad rights can return masked columns in cleartext — the protections you configured at the SQL layer don't reach the model context.
3. T-SQL has escape hatches. Stored procedures, dynamic SQL, and (where enabled) xp_cmdshell let a query do far more than read a table. DAB can expose stored procs as tools; a community server may expose raw T-SQL. A misread prompt can reach well beyond a SELECT.
4. Linked servers extend the blast radius. A read grant on one database doesn't bound a linked-server hop. The agent's reach can quietly cross into other databases and instances you didn't mean to expose.
5. There is no column filter in the path. Whatever the connected principal can read, a wide SELECT returns — plaintext PII, financial data, credentials in config tables — straight into the model's context window, far more than any human would copy by hand.
The DLP a company already runs doesn't sit in the T-SQL path between an agent and SQL Server. The query result goes straight from the database into the AI agent's context window. That reach is precisely why each agent's access to Azure SQL must be governed: controlled (which tables and columns it can touch, and whether it can write or run DDL and stored procs), the sensitive data it returns protected, and every query audited. That is where Strac Azure SQL MCP DLP lives.
Strac's Azure SQL MCP DLP is the governance layer that sits between AI agents and the Azure SQL MCP server. Strac governs every query: it sees exactly what each agent runs, controls what it can reach and do, protects the sensitive columns it touches, and logs every call as audit evidence. In-policy, non-sensitive queries flow through untouched.
What this looks like in practice, mapped to See / Control / Protect / Prove:
claims and policies but never payment_methods or secrets. Writes (UPDATE / DELETE / INSERT), DDL (CreateTable / DropTable), and risky stored procedures are blocked or routed for approval — so a misread prompt can't mutate production or alter your schema.ssn returns masked, a card_number tokenized, a secret vaulted.The same Strac MCP DLP layer covers your other databases and warehouses — Postgres MCP, Snowflake MCP, Databricks MCP, and BigQuery MCP — one control plane across every place AI agents reach your regulated data. See the MCP DLP pillar and the broader MCP data security discipline for the full model.
MCP DLP governs the AI-agent query surface. Strac's native Azure SQL DLP governs the data at rest — the same database, but discovered and classified so you know where the regulated columns are before any agent ever queries them. This is DSPM for Azure SQL, and most teams run both: native discovery to map and label the sensitive data, MCP DLP to govern how agents reach it.
What Strac's native Azure SQL DLP includes:
nvarchar(max) notes column holding clinical data or a config table hiding secrets is caughtFor the broader practice this sits inside, see DSPM for AI. For every SaaS, cloud, database, and endpoint surface Strac covers, see strac.io/integrations.
The screenshot below shows Strac's MCP DLP redacting sensitive data from a real Claude session — customer emails, identifiers, and credit card numbers tokenized inline before the model received them. The same inspection pattern runs on every Azure SQL MCP query routed through Strac, applied column-by-column to the returned rows.
Setup is agentless and takes under 10 minutes.
db_owner or an admin Entra role — so the agent's reach is bounded from the start.json
"mcpServers": {
"azure-sql": {
"url": "https://mcp.strac.io/azure-sql",
"auth": { "type": "bearer", "token": "<your-strac-token>" }
}
}
For Cursor, OpenAI Agents, and custom agents — same endpoint, same auth.The same Strac Azure SQL MCP DLP control produces evidence mapped to every major compliance framework.
For the broader AI-data-governance program this sits inside, see AI DLP.
In June 2026 Microsoft deleted the experimental MssqlMcp sample from its SQL-AI-samples repo in a pull request literally titled "Removed unsafe MCP sample," explaining it "continues to pop up for customers leading them down the wrong road." The sample defaulted to write access (the .NET version had no read-only mode), which made it easy to give an AI agent destructive rights over a database. Microsoft now points to the SQL MCP Server built on Data API Builder, which is RBAC-governed and excludes DDL. Forks of the removed sample still circulate, so the safe move is the DAB path plus a DLP layer that inspects the data itself.
Use the SQL MCP Server on Data API Builder, not the removed sample or its forks. DAB governs access with per-entity, per-role RBAC, abstracts your schema, excludes DDL, and pulls secrets from Key Vault. Even then, RBAC controls which entities an agent can reach — it doesn't redact the regulated values inside the rows it returns. So scope tightly and put a DLP layer like Strac in front so the data itself is inspected, not just the access.
Yes — the same thing. The MCP specification says server; Claude and Cursor surface it as the Azure SQL connector. Both let an agent query your tables, and Strac's Azure SQL MCP connector redacts regulated columns at the tool-call boundary regardless of the label.
Not by itself. The widely-copied sample defaulted to write, a privileged agent bypasses Always Encrypted and Dynamic Data Masking, and even the RBAC-governed DAB path returns plaintext rows for the entities an agent can read. For production use against regulated data you need an MCP-layer control like Strac Azure SQL MCP DLP that scopes table and column access, blocks writes and DDL, and redacts sensitive columns before any row reaches the model.
Yes — that's a key point for SQL Server. Always Encrypted, Dynamic Data Masking, and Row-Level Security assume a constrained application principal; a broadly-privileged agent can return masked columns in cleartext. Strac inspects the actual rows returned at the MCP layer and redacts, masks, or tokenizes regulated values independent of the SQL-layer controls — so the protection holds even when the database-native masking is bypassed.
Yes. Strac inspects the operation before it executes. Writes (UPDATE, DELETE, INSERT), DDL (CreateTable, DropTable, ALTER), and risky stored procedures can be blocked outright, allowed only on specific tables, or routed for human approval — so even a write-enabled server can't let a misread prompt mutate production or change your schema.
PII (SSN, driver's license, passport, address, phone, email), PHI (clinical notes, MRN co-occurrence, ICD-10 codes adjacent to identifiers, lab values), PCI (full and partial card numbers via Luhn check), credentials (API keys, AWS / GCP / Azure access keys, OAuth tokens, JWTs, connection strings — 48+ patterns), and custom detectors trained on your internal classifications. Detection runs column-by-column across the returned rows, including text inside nvarchar(max) and JSON columns.
Under 10 minutes for the first database. Connect Strac with a least-privilege SQL principal, paste the Strac MCP endpoint into your AI client's config, pick a policy template, done. No application changes, no schema migration, no re-grant.
The Azure SQL MCP server is fast becoming the way AI agents read — and sometimes write — your SQL Server data. Microsoft thought the risk was serious enough to delete its own sample and call it unsafe. The supported DAB path is a real improvement, but it governs access, not the plaintext PII inside the rows an agent is allowed to read — and your SQL-layer masking can be bypassed by a privileged agent. Running Azure SQL MCP in 2026 without an MCP-layer governance control isn't a question of if the first incident reaches your security team; it's when.
Strac Azure SQL MCP DLP gives you the control plane — see every query, scope every agent, block writes and DDL, protect every regulated column, prove every call — so your team can use Azure SQL with Claude, Cursor, ChatGPT, and any future AI client without making each one a separate security exception.
If you are running — or about to run — Azure SQL MCP in production, book a 30-minute demo. We'll walk through the architecture, the DAB-vs-sample decision, the masking-bypass risk, the policy templates, and a deployment plan for your specific database and AI clients.
For the broader MCP DLP control plane across every data surface, see the MCP DLP pillar. For more data-platform deep dives: Postgres MCP, Snowflake MCP, Databricks MCP, BigQuery MCP.
.avif){kind=icon}
.gif)
