基于策略的条件约束解码实现文本到SQL中的列级访问控制

# 策略条件约束解码用于文本到SQL中的列级访问控制
来源：https://arxiv.org/html/2607.12341
###### 摘要

文本到SQL技术正越来越多地跨越数据提供方和用户之间的信任边界进行部署。这种部署必须平衡三个相互冲突的需求：策略合规性、答案覆盖率和成本可控性。现有方法通常根据查询引用了哪些列来决定是否拒绝，并以随机方式强制执行。然而，一条查询是否合规，不仅取决于哪些列出现，还取决于它们如何被使用，而随机强制执行无法确定性地消除违规。我们将这一需求形式化为一个关于语义用途的列使用策略：输出、过滤条件和聚合参数。我们通过将每种角色与解码器跟踪的语法产生式对齐来整合该策略。由此产生的系统PCC-SQL，应用了一个逐token的logits掩码，能够在单次解码过程中确定性地消除所支持的SQL片段上的单查询列使用违规。在三个基准和三个开源模型上，PCC-SQL在Spider-CU上实现了0%的泄露率和高达88.7%的覆盖率，同时token消耗量仅比直接提示多出+10%。我们另外通过执行准确率来评估语义对齐情况。

## 1 引言

图1：当salary为AggregateOnly时，将其直接放在SELECT中（上图）违反策略，而仅将其作为AVG()的参数（下图）则合规。因此，同一个NL请求既存在违规的SQL形式，也存在合规的SQL形式；只有列的角色能区分它们。

用自然语言查询数据库是NLP领域几十年来追求的目标（Androutsopoulos et al., 1995）。最近的LLM使这一目标触手可及：文本到SQL已从研究基准转向实际部署（Yu et al., 2018; Li et al., 2023; Hong et al., 2025）。与此同时，LLM越来越多地充当外部系统的自然语言接口（Yao et al., 2023; Schick et al., 2023; Patil et al., 2024）。这些趋势共同将文本到SQL带入了数据提供方和发出查询的用户位于信任边界两侧的场景中，包括SaaS运营分析、企业数据门户，以及医疗、金融和政府数据的分析支持。在此类场景中，生成的SQL不仅要响应用户的请求，还必须满足数据提供方指定的披露策略。

要在这种场景下部署文本到SQL，必须同时满足三个要求。首先，生成的SQL不得违反策略。其次，只要用户的请求允许存在策略合规的SQL，系统就应该生成一个这样的SQL，而不是拒绝，从而保持对可接受请求的高覆盖率。第三，响应延迟和计算成本必须足够低，以支持持续的在线服务。这三个要求相互冲突：更严格的拒绝会降低覆盖率，而扩大允许响应的集合则需要额外的违规检查或重新生成步骤，从而增加计算成本。事后修复被锁定在这种权衡之中，因为每次验证调用或重试都需要为减少违规而付出额外的token成本；因此，要同时满足这三个要求，就需要一种在设计上能在生成时而非事后防止违规的方案。

策略合规的文本到SQL是可信部署的一个关键问题，已有多种方法被提出（Klisura et al., 2026; Abedini et al., 2025; Liu et al., 2026）。尽管这些方法代表了重要进展，但在满足所有三个要求的道路上仍然存在两个差距：策略如何表述，以及合规如何实现。首先，策略词汇表的粒度停留在列提及层面（列是否出现在查询中），尚未区分列在SQL中扮演的角色。因此，当同一列提及根据其角色可能产生违规或合规两种形式（图1）时，策略被迫在拒绝该列（降低覆盖率）和允许该列（允许泄露）之间做出二元选择。其次，现有方法通过训练时对齐或输入侧预处理来寻求合规，这无法确定性地消除未见输入上的违规。将残余泄露降至零需要事后验证和重新生成，这会增加token成本，与低成本要求相矛盾。因此，要打破这种权衡，需要同时扩展策略词汇表和合规机制。

