Why Enterprises Should Not Let LLMs Execute SQL Directly

Length: About 2,800 words · Reading time: about 13–15 minutes

Enterprises should not let LLMs execute SQL directly because an LLM can generate a query that looks reasonable but is still unsafe, unauthorized, too expensive, or semantically wrong.

The issue is not whether a model can write SQL. Many models can produce plausible SQL for common analytical questions. The issue is whether that SQL should be trusted as the final decision before a database, warehouse, or production data platform runs it.

For enterprise ChatBI, Text-to-SQL, and AI data agent systems, the safer pattern is simple: the LLM may propose SQL, but a deterministic control layer should validate, govern, and audit that SQL before execution. That layer is often described as an LLM SQL Guard.

Key Takeaways

• LLM-generated SQL should be treated as untrusted input until it has been validated against the target dialect, schema, catalog, permissions, and data policies.
• Prompt instructions such as “only write safe SQL” are useful, but they do not enforce access control or prove that a query is safe to run.
• The most serious Text-to-SQL risks are often semantic, not syntactic: hallucinated columns, wrong joins, missing filters, sensitive fields, and unauthorized access.
• A production architecture should place a SQL Guard between the LLM and the database, with allow / deny / warn / require approval decisions.
• The guard should return structured feedback so the model or application can repair unsafe SQL instead of simply failing.
• Audit logs matter: enterprise teams need to explain who asked what, which SQL was generated, which policy was applied, and why a query was allowed or blocked.

Short Answer

Do not let an LLM execute SQL directly against enterprise data. Let the LLM generate a candidate query, then pass that query through a deterministic SQL Guard that can parse the SQL, bind it to the real catalog, validate tables and columns, check user permissions, detect sensitive fields, evaluate query risk, and record an audit trail.

A direct LLM-to-database path may be acceptable for a toy demo with synthetic data. It is not a responsible production pattern for enterprise data access.

Why This Matters Now

Many teams are adding natural-language analytics to their applications. A business user asks a question such as:

Show me the top customers by revenue this quarter.

The system sends the question to an LLM, and the model returns SQL:

SELECT c.customer_name, SUM(o.amount) AS revenue
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
WHERE o.order_date >= DATE '2026-01-01'
GROUP BY c.customer_name
ORDER BY revenue DESC
LIMIT 20;

For a demo, this feels magical. For a production enterprise system, it immediately raises harder questions:

• Is the user allowed to see customer-level revenue?
• Did the model use the correct tables and columns?
• Is the time filter correct for the company’s fiscal calendar?
• Should this query include region, tenant, or row-level restrictions?
• Does it expose customer names, emails, phone numbers, or other sensitive fields?
• Is the query cheap enough to run now?
• Can the system explain why this query was allowed?

These are not language-model questions. They are data governance questions.

The Risk Is Not Only Bad SQL Syntax

It is tempting to think the main problem is whether the generated SQL parses. Syntax matters, but a syntactically valid query can still be dangerous.

For example, an LLM may generate:

SELECT name, email, phone, date_of_birth
FROM customers
WHERE region = 'EU';

This query may be valid SQL. The table may exist. The columns may exist. The result may even answer the user’s question. But it may still violate field-level permission rules, privacy policies, or data minimization requirements.

Another model output may look harmless:

SELECT *
FROM transactions
WHERE transaction_date >= DATE '2020-01-01';

Again, the SQL may parse. But in a large warehouse, it may scan far more data than intended, expose columns that the user did not ask for, and create operational cost. A direct execution path gives the database no context about whether the SQL was generated by a model, whether the user had the right intent, or whether the application should request approval first.

What Can Go Wrong When LLMs Execute SQL Directly

1. The model may hallucinate schema objects

LLMs often infer table and column names from natural language. If the real schema has customer_id but the model writes client_id, the query may fail. More subtly, if a similar column exists with a different meaning, the query may run and produce misleading results.

Schema hallucination is not just a usability issue. In analytics workflows, a wrong column or join can lead to bad business decisions.

2. The query may bypass application-level permissions

Database permissions are necessary, but many enterprise applications enforce additional context-specific rules: tenant restrictions, department-level access, purpose-based access, field masking, approval requirements, and row-level filters.

A direct LLM-to-database path makes it harder to apply those rules before execution. A user may ask a broad question, and the model may generate SQL that touches restricted fields without understanding the user’s role or policy scope.

3. Sensitive fields may appear through aliases or expressions

Sensitive data is not always obvious from the final column name. A query may derive, concatenate, hash, aggregate, or alias sensitive fields:

SELECT
  customer_id,
  CONCAT(first_name, ' ', last_name) AS customer_name,
  phone AS contact_number
FROM customer_profiles;

