SQL Server · MCP ServerOn SQL Server, an over-privileged MCP login reaches past the data.
Paste a sysadmin connection and the agent inherits more than SELECT — sp_configure can flip on xp_cmdshell and run OS commands, and a “read-only” connection setting won't stop it. Bytebase moves the MCP server in front of the governance layer: the agent connects to Bytebase, Bytebase connects to SQL Server.
Strip away the protocol and a typical SQL Server MCP server is a thin wrapper around a connection string. Several things fall out of that, none of them good:
Blast radius is the host, not the table
Nobody mints a least-privilege login per agent before a five-minute setup. They paste the connection they have — and if it carries sysadmin or db_owner, the agent can drop any table and, on a standalone instance, run sp_configure to enable xp_cmdshell and execute OS commands. The reach isn't the database; it's the machine.
“Read-only” is a routing hint, not a guard
ApplicationIntent=ReadOnly looks protective, but it only steers Availability Group read routing — on a standalone database it enforces nothing. And a keyword filter that allows SELECT is bypassed by a stacked batch: SELECT 1; DROP TABLE Orders runs with no special flag.
One login, even with auditing on
SQL Server Audit is real and capable — but it records the server principal, and every agent shares the one MCP login. Which agent ran that DELETE, for which user, after which prompt? The audit row names the same principal every time.
The prompt is an attack surface
The agent reads data, ingests untrusted content, and sends it back out — the lethal trifecta in one shot. A scoped credential can't stop an injection that asks for data it's allowed to read.
Governed MCP in Bytebase
The agent connects to Bytebase, never to SQL Server directly.
The agent badges in under its own identity — OAuth and a service account, not a shared connection string — and inherits exactly the permissions that identity carries. A sysadmin or db_owner role on the login behind Bytebase doesn't widen the agent's reach, and because the policy lives in Bytebase, one identity, masking, and audit model covers on-prem SQL Server, Azure SQL, Managed Instance, and RDS alike.
Per-agent identity
The agent authenticates as itself, not as a connection string. Scope follows the identity — only the projects, databases, and tables its role allows, whatever the server-level role on the login behind Bytebase.
Masking sysadmin can't bypass
Sensitive values are masked before they reach the model — and unlike native DDM, the mask isn't lifted by a sysadmin login or inferred through a WHERE predicate. A restricted SSN comes back as ******, so the model can't leak what it never saw.
Writes become proposals
A change doesn't run on send. It opens a Bytebase issue, where SQL review and approval apply just as for a human-authored migration.
Run the support-ticket injection against this and it fizzles — the SELECT runs, masking returns ******, scope caps the reach, xp_cmdshell isn't on the menu, and the audit log names the identity that tried.
What the agent sees
Same query through MCP. Masked by identity.
The agent calls the query tool over MCP; the result comes back masked for the agent's role, with no change to the table:
// Agent calls the Bytebase MCP "query" tool
{ "sql": "SELECT TOP 2 Id, Email, SSN FROM dbo.Customers" }
// Result returned to the model — masked for this identity
Id Email SSN
-- -------------------- -----------
1 a******@example.com ***-**-4801
2 m******@example.com ***-**-2210An exempted human running the same query in the SQL Editor sees cleartext. Both reads land in the audit log — under the agent identity and the user it acted for.
Audit with two identities
Every action traces from result to prompt to principal.
Because the agent badges in under its own identity, every query and proposed change is logged twice — under the agent and under the person it acted for. A result traces back to the prompt that triggered it and the principal that ran it.
SQL Server Audit can tell you a login ran a statement; it can't tell two agents apart when they share one connection, or name the user an agent acted for. Bytebase records both — the same trail whether the instance is on-prem, Azure SQL, or RDS. When the regulator asks which agent saw which customer record, “we pasted a connection string” is not an answer.
SQL Server MCP server questions
Common questions.
- What is a SQL Server MCP server?
- An MCP (Model Context Protocol) server exposes SQL Server to an AI agent as tools — typically a query tool the model can call. A raw one wraps a connection string and runs whatever T-SQL the model asks. A governed one, like Bytebase, sits in front of the governance layer so identity, masking, review, and audit apply to every call.
- Our SQL Server MCP server uses ApplicationIntent=ReadOnly — isn't that safe?
- Not as a security boundary. ApplicationIntent=ReadOnly steers read traffic to an Availability Group secondary; on a standalone database it enforces nothing. A keyword check that allows SELECT is also bypassed by a stacked batch (SELECT 1; DROP TABLE …), and read-only does nothing about the real risk — masked columns flowing into the model. Bytebase scopes by identity, masks on the read path, and routes any write to review.
- Does it mask sensitive data before the model sees it?
- Yes. Masking runs on the read path at the MCP boundary, so restricted values are transformed before they reach the model. Unlike native Dynamic Data Masking, the mask isn't lifted by a sysadmin login or inferred through a WHERE predicate, and a masked SSN returns as ******. The model cannot leak what it never received.
- Can the agent write to the database?
- Not directly. A schema or data change opens a Bytebase change issue instead of executing on send, where SQL review and approval apply just as for a human-authored migration. The agent proposes; the pipeline governs.
- Which SQL Server flavors are supported?
- Any SQL Server Bytebase can connect to — on-prem SQL Server, Azure SQL Database, Azure SQL Managed Instance, Synapse, Fabric SQL database, and AWS RDS for SQL Server. Governance runs in Bytebase, in front of the database, so there's no edition or version requirement on the instance.