VYAN LABS / ENGINEERING NOTE
Enterprise Text-to-SQL MCP: security before syntax.
Sourish Sarmah built an enterprise Text-to-SQL MCP at Agentic Private Markets. This note explains the design questions that matter when a natural-language interface can reach company data.
Discuss Text-to-SQLBy Sourish Sarmah. Based on his prior employment at Agentic Private Markets, not a Vyan Labs client engagement. The guidance does not disclose that system’s implementation or private data. ·
01 / THE PROBLEM
A question can become a database query.
A Text-to-SQL (Text2SQL) system translates a user’s question into SQL. An MCP server gives an AI client a tool interface to request that work. The security boundary has to survive an incorrect or adversarial model output.
A useful enterprise system must understand business vocabulary and schema relationships, but generating valid SQL is only one requirement. The same system has to decide who is asking, which data they may see, what query shape is permitted, and how the result is returned. A fluent answer that crosses a data boundary is a failure even when the SQL is syntactically correct.
The model should propose a query. The application and data layer should decide whether that proposal is allowed. This separation is the central design choice.
02 / REFERENCE FLOW
Six checks before an answer.
A practical review path for teams building a secure Text-to-SQL MCP. These are recommended controls, not a description of confidential implementation details.
Authenticate the caller
Bind the MCP request to a verified identity and tenant context. Do not let the language model choose or rewrite that identity.
Limit the data surface
Expose approved datasets and business definitions. Keep sensitive tables and columns out of the tool’s accessible schema unless there is a clear need and policy.
Validate the query
Parse and inspect proposed SQL against an allowlist of operations, schemas, and functions. Do not rely on a prompt such as “only generate SELECT” as the enforcement layer.
Execute with least privilege
Use a database role that cannot write or administer data. Apply database access policies, row-level controls where appropriate, timeouts, and result limits.
Constrain the result
Return only the fields and rows the caller may see. Redact sensitive values where required, and make the query or source visible enough for review.
Record and evaluate
Log the request, identity, policy decision, query, execution status, and result size under appropriate retention rules. Test permission boundaries as well as answer accuracy.
03 / FAILURE MODES
What a demo usually misses.
A realistic evaluation set should include these cases, not just easy questions over a clean schema.
| Failure | Control to test |
|---|---|
| Cross-tenant answer | Identity propagation and database row policies are enforced even if the model requests another tenant. |
| Prompt injection in retrieved content | Untrusted text cannot change tool permissions or bypass the query policy. |
| Expensive or unbounded query | Statement timeout, row limit, allowed query shape, and cost controls stop resource exhaustion. |
| Correct SQL, wrong business meaning | Golden questions check joins, units, time windows, and source definitions. |
| Sensitive result leakage | Column policy, redaction, output limits, and audit checks apply after execution too. |
04 / BUYER CHECKLIST
Questions to ask your builder.
These questions reveal whether a proposed Text-to-SQL agent is ready for enterprise use.
- Can the model ever run a query with broader permissions than the authenticated user?
- Which layer rejects unsafe SQL, and can it be tested independently of the prompt?
- How are tenant and row-level access enforced if a generated query changes shape?
- What happens when a query is expensive, ambiguous, or returns sensitive columns?
- How do we evaluate factual correctness and authorization failures before release?
- What evidence is available after an incorrect or denied answer?
We can help design the MCP boundary, query policy, evaluation set, and backend that connects this safely to your data environment. Start with the permissions and business definitions; model choice comes later.
Discuss a secure Text-to-SQL system05 / RELATED WORK
Build the complete system.
Text-to-SQL depends on agent design, backend policy, and operating controls working together.
06 / REFERENCES
Technical sources.
Primary documentation for the security and data-control principles discussed above.
07 / CONTACT
Tell us what needs to work.
A useful first conversation starts with the workflow, constraints, and what success would look like.
Let’s make it real.
Share a brief outline. Sourish will reply directly to discuss scope, feasibility, and a sensible first milestone.
support@vyanlabs.in ↗