Direct answer
Resolve identity and permissions before generating or executing SQL. Limit the available schema, inject row and column constraints into the query plan, validate the statement, execute it through a restricted role, and record the evidence behind the result. Filtering the answer after the database query is already too late.
Text-to-SQL is the visible step, not the whole system
A user asks, “Which regions lost the most margin last quarter?” The model still needs to know what “margin” means, which sources contain revenue and cost, how tables join, which fiscal calendar applies, and which regions that user may see.
A syntactically valid query can be commercially wrong, operationally expensive, or unauthorized.
That makes natural-language analytics a governed query-planning problem. SQL generation is one component inside it.
Start with a scoped semantic layer
Do not expose the raw enterprise schema and hope the model discovers the right meaning. Publish approved metrics, dimensions, relationships, synonyms, time definitions, and join paths. Mark sensitive columns and sources that require elevated access.
At request time, combine that semantic context with the user’s tenant, groups, role, and purpose. The model should only see the sources it may use. Required row predicates and column restrictions become part of the plan before SQL exists.
This prevents an unsafe pattern: query everything, then hide forbidden rows in the interface.
Validate the query twice
First, inspect the generated statement before execution. Allow only supported operations, verify referenced objects, require tenant predicates, block comments or stacked statements, and reject unexpected functions. Estimate cost where the database supports it. Add row, time, and resource limits.
Second, execute through a database identity that can do only what the workflow permits. Application validation is useful, but the database must remain the final enforcement boundary.
Read-only does not mean harmless. A full-table scan can still degrade production. Use replicas, query queues, timeouts, and concurrency limits for analytical workloads.
Explainability should survive the chat
The answer should retain the original question, selected metric definitions, sources, filters, generated SQL, validation result, permission context, execution time, and result version. Users may not need to see all of it by default, but reviewers and analysts need a path to inspect the logic.
In Zenveus’s enterprise AI business-intelligence work, the product ran inside the customer’s AWS account and federated data through Trino. Existing identity and role rules shaped query construction; unauthorized references were blocked before execution. The output became a persistent Apache Superset dashboard, while the system retained the sources, generated and validated SQL, permissions, filters, and visual choice behind the answer.
The valuable product was not a chatbot that wrote SQL. It was governed analytics that happened to begin in natural language.
Test authorization with paired questions
Create evaluation pairs where two identities ask the same question. The correct results should differ because their permissions differ. Add tests for unauthorized columns, ambiguous metrics, cross-tenant joins, prompt injection inside stored data, expensive queries, and requests to change state.
Also test absence. The system should distinguish “no matching data” from “you are not allowed to search all relevant data.” Those messages carry different meaning.
The enterprise acceptance test
Ask whether a security reviewer can prove four things:
- the model never received unauthorized schema or data;
- the database independently enforced access;
- the query stayed within resource limits;
- the result can be reconstructed later.
If any answer is unclear, the interface may be conversational, but the control model is not enterprise-ready.
Related Zenveus services: Agentic AI Development and SaaS Development