AI Agent and MCP Server Security for SQL Server
AI readiness covers many things, from data quality to infrastructure. We focus on security: what AI agents and MCP servers can do with your SQL Server data once they are connected. We review the access you plan to give them and design it so SQL Server itself enforces the limits, before an agent goes live.
Limits the database enforces
Instructions and system prompts guide an agent, but a model can misread them, and text it reads along the way can steer it somewhere else. This is known as prompt injection. Many AI tools also offer permission rules and hooks. They are useful, but they apply only inside that tool and only to the cases someone thought of, and the agent’s credentials work just as well from any other client.
What applies to every client is SQL Server’s own access control: whatever tool connects, the login can only do what it is allowed to do. That is the layer we review and design, alongside the controls in your AI tools.
When to call us
- You plan to connect an MCP server, Copilot or a Fabric data agent to SQL Server.
- Developers already connect AI assistants to databases, often with their own, highly privileged logins.
- A software vendor adds AI features to an application that runs on your SQL Server.
- Auditors, your board or your customers ask how AI access to your data is controlled.
Why AI agents need their own security review
An AI agent does what its login allows, not what you intended. It writes its own queries and works fast. A login that a human application used safely for years can expose far more once an agent decides which queries to run. The question is no longer only “who has access?” but “what can this login reach, and what would happen if the agent were tricked into using all of it?”
What we check
Hidden escalation paths
An agent can use every capability its login has, and combine them. So we check the known routes from a low-privileged login to more access, including escalation paths that only appear when capabilities are chained: ownership chaining, impersonation, module signing, linked servers, and procedures that run dynamic SQL in a more powerful security context.
New escalation paths keep being discovered, and new techniques are developed. So we also limit the blast radius with compensating controls: least privilege, a separate identity for each agent, and auditing that shows what it did.
Least privilege for agents
You get a concrete least-privilege design for each agent: a dedicated identity, only the objects and actions it needs, through approved stored procedures, a well-designed schema or a separate sandbox database, whichever fits, with row-level security and masking that the agent can’t switch off, and auditing that shows what it did. Where an agent should only read, we make sure it can’t write.
What you receive
- An access map for each agent: what its login can read, change and execute, directly and through indirect paths.
- Findings ranked by impact, with the effort to fix each one.
- A least-privilege design you can implement: identities, roles, views or procedures, and policies the agent can’t switch off.
- Auditing recommendations, so agent activity can be traced back to the person who asked for it.
The security part of AI readiness
AI readiness also covers data quality, pipelines and infrastructure. Our part is security: what an agent can do once it is connected. We are SQL Server security specialists. Sarpedon Quality Lab was founded by a former Microsoft Senior Program Manager for SQL Server security, and our team includes a former Microsoft Principal Program Manager for SQL auditing who wrote the auditing section of the Azure SQL Database STIG. We know SQL Server’s permission system down to the ownership chains, signed modules and side channels that most reviews never look at. Meet the team.
Securing Microsoft’s SQL MCP Server
If you are setting up Microsoft’s SQL MCP Server or another MCP server for SQL Server, the most important decision is the identity it connects with. The server runs every query the agent sends under that login or managed identity. We check which identity it uses, which databases and objects it exposes to the agent, what that identity could do beyond them, and which permissions to grant or deny so it can only do its job.
Agents and tools we review
Any AI system that reaches SQL Server through a login can be reviewed, for example:
- MCP servers for SQL Server, including Microsoft’s SQL MCP Server and third-party or self-built servers.
- AI assistants connected through MCP, such as Claude, ChatGPT or GitHub Copilot.
- Microsoft Copilot features that query SQL Server data, such as Copilot in SQL Server Management Studio.
- Microsoft Fabric data agents connected to SQL Server data.
- Custom text-to-SQL and RAG applications, for example built with LangChain or Semantic Kernel, that let a language model generate or run SQL.
How it works
- Scoping call: which agents, which databases and which logins.
- Review: read-only, building on our SQL Server Security Assessment, plus the access paths meant for AI agents.
- Results: what each agent can reach, the risks in order of impact, and the least-privilege setup to fix them.
Scoped to your AI systems
No two AI setups are alike. Which agents you use, how they connect and which databases they reach decide what needs checking. That is why this is a service of its own: we scope it to your agents and databases, and you get a fixed-scope proposal before any work starts.
Frequently asked questions
Is it safe to connect an AI agent to a production database?
It can be, if the agent’s login can reach only what it needs, can’t change protections such as row-level security, and its activity is audited. The risk usually lies in logins with far more rights than the task requires, MCP servers that are insecure by design, and unrestricted ad hoc queries. Ideally, an agent can only run specific, approved stored procedures. That needs design work for your environment, but it gives the tightest control. And for some systems, the risk is not worth the benefit: then a copy of the data, a sandbox or no agent access at all is the better choice. We help you weigh the risks against the benefit and estimate the work it takes to lock access down.
How do I give an agent least privilege?
Give each agent its own identity and grant only what the task needs: specific stored procedures for the tightest control, or a well-designed schema or even a separate sandbox database. Designed wrong, a schema or sandbox can itself become an escalation path, so ownership and permissions need care. Give read-only agents no write permissions, keep agents out of db_owner and other powerful roles, and check for indirect paths such as ownership chaining, impersonation and linked servers. Then audit what each agent does.
Can an agent bypass row-level security?
Yes, if its login is too powerful. Row-level security filters rows for every user, but a login that can alter or drop the security policy, such as a member of db_owner, can switch it off. Members of db_owner also see data unmasked despite dynamic data masking. Well-crafted queries can also infer filtered data, which Microsoft documents as a known limitation.
Where should limits for AI agents be enforced?
In several layers, and always in the database. Instructions, permission rules and hooks in the AI tool help. The OWASP Top 10 for LLM Applications also recommends implementing authorization in the downstream systems rather than relying on the model to decide whether an action is allowed. For SQL Server, that means the agent’s login and its permissions.
What is an MCP server for SQL Server?
MCP (Model Context Protocol) is an open standard that lets AI agents use tools and data sources. An MCP server for SQL Server, such as Microsoft’s SQL MCP Server, sits between the agent and your database and runs queries on the agent’s behalf, under the login it is configured with. That login decides what the agent can do.
Planning to connect AI agents to SQL Server?
Tell us which agents and databases you have in mind. We’ll show you what they could reach.