我们通过两项互补的贡献来弥补这两个差距。在策略方面，我们引入了一种基于角色的列使用策略。在解码方面，我们提出了PCC-SQL（策略条件约束SQL生成），一种在单次解码过程中应用该策略的约束解码器。列使用策略为每列分配四种角色之一：Public（可作为输出列出现）、Hidden（不得在任何SQL上下文中出现）、ConditionOnly（仅限条件子句）、AggregateOnly（仅限聚合参数）。这将商业数据库中使用的列级访问控制（如Snowflake的投影策略）扩展到取决于列在查询中角色的粒度。由此产生的按角色划分的粒度保留了基于提及的策略无法捕获的合规形式路径，从而维持了覆盖率。PCC-SQL将尊重语法的约束解码扩展到了策略合规。在每个解码步骤，它跟踪当前SQL语法位置所暗示的角色上下文，并使用logits掩码排除该角色下不被允许的列，使其不出现在下一个token候选中。该机制在单次解码过程中完成，无需事后验证或重新生成，确定性地消除了查询内的违规，同时保持了较低的token成本。这两个贡献共同在单次解码过程中满足了所有三个要求。

#### 贡献。

- • 列使用策略：形式化为四种权限类型和四种角色，并标注了Spider-CU和BIRD-CU数据集。
- • PCC-SQL：一种约束解码器，在单次解码过程中确定性地消除我们所考虑的SQL片段上的单查询列使用策略违规。
- • 评估：在Spider-CU、BIRD-CU和Spider-ACL三个基准上，使用三个开源模型，与四种基线（涵盖提示、重新生成、事后验证（Klisura et al., 2026）和步骤级回滚）进行比较：在token消耗量仅比直接提示多+10%的情况下，实现0%的泄露率，Spider-CU上覆盖率高达88.7%。111代码和基准将在录用后于GitHub发布。

## 2 相关工作

### 2.1 文本到SQL安全性与策略合规

#### 攻击与泄露检测。

近年来，文本到SQL安全性研究迅速扩展（Hong et al., 2025），研究重点包括识别攻击面，例如从输出SQL推断模式（Klisura and Rios, 2025）、检测恶意提示和SQL（Song et al., 2024b），以及通过训练数据投毒进行后门攻击（Lin et al., 2025）。SecureSQL（Song et al., 2024a）提供了一个基准，系统性地评估了基于LLM的数据库自然语言接口（NLIDB）中的敏感数据泄露。

这些研究在策略违规SQL生成之后对其进行表征、检测或基准评估。仅靠检测无法阻止违规SQL的产生，从而将部署任务留给下游进行过滤或重新生成，这需要额外的LLM调用成本。

#### 隐私保护生成。

与事后检测策略违规不同，有几种方法旨在生成时实现合规SQL：基于角色访问控制策略进行拒绝（Klisura et al., 2026）、在将敏感token发送给外部LLM之前进行抽象（Abedini et al., 2025），以及结合安全感知数据合成与迭代偏好优化的安全对齐（Liu et al., 2026）。其中，Klisura et al.（2026）与本文最接近，针对单查询的列级访问（用作我们的外部基准Spider-ACL）；SafeNLIDB通过ShieldSQL基准针对多查询推理攻击。他们的策略词汇表仅限于每列的二元可见性或行过滤，无法区分同一列是作为输出、条件还是聚合参数出现；合规也依赖于随机的训练时对齐或生成后抽象。

### 2.2 数据库访问控制

数据库研究长期以来一直关注上下文相关的访问控制和聚合结果的受控发布。例如，基于目的的细粒度访问控制（Xue et al., 2020）、数据库系统中的动态信息流控制（Guarnieri et al., 2019），以及差分隐私下的聚合结果发布（Johnson et al., 2018）。

这些设计主要在数据库执行层或中间件层运行。为了在生成阶段（LLM从自然语言组合SQL时）实施等效的控制，必须将策略词汇表和防止违规的机制都迁移到模型端。