A simple keyword filter may miss this. To identify the real data dependencies, the system needs SQL parsing, name resolution, catalog metadata, and often column-level lineage.

4. Read-only instructions may fail

Many teams add prompt rules such as:

Only generate SELECT statements. Never modify data.

That instruction helps, but it is not enforcement. A model can still produce UPDATE, DELETE, CREATE TABLE AS, MERGE, stored procedure calls, or dialect-specific statements that change data or trigger side effects.

A production system should verify statement type before execution.

5. The model may generate expensive queries

A model does not naturally understand the current warehouse load, table size, partition strategy, or cost profile. It may omit partition filters, generate cross joins, use SELECT *, or scan years of data to answer a narrow question.

For enterprise systems, query cost is part of safety. Some queries should be allowed immediately, some should be rewritten, some should require approval, and some should be denied.

6. The system may lose auditability

If an LLM generates and executes SQL directly, it can be difficult to reconstruct the decision path later. Enterprise teams may need to know:

• who asked the question;
• what prompt context was used;
• what SQL was generated;
• which tables and columns were touched;
• which policies were checked;
• why the query was allowed, denied, or modified;
• what result was returned.

Without this evidence, Text-to-SQL becomes difficult to govern.

Prompt Engineering Helps, But It Is Not a Control Layer

Prompt engineering can reduce risk. It can tell the model to avoid destructive statements, use a specific schema, add LIMIT, or ask for clarification. Those are useful behaviors.

But prompt engineering cannot reliably enforce enterprise policy.

The right pattern is not prompt engineering versus validation. It is prompt engineering plus deterministic validation.

A Safer Architecture for Enterprise Text-to-SQL

A safer enterprise architecture keeps the LLM away from direct database execution.

User question
  ↓
Application context
  - user identity
  - role / group
  - tenant / region
  - allowed datasets
  - purpose of access
  ↓
LLM generates candidate SQL
  ↓
SQL Guard
  - parse SQL
  - detect statement type and dialect
  - bind tables and columns to catalog
  - validate schema objects
  - check permissions and data policies
  - detect sensitive fields
  - estimate query risk and cost
  - produce lineage and audit evidence
  - return allow / deny / warn / repair suggestion
  ↓
Application decision
  - execute
  - ask for approval
  - ask the model to repair
  - ask the user for clarification
  - deny
  ↓
Database or warehouse

In this design, the LLM is a query-generation assistant. It is not the authority that decides whether SQL should run.

What the SQL Guard Should Check

An enterprise SQL Guard should check more than syntax. At minimum, it should evaluate:

SQL validity and dialect

The SQL should be valid for the target system: Snowflake, BigQuery, PostgreSQL, Oracle, SQL Server, Teradata, Spark SQL, or another dialect. Dialect matters because functions, date syntax, identifiers, DDL, procedural blocks, and permissions often differ.

Statement type

The guard should classify whether the query is read-only, data-modifying, DDL, administrative, procedural, or mixed. Many teams will allow only controlled read-only statements for self-service analytics.

Catalog binding

The guard should bind table and column references to the real catalog. This helps detect hallucinated fields, ambiguous columns, wrong schemas, and references that are valid SQL but invalid for the target environment.

User permissions

The guard should evaluate whether the current user can access the referenced tables, columns, rows, or derived outputs. This may include application-level policies that are not fully represented in database grants.

Sensitive data

The guard should detect whether the query reads PII, financial data, credentials, health data, or other sensitive fields. It should also consider aliases, expressions, joins, and derived columns.

Query risk and cost

The guard should identify high-risk patterns such as SELECT *, missing LIMIT, missing partition filters, large joins, cross joins, broad date ranges, and queries that may require approval.

Lineage and audit

For governance, the system should be able to explain which source columns contribute to the output. This is especially important when sensitive fields are transformed, masked, aggregated, or joined into derived results.

Example: Direct Execution vs Guarded Execution

Suppose a user asks:

Give me a list of customers with high refund rates and their contact details.

The LLM generates:

SELECT
  c.customer_id,
  c.name,
  c.email,
  c.phone,
  COUNT(r.refund_id) * 1.0 / COUNT(o.order_id) AS refund_rate
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
LEFT JOIN refunds r ON o.order_id = r.order_id
GROUP BY c.customer_id, c.name, c.email, c.phone
ORDER BY refund_rate DESC
LIMIT 100;

A direct execution path may run this query if the database account has access.

A guarded execution path may return structured feedback:

{
  "decision": "warn",
  "risk_level": "medium",
  "statement_type": "select",
  "tables": ["customers", "orders", "refunds"],
  "sensitive_columns": ["customers.email", "customers.phone"],
  "policy_violations": ["CONTACT_FIELD_ACCESS_REQUIRES_APPROVAL"],
  "repair_hint": "Remove email and phone, or request approval for contact fields. Keep customer_id, name, and refund_rate."
}

