One HTTP contract/governed API for DB Agnostic Solution (PostgreSQL, MySQL, and SQL Server) with tenant-safe execution and assistant-friendly integration.

Introduction

Enterprises operate across multiple SQL systems—most commonly PostgreSQL, MySQL, and Microsoft SQL Server—spread across business units, regions, and tenants. While leaders increasingly want natural-language access to this data, they are not willing to expose raw credentials to every assistant or integration, nor rely on a model’s “politeness” as a substitute for enforced SQL policy.

What’s needed is not just SQL generation—but controlled execution.

This article introduces a governed natural-language-to-SQL (NL2SQL) service: a database-agnostic HTTP API that understands who is asking, applies tenant-specific policy, validates SQL before execution, and returns a concise, controlled response.

We then position where Model Context Protocol (MCP) fits in this architecture. MCP is a powerful standard for tool discovery and invocation across AI clients—but it does not replace tenant binding, authorization hooks, or query validation. Those responsibilities belong in the data plane, where trust and enforcement must be explicit.

The real problem isn’t SQL—it’s trust

Most NL2SQL implementations don’t fail at generating SQL.

They fail at controlling it.

Three failure modes show up consistently in enterprise systems:

1. Unbounded agents → unpredictable cost

If your agent can “think” indefinitely, cost and latency become impossible to manage.

2. Prompt-based safety → false guarantees

“Only generate SELECT queries” is not enforcement—it’s a suggestion.

3. Weak tenant isolation → real risk

If the client determines the database or connection, isolation is already compromised.

A different approach: move governance into the data plane

Instead of embedding SQL logic into every assistant, tool, or integration, centralize responsibility:

A single governed NL2SQL API between all AI systems and your databases.

At the center is one simple interface:

POST /api/v1/query

Every consumer—whether it’s a dashboard, automation workflow, or AI assistant—uses the same contract.

No database credentials.
No connection strings.
No client-side routing.

Everything is resolved server-side.

So what does this look like in practice?

Instead of distributing logic across systems, everything flows through a governed data plane.

Data Plane Architecture

Notice what’s missing:
No client ever talks directly to a database.

What actually happens inside the service

Each request flows through controlled stages:

1. Identity and tenant resolution

The system determines:

• Who is making the request
• Which tenant do they belong to
• Which database and policies apply

2. Bounded SQL generation

Natural language is converted to SQL with:

• Limited reasoning steps
• Controlled execution path

3. Validation before execution

This is the enforcement layer:

• Read-only constraints (e.g., SELECT-only)
• Row limits
• Query timeouts
• Table and column allowlists

4. Controlled execution and response

Only validated queries are executed, and responses are intentionally minimal:

{ "answer": "..." 

Where MCP fits—and where it doesn’t

Model Context Protocol (MCP) is often misunderstood in this context.

MCP is excellent at:

• Tool discovery
• Standardized invocation
• Cross-assistant interoperability

But MCP does NOT handle:

• SQL validation
• Tenant resolution
• Authorization enforcement
• Query safety

The right mental model

MCP is a control plane pattern.
NL2SQL governance is a data plane responsibility.

The correct integration pattern

Use MCP as a thin layer—not the enforcement layer.

All critical responsibilities remain centralized:

• Validation
• Policy enforcement
• Observability

What this architecture enables

This pattern unlocks multiple enterprise use cases:

Self-service analytics

Business users query data without writing SQL.

Multi-tenant SaaS platforms

One API serves many customers with strict isolation.

AI assistants and copilots

Assistants access data safely without direct database connectivity.

Support and operations

Teams query production data within controlled boundaries.

What most teams get wrong

Common pitfalls include:

• Treating prompts as enforcement
• Allowing clients to pass database connections
• Duplicating validation logic across services
• Using MCP as backend infrastructure

These patterns work in demos—but fail under real production constraints.

Architecture in one line

One governed API between every AI system and your databases.

Closing Thoughts

The goal isn’t to replace MCP.

It’s to use each layer for what it does best:

• MCP → tool access and orchestration
• NL2SQL API → governance and execution

When you separate these concerns, the system becomes:

• Safer
• More scalable
• Easier to audit

Because in enterprise AI:

Trust doesn’t live in prompts.
It lives in the data plane.