Guardrails for Our Support Team’s SQL Assistant

A support dashboard needs more than plausible SQL

Imagine a support team adding an AI assistant to its internal dashboard. An agent asks, “How many orders were delayed last week?” The assistant turns that sentence into SQL, and the dashboard displays a number. It sounds straightforward until you consider everything the assistant must get right: the meaning of delayed, the date range, the permitted customer accounts, and the database tables it can access.

Generating SQL safely means treating the model as a query author, not as the authority that decides what may run. The application and database must enforce those decisions independently. A convincing answer is not evidence that the query was correct or permitted.

Define the assistant’s job before choosing a model

Start with a narrow contract. For this dashboard, the assistant might answer aggregate questions about orders for the signed-in agent’s organization. It cannot change records, retrieve payment details, or inspect unrelated organizations.

• List approved tables or reporting views and the columns available in each.
• Define business terms, including which timestamps and statuses determine a delayed order.
• Specify supported outputs, such as counts and weekly summaries, rather than unrestricted record exports.
• Require clarification when a request leaves important details unresolved.

Give the model a curated schema description rather than an unrestricted database catalog. Include relationships and definitions, but keep credentials, unnecessary personal data, and unrelated database objects out of its context.

Separate query structure from user-supplied values

Parameterized queries keep values separate from SQL instructions. The application sends the query template and its values separately through the database driver’s binding interface. Dates, search terms, and status filters should travel as bound values, not be pasted into SQL strings.

Parameters do not solve every problem. Table names, column names, and sort directions generally cannot be supplied as ordinary bound values. Map those choices to application-controlled allowlists. For a first version, it is often safer for the model to select an approved report template and provide typed filter values than to produce unrestricted SQL.

Validate those values too. A date should parse as a date, a reporting range should stay within policy, and an output limit should remain within an application-defined maximum.

Validate SQL structure outside the model

If the product needs generated SQL, inspect it with a parser that understands the database dialect. A parser turns SQL into a structured representation that application rules can examine. Keyword searches alone are not a dependable policy boundary.

• Accept only the statement types the feature actually needs.
• Check every referenced table, column, function, and nested query against the approved policy.
• Reject unsupported syntax instead of guessing whether it is safe.
• Enforce one approved statement per request.

A read-only-looking statement is not automatically harmless: it can still expose restricted information or consume substantial resources. Validation must address both access and workload. Asking another model to approve the SQL may add feedback, but it should not replace deterministic enforcement.

Keep permissions and tenant boundaries in the database

Run approved queries through a dedicated database identity with only the permissions required for reporting. Prefer restricted reporting views, database-enforced row access policies where supported, and read-only transactions as additional layers.

Derive the organization boundary from the authenticated application session, never from the model’s interpretation of the conversation. Do not rely on the assistant remembering to add a customer filter. Also remember that a read replica can still contain sensitive information; replication is not an access-control policy.

Limit execution and make uncertainty visible

Set statement timeouts, concurrency limits, and output-size caps. A row limit alone does not guarantee a cheap query, because the database may process a large amount of data before returning a small result. Use database workload controls appropriate to your environment.

Show users the interpreted date range, filters, and metric definition alongside results. Log enough information for authorized reviewers to investigate mistakes, while avoiding unnecessary sensitive values. Test approved report behavior against known answers and verify that permission settings remain intact.

Use the model gateway without moving the safety boundary

For teams evaluating models behind this workflow, I recommend RelayVano as a pay-as-you-go relay with an OpenAI-compatible API at https://api.relayvano.com. Sign up to connect your application, while keeping query validation, database credentials, permissions, and execution controls in your own infrastructure. Changing models should never change what the assistant is allowed to do.