The application can then ask the model to repair the query:

SELECT
  c.customer_id,
  c.name,
  COUNT(r.refund_id) * 1.0 / COUNT(o.order_id) AS refund_rate
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
LEFT JOIN refunds r ON o.order_id = r.order_id
GROUP BY c.customer_id, c.name
ORDER BY refund_rate DESC
LIMIT 100;

This is the important shift: the model can still help users move quickly, but execution is governed by deterministic checks.

Where SQL Parsing and Lineage Fit

A SQL Guard needs SQL understanding. Simple regular expressions are not enough for enterprise SQL, especially when queries include nested subqueries, CTEs, stored procedures, vendor-specific syntax, aliases, window functions, or complex joins.

SQL parsing is the first step. It identifies the structure of the query. But enterprise governance usually needs more:

• name binding to resolve which table or column each identifier refers to;
• catalog-aware validation to confirm objects exist and are allowed;
• column-level lineage to understand sensitive source fields behind derived outputs;
• policy evaluation based on user, role, tenant, environment, and purpose;
• structured output that applications and LLMs can use for repair.

In the Gudu portfolio, these SQL analysis capabilities can be used in different ways:

• General SQL Parser (GSP) is an embeddable SQL analysis engine for parsing, semantic resolution, and column-level lineage extraction across many SQL dialects.
• Gudu SQLFlow operationalizes lineage with APIs, visualization, widgets, batch processing, and enterprise deployment.
• Gudu SQL Omni brings SQL lineage inspection into VS Code for local IDE workflows.

For AI data access, the practical question is: can your application understand generated SQL deeply enough to decide whether it should run?

Enterprise Checklist Before Allowing LLM-Generated SQL

Before putting Text-to-SQL into production, ask whether your system can:

• classify SQL statement type before execution;
• block or require approval for non-read-only statements;
• validate generated SQL against the real database dialect;
• bind every table and column to the current catalog;
• detect hallucinated tables and columns;
• apply user-specific table, row, and field permissions;
• identify sensitive fields through aliases, expressions, joins, and derived outputs;
• detect broad scans, missing limits, missing partition filters, and high-cost joins;
• produce allow / deny / warn / require approval decisions;
• return structured repair hints to the model;
• preserve an audit log for every generated query and decision;
• integrate with existing catalogs, identity systems, and governance workflows.

If the answer is no, the system is not ready for direct SQL execution.

Common Questions

Can we let the LLM execute SQL if the database user has read-only permissions?

Read-only permissions reduce risk, but they are not enough. A read-only query can still expose sensitive fields, scan too much data, bypass application-level policy, or produce misleading results from wrong joins and hallucinated schema objects.

Is this only a security problem?

No. Security is part of it, but the broader problem is governed execution. The system needs correctness, permissions, sensitive data detection, cost control, repair feedback, and auditability.

Can database permissions solve this by themselves?

Database permissions should still be enforced. However, Text-to-SQL systems often need additional context: the user’s business role, tenant, purpose of access, workflow state, approval requirements, and application-level policies. A SQL Guard can apply those checks before the database runs the query.

Should the SQL Guard block every risky query?

Not always. Some queries should be denied, some should require approval, some should be rewritten, and some should be allowed with warnings. The decision should depend on the user, data, query pattern, environment, and policy.

Does this make the user experience slower?

It can add a validation step, but it can also improve the experience by returning specific repair hints instead of generic database errors. The user gets safer answers, and the application can automatically ask the model to generate a corrected query.

Quick Reference

Conclusion

LLMs are useful for generating SQL, but they should not be the final authority on SQL execution. Enterprise data access needs deterministic checks that a model cannot reliably provide on its own.

The safer pattern is to let the LLM propose SQL, then validate that SQL before it reaches the database. A practical SQL Guard checks syntax, dialect, catalog binding, permissions, sensitive fields, query risk, lineage, repair options, and audit evidence.

This does not make Text-to-SQL less useful. It makes Text-to-SQL more deployable.

Next Step

If your team is building ChatBI, Text-to-SQL, or an AI data agent, start by testing the kinds of SQL your system already generates:

• Does the query reference real tables and columns?
• Does it touch sensitive fields?
• Is it read-only?
• Does it include reasonable filters and limits?
• Can your application explain why the query should be allowed, denied, or repaired?

You can test SQL Guard-style validation with your own SQL by pasting an LLM-generated query into the DPRiver SQL tool: Test an LLM-generated SQL query.

DPRiver / Gudu can also help evaluate SQL semantic validation, column-level lineage, and SQL Guard architecture for your environment.