LLM SQL Chatbot Access Control and Query Safety

Design an LLM chatbot for SQL query generation over internal data. The discussion focuses on ensuring users can only query data they are allowed to access and preventing hallucinated or expensive queries such as accidental cross joins from crashing a Trino cluster. Requirements Design an internal LLM chatbot that generates SQL queries. Functional requirements: Accept natural-language analytical questions from users. Generate SQL against governed internal datasets. Enforce data access so each user can only query authorized tables, columns, and rows. Prevent unsafe, nonsensical, or extremely expensive SQL from reaching the warehouse unchecked. Return useful errors or clarifying questions when the request cannot be answered safely. Constraints and design points: Trino-cluster stability is a first-class constraint. Cross joins and hallucinated table / column names are explicit failure modes. Access control must be enforced outside the model, not only through prompting. Notes A strong design puts the LLM behind deterministic policy and validation layers: Retrieve the user's authorized schema subset before generation and expose only that subset to the model. Validate generated SQL against a parser and catalog before execution. Apply a policy engine for table, column, and row-level permissions. Add query guards: join limits, required predicates for large tables, cost estimation, timeout, row limit, and read-only execution. Use dry-run / explain-plan checks before submitting to Trino. Log prompts, generated SQL, policy decisions, and execution metadata for audit and improvement. Preparation Sketch the flow: user request -> auth context -> schema retrieval -> LLM generation -> SQL parser -> policy / cost gate -> execution. Prepare examples of deterministic guardrails that do not rely on the model following instructions. Practice explaining how to handle an unauthorized question without leaking whether restricted data exists.