DEV Community: 白海洋

Field-Level Permission Checks in Text-to-SQL Systems

白海洋 — Thu, 04 Jun 2026 14:41:27 +0000

Recently, many teams have been working on Text-to-SQL, ChatBI, or data analysis agents. One often underestimated issue is that generating SQL is only the first step—deterministic semantic, permission, and audit checks must also be conducted before deployment.

This article focuses on the issue of field-level permissions in Text-to-SQL: why table-level permissions are insufficient, and why checks are needed for sensitive fields, derived fields, filtering, and aggregation.

Core Points:

Table-level permissions are often too coarse for AI-generated SQL.
Sensitive fields can appear in projections, filters, joins, aggregations, and derived results.
Catalog-aware binding and lineage can help enforce field-level policy decisions.
Original Link: https://www.dpriver.com/blog/field-level-permission-checks-for-text-to-sql-systems/?utm_source=dev&utm_medium=community&utm_campaign=ai_sql_governance_external_2026q2&utm_content=shenhuan_dev_field_level_permission_checks_for_text_to_sql_systems

How to Assess the Governance Readiness of LLM-Generated SQL

白海洋 — Thu, 04 Jun 2026 14:38:49 +0000

This article discusses a readiness checklist for teams preparing to move LLM-generated SQL from experimentation to production, assessing whether governance capabilities are in place.

Key Points:

Governance readiness encompasses not only SQL generation quality but also validation, permission checks, lineage, and auditability.
LLM-generated SQL should be tested within the context of real catalogs and policy frameworks.
The article provides a checklist suitable for architecture reviews and pre-deployment inspections.
Original Link: https://www.dpriver.com/blog/how-to-evaluate-sql-governance-readiness-for-llm-generated-queries/?utm_source=dev&utm_medium=community&utm_campaign=ai_sql_governance_external_2026q2&utm_content=shenhuan_dev_how_to_evaluate_sql_governance_readiness_for_llm_generated_queries

LLM SQL Guard Architecture: Parser, Catalog, Policy Engine, Audit Log

白海洋 — Wed, 03 Jun 2026 15:51:40 +0000

Recently, many teams are working on Text-to-SQL, ChatBI, or data analysis Agents. A problem that is easily underestimated is: generating SQL is only the first step; deterministic semantic, permission, and audit checks are still needed before deployment.

This article discusses: a technical blueprint for architecture review and POC: explaining how an SQL Guard is composed of parser, catalog binding, policy engine, risk scoring, and audit log.

Key Points:

SQL Guard is not just syntax checking; it also requires catalog binding and policy context.
The policy engine should output auditable decisions such as allow, warn, deny, or approval_required.
Audit log enables retrospective review of governance decisions in Text-to-SQL.
Original Link: https://www.dpriver.com/blog/llm-sql-guard-architecture-parser-catalog-policy-engine-audit-log/?utm_source=dev&utm_medium=community&utm_campaign=ai_sql_governance_external_2026q2&utm_content=shenhuan_dev_llm_sql_guard_architecture_parser_catalog_policy_engine_audit_log

SQL Semantic Validation for LLM-Generated Queries

白海洋 — Wed, 03 Jun 2026 15:46:12 +0000

Recently, many teams are working on Text-to-SQL, ChatBI, or data analysis agents. An often underestimated issue is that SQL generated by LLMs should not be directly executed on production databases.

This article discusses a technical topic: explaining why syntactically correct SQL still requires catalog binding, name resolution, and semantic checks.

Key points:

Syntactic correctness does not guarantee semantic correctness.
Real catalog metadata is needed to resolve tables, columns, aliases, scopes, functions, and types.
This serves as a key technical bridge from SQL parsing to SQL semantic governance.
Original link: https://www.dpriver.com/blog/sql-semantic-validation-for-llm-generated-queries/?utm_source=dev&utm_medium=community&utm_campaign=ai_sql_governance_external_2026q2&utm_content=shenhuan_dev_sql_semantic_validation_for_llm_generated_queries

Prompt Engineering Cannot Truly Secure LLM-Generated SQL

白海洋 — Sun, 24 May 2026 13:53:01 +0000

Recently, many teams are working on Text-to-SQL, ChatBI, or data analysis Agents. One underestimated issue is that SQL generated by LLMs should not directly enter production databases.
This article discusses: addressing the common misconception that "prompt rules can control generated SQL," and explaining why pre-execution validation is still necessary.
Key points:
Prompts can guide the model, but cannot enforce database security.
Generated SQL requires deterministic pre-execution validation.
The correct pattern is prompt guidance + parser/catalog/policy/audit checks.
Original link: https://www.dpriver.com/blog/prompt-engineering-cannot-secure-llm-generated-sql/?utm_source=dev&utm_medium=community&utm_campaign=ai_sql_governance_external_2026q2&utm_content=shenhuan_dev_prompt_engineering_cannot_secure_llm_generated_sql

10 Security Risks of Text-to-SQL Before Going to Production

白海洋 — Sun, 24 May 2026 13:52:06 +0000

Recently, many teams are working on Text-to-SQL, ChatBI, or data analysis Agents. One underestimated issue is that SQL generated by LLMs should not directly enter production databases.
This article discusses: for teams currently launching Text-to-SQL, ChatBI, or database Agents, here are 10 categories of risks that must be checked before going live.
Key points:
Text-to-SQL security is not just about SQL injection.
It also requires checking permissions, sensitive fields, high-cost queries, semantic errors, and auditing.
This article serves as a pre-launch readiness checklist.
Original link: https://www.dpriver.com/blog/text-to-sql-security-10-risks-before-production-deployment/?utm_source=dev&utm_medium=community&utm_campaign=ai_sql_governance_external_2026q2&utm_content=shenhuan_dev_text_to_sql_security_10_risks_before_production_deployment

Why Enterprises Should Not Let LLMs Execute SQL Directly?

白海洋 — Sun, 24 May 2026 13:04:56 +0000

Recently, many teams are working on Text-to-SQL, ChatBI, or data analysis Agents. One underestimated issue is that SQL generated by LLMs should not directly enter production databases.
This article discusses: a risk explanation for managers and architecture leaders: there must be a validation layer between LLMs and production databases.
Key points:
Allowing LLMs to execute SQL directly brings security, permission, cost, and audit risks.
Prompts are not enforcement mechanisms.
A deterministic SQL validation layer can transform generative SQL into a controllable process.
Original link: https://www.dpriver.com/blog/why-enterprises-should-not-let-llms-execute-sql-directly/?utm_source=dev&utm_medium=community&utm_campaign=ai_sql_governance_external_2026q2&utm_content=shenhuan_dev_why_enterprises_should_not_let_llms_execute_sql_directly

What is an LLM SQL Guard?

白海洋 — Sun, 24 May 2026 13:02:23 +0000

Recently, many teams are working on Text-to-SQL, ChatBI, or data analysis Agents. One underestimated issue is that SQL generated by LLMs should not directly enter production databases.
This article discusses: explaining LLM SQL Guard with clear definitions: why Text-to-SQL cannot rely solely on model generation, and why deterministic SQL checks are mandatory before execution.
Key points:
LLM-generated SQL may be syntactically correct but semantically incorrect or unsafe.
SQL Guard performs deterministic checks before execution by combining parser, catalog, policy, risk, and audit.
Suitable as an introductory article for AI data governance, ChatBI, and Text-to-SQL teams.
Original link: https://www.dpriver.com/blog/what-is-an-llm-sql-guard/?utm_source=dev&utm_medium=community&utm_campaign=ai_sql_governance_external_2026q2&utm_content=shenhuan_dev_what_is_an_llm_sql_guard