### 2.3 约束/结构化生成

约束解码通过干预每步token分布，使输出满足给定约束。许多先前研究专注于通过排除违反约束的token来确保语法或模式有效性，包括SQL语法约束（Scholak et al., 2021）、结构化输出格式如JSON或Python（Dong et al., 2025; Ugare et al., 2025b），以及语言级查询语法（Zheng et al., 2024）。相比之下，IterGen（Ugare et al., 2025a）在符号级别交替生成和验证，并在失败时回滚，而RAIN（Li et al., 2024）则通过自我评估和回滚进行解码时对齐。两者都依赖于生成后验证。

这些方法主要用于语法有效性或通用对齐，将它们应用于解码时的安全约束（如策略违规）仅被有限地报道过。研究还观察到，硬约束可能对生成分布产生副作用（输出质量偏差与约束相关）（Banerjee et al., 2025）。

## 3 预备知识

本节将列使用策略合规形式化为基于列的策略π和其在SQL中的使用角色ρ的决策。

四种使用角色ρ对应于语法位置。Sel标记SELECT/GROUP BY/ORDER BY中的投影，Join标记JOIN ... ON内的谓词，Where标记WHERE/HAVING（排除聚合）内的谓词，Agg标记集合聚合函数COUNT、SUM和AVG的参数。四种列策略π为Public、ConditionOnly、AggregateOnly和Hidden，权限关系perm(π, ρ)定义于表1。

表1：权限关系perm(π, ρ)。行为列策略π，列为使用角色ρ。✓表示允许，—表示禁止。

| π \ ρ | Sel | Where | Agg | Join |
|--------|-----|-------|-----|------|
| Public | ✓ | ✓ | ✓ | ✓ |
| ConditionOnly | — | ✓ | — | ✓ |
| AggregateOnly | — | — | ✓ | — |
| Hidden | — | — | — | — |

对于策略分配P: Col → Policy，查询q的安全性定义为safe(q, P) ⇔ ∀(c, ρ) ∈ cols(q), perm(P(c), ρ) = ⊤，其中cols(q)收集q中带有角色标记的列出现。在本文考虑的SQL片段上（在局限性一节中指定），角色由语法位置唯一确定，从而将角色分配简化为在生成过程中跟踪SQL前缀。

## 4 方法：PCC-SQL

图2：架构和一个token级掩码步骤。上：状态跟踪器从部分SQL推导出角色ρ，Logits处理器将被禁止列的logits设为-∞。下：在WHERE内（ρ = Where）的列槽位上，违反策略的列（users.email, orders.amount）被掩码，因此下一个token仅从允许的列（users.area, orders.status）中采样。

PCC-SQL（策略条件约束SQL生成）是一种约束解码器，能够在单次解码过程中输出策略合规的SQL。该方法基于SQL的一个关键属性：在任何列名位置，角色仅由前缀决定。例如，SELECT子句中的列具有角色Sel，而JOIN ... ON中的列具有Join。PCC-SQL包含两个组件。（1）状态跟踪器从语法位置维护当前角色。（2）Logits处理器在列名位置将每列的策略与角色进行比较，并仅保留允许的列作为下一个token候选。解码器仅生成Logits处理器允许的token。图2展示了架构和一个单步示例。

### 4.1 角色与语法的对应关系

状态跟踪器在生成过程中维护一个小的SQL语法状态集，例如当前子句和聚合嵌套状态。在每个列名位置，它使用此状态分配一个角色（Sel/Join/Where/Agg），这随后驱动第4.2节描述的掩码操作。

### 4.2 掩码构建与拒绝路径

在每个列名位置，给定状态跟踪器产生的范围（当前子查询级别的表范围）和当前角色ρ，我们计算允许的列集：

Allowed = { c ∈ Scope | perm(P(c), ρ) = ⊤ }

Logits处理器将列名token的logits