Governed AI Access — NL-to-SQL, RAG & MCP

The demand is legitimate: business users want answers without a ticket queue, org assistants want a SQL surface, incident copilots want schema access. The DBA's job is not to say no — it is to design the blast radius. This module covers the three access patterns you will be asked to enable — natural-language SQL, retrieval over database content, and MCP servers for AI assistants — and the governance that makes each deployable: eval sets before rollout, entitlements enforced in the engine, and guardrails that assume the caller is confused at best.

The scenario — the confident wrong number

Deepak is a database developer at a Gurugram consumer-lending company. A VP hears a text-to-SQL demo at a conference; two weeks later Deepak has a pilot: an LLM with schema access on a read replica, a chat UI, twelve business users.

The rescue, over the following month, is this module in miniature: curated semantic views that encode the business rules (v_disbursals with status and date logic baked in), a scoped role that can only see those views, an eval set of 25 real questions with known-correct answers, execution accuracy measured before and after curation — and refusal behavior for questions the views cannot answer. Accuracy on the eval set went from "we think it's usually right" to a number that could be defended, and improved with every view iteration.

NL-to-SQL, honestly assessed

• Why raw failsreal schemas have cryptic names, overloaded status columns, soft deletes, duplicated-looking tables with different authority, and tribal date semantics. The model guesses fluently; fluent guessing over finance data is the failure mode.
• Semantic views are the fix that workscurated views that pre-join, pre-filter, and rename into business vocabulary. The LLM queries a small, honest surface instead of the raw schema. This is the same curation lesson every NL-analytics vendor has converged on.
• Eval sets make accuracy a number25+ real questions with expected results, scored by execution accuracy (does the query return the right answer, not does the SQL look right). No eval score, no rollout; the score is also your regression suite for every model, prompt, or view change.
• Refusals are a featureambiguous questions ("revenue" — booked? recognized? disbursed?) must produce a clarifying refusal, not confident SQL. Seed the eval set with ambiguous questions and score refusal behavior explicitly.

Vendor NL surfaces follow the same discipline: Oracle Select AI takes a scoped profile (allowed tables, chosen LLM) — evaluate its accuracy on your schema before enabling it for anyone; SSMS Copilot's NL query is a DBA-facing convenience whose output you read before you run, same as any assistant. Evaluation before enablement, not after the first wrong number reaches a deck.

The guardrail stack — blast-radius design the DBA owns

Whatever sits on top — NL-to-SQL, RAG, MCP — the engine-side controls are one stack:

The design habit: assume the layer above will fail. The prompt will be injected, the model will generate something weird, the app will pass the wrong tenant ID. Each engine-side layer holds independently — that is why entitlements live in RLS and not in a WHERE clause the model is asked to include.

RAG over the database — retrieval that respects RLS

Module 4 built vector search in the engine; the governance question is who retrieves what. If support tickets are embedded and searchable, tenant A's semantically relevant results must never include tenant B's tickets — and the only trustworthy enforcement is the same row-level security the relational data already obeys. Engine-side retrieval makes this natural: the vector query is still SQL, so it runs as the caller (SET ROLE / session context per request — not a super-role connection pool that flattens identity), and RLS/VPD filters the candidate rows before similarity ranking.

Then prove it hostilely. An RLS-safe design is a claim; adversarial leak probes are the evidence:

• Cross-tenant semantic probesqueries crafted to be maximally similar to another tenant's known content; any hit is a policy gap, however "relevant."
• Filter-evasion probesrequests phrased to coax the retrieval path around its scoping (alternate entry points, direct function calls, missing session context defaults).
• Zero-entitlement probesa caller with no rights must get zero rows, not "no relevant results" — the difference between denial and luck.
• Re-runs on every policy changethe probe suite is a regression test; ten probes, all blocked, is the leak-test report an auditor and a CISO will both accept. This inheritance story is the estate argument sharpened: retrieval in the engine inherits entitlements the org already trusts, while an external vector store starts its security story from zero.

MCP servers — a SQL surface for the org's assistants

MCP is how AI assistants and agents get tool access to your database, and it will arrive with or without you — better it arrives through a server you configured. Threat-model it as what it is: a programmatic SQL surface whose caller is a language model that can be socially engineered by any document it reads.

The same read-only MCP pattern, pointed at monitoring APIs instead of table data, gives you natural-language fleet operations — "which instances grew 10% this month and why" — with one addition: a curated metric vocabulary. Define the metrics, their units, and their meaning in the resources the assistant sees; an assistant guessing what "growth" means across forty instances produces confident nonsense, the same disease as raw text-to-SQL, cured by the same curation.

The documentation layer that makes it all work

Every pattern above leans on the same scarce resource: written-down meaning. Semantic views encode it; eval sets test it; a data dictionary is its cheapest broad form — and AI now removes most of the drafting cost. Generate table and column descriptions from names, constraints, sampled values, and how app code actually uses the columns; then a human verifies business meaning before publication — the model can infer that status_cd is an enum, but only the org knows code 7 means "written off, pre-2019 rules." Wrong documentation is worse than none: every downstream AI surface inherits the error at generation speed. Verified, published, and fed back into NL-SQL prompts and MCP resources, the dictionary compounds: better docs make every AI answer over your data better.

Try it now

1. 1Write three semantic views. Pick the three questions business users most often ask of your database and build views encoding the status, date, and authority rules a correct answer needs — the meaning nobody wrote down.
2. 2Build a 10-question eval set. Real questions, expected answers from hand-verified SQL, two deliberately ambiguous entries that should produce refusals. Run your assistant's NL-to-SQL over the views and score execution accuracy.
3. 3Scope one AI role. Create a read-only role granted only those views, with a statement timeout and row limit; write down (or configure) what it blocks — catalogs, PII tables, base tables — as your first guardrail spec.

Check yourself: Security asks: "If the org assistant's MCP access were compromised by prompt injection tomorrow, what is the worst case?" Walk the guardrail stack and state the honest answer — and the one residual risk that remains.

This module anchors LAB-09 (guardrailed NL-to-SQL with an eval scorecard) — accuracy measured before and after semantic-view curation, with seeded ambiguous questions that must refuse — and LAB-10 (RLS-safe RAG and MCP leak test), where two seeded policy gaps must be found before all ten probes block. Do it at work this week → pb-33 (text-to-SQL on a replica), pb-34 (MCP guardrails), pb-35 (RLS-safe retrieval), pb-36 (NL fleet monitoring), and pb-27 (the verified data dictionary).