Text-to-SQL Governance: How to Let AI Query Production Data Safely

Giving an LLM access to your database is easy — a connection string and twenty lines of code. Giving it access your security team can sign off on is an entirely different project, and it's the one that determines whether text-to-SQL ever leaves the pilot phase.

Why human-era governance breaks

Traditional database governance assumed a small set of trained humans writing queries: grant schemas, trust the analysts, review access quarterly. Text-to-SQL breaks every assumption:

• The query author is a model, not a person who signed a data-handling policy.
• The requester may be anyone — the whole point of AI self-serve is that sales ops and finance ask questions directly.
• Volume explodes. Hundreds of novel queries a day, none pre-reviewed.
• Context leaks. Whatever the model reads — schema, sample rows, results — may flow into prompts, logs or third-party APIs.

If your governance plan is "the service account is read-only", you don't have a governance plan.

The four layers of text-to-SQL governance

Layer 1: Identity-aware execution

Every AI query must execute as the requesting user's permission set, not as a privileged service account. When a viewer asks a question that touches a restricted column, the system must know it's a viewer asking. This sounds obvious; most text-to-SQL demos get it wrong because a shared service account is the path of least resistance.

Layer 2: Column- and row-level policy

Sensitive columns (SSN, email, DOB, salary — see our PII masking guide) need classifications that the query engine enforces:

• Refuse — viewers asking for restricted data get a refusal with a reason, not a workaround.
• Mask — privileged roles can query the column but receive [restricted] values unless explicitly entitled.
• Row policies — regional teams see their region; managers see their reports.

Classification should be automatic at ingest (pattern + name + content detection) with human review, because nobody manually tags 3,000 tables.

Layer 3: Refusal behavior

A governed system needs to say no gracefully — and log that it did. Questions that require restricted data, ambiguous questions that could only be answered by guessing, and requests outside the model's grounded knowledge should produce explicit refusals. A system that never refuses is a system that fabricates; that's the hallucination problem wearing a security hat.

Layer 4: Append-only audit

Every question, every generated SQL statement, every policy decision — recorded, immutable, exportable. When compliance asks "who accessed patient contact data in June?", the answer should be a filter, not a forensic project. Audit is also your quality loop: reviewing refusals and overrides is how policy improves.

The architecture that makes this tractable

You could bolt these four layers onto a raw text-to-SQL pipeline, but you'd be rebuilding a semantic layer piece by piece. The semantic layer is the natural enforcement point because it already sits between questions and SQL:

Governance need	Semantic layer mechanism
Identity-aware queries	Workspace roles resolved before generation
Column masking	Sensitivity flags on the schema model, applied in SQL
Sane refusals	Grounded entity/metric resolution — "I don't know" beats a guess
Audit	Every resolution step already structured and loggable

This is how Sema implements it: columns are auto-flagged at discovery, viewers get refusals with reasons, admins get masked values with an audit entry (chat.restricted_refusal / chat.restricted_override), and the log is append-only by construction.

A rollout checklist

1. Inventory sensitive columns automatically; review the flags with your privacy owner.
2. Map workspace roles to data entitlements before opening AI access.
3. Decide refusal vs mask behavior per classification, per role.
4. Turn on the audit log from day one — retrofitting audit is misery.
5. Review the first month of refusals and overrides; tune policy, not prompts.

Governance done this way isn't friction — it's the unlock. The teams that can prove AI access is safe are the ones allowed to scale it. For the broader organizational framework around this, read AI data governance: a practical framework.