EACL 2026 Findings · RBAC · Text-to-SQL · Safe Refusal

Role-Conditioned Refusals：LLM 能守住智能问数的角色权限吗？

这篇论文不是在问模型会不会写 SQL，而是在问：同一个问题由不同角色提出时，模型能否该答就答、该拒绝就拒绝。

正式来源：EACL 2026 Findings数据：Spider-ACL / BIRD-ACL核心：Prompt vs Verifier vs LoRA原文 PDF 已保存

先说结论：LLM 可以参与权限判断，但不能独自当门卫

论文把同一个问数问题交给不同角色，要求模型在有权限时生成 SQL、没权限时明确拒绝。结果表明：让一个模型同时“理解问题、生成 SQL、判断权限”不够稳定；先生成候选 SQL，再单独核验 SQL 触碰了哪些表和字段，通常更可靠。

做了什么

给 Spider / BIRD 加上真实风格的 RBAC

每个数据库增加 4 个逐级收紧的角色，并在表级、列级设置可见范围，形成带 PERMIT / DENY 标签的 Text-to-SQL 权限数据集。

怎么做

比较 3 种权限执行方式

直接提示、SQL 生成器 + 权限核验器、LoRA 权限感知微调。它们分别代表“靠提示”“靠独立检查”“把规则学进模型”。

最重要发现

显式核验优于一口气完成

两阶段方法在复杂、部分越权的查询上改善最大；但策略越长，所有方法都会明显退化，说明 LLM 的策略推理远未达到确定性系统的可靠度。

一句话理解：模型可以帮你判断“这条 SQL 是否看了不该看的字段”，但最终放行仍应由确定性的策略引擎和数据库权限完成。

先看一个直观例子

医生问：下载患者 10293 的记录

医生角色拥有患者记录权限，系统应该生成并执行 SQL。

PERMIT → SQL → 执行

行政人员问同一句话

问题本身完全相同，但角色没有该权限，系统应该停止，不生成可执行结果。

DENY → Access Denied

同一请求在不同角色下被允许或拒绝 — 论文图 1：授权与否取决于“用户角色 + 查询所需数据”，而不是只看问题文本。

数据集是怎么造出来的

迁移数据库

把 Spider、BIRD 的 SQLite schema 转为 PostgreSQL，为真实 RBAC 策略提供执行环境。

定义 4 个角色

Role 1 全量可读；Role 2 只读部分表；Role 3 可读全部表但只能看部分列；Role 4 仅有最小可见范围。

重新标注问题

确定性策略引擎检查标准 SQL 依赖的表、列是否都在角色许可集合中。

产生角色化样本

同一问题在不同角色下可能得到不同标签，最终得到 Spider-ACL 与 BIRD-ACL。

数据集	数据库	角色实例	角色化查询	特点
Spider-ACL	153	612	19.6k	跨领域、结构相对规整
BIRD-ACL	80	320	35.8k	schema 更大，策略更长、更接近企业场景

数据构造与三种模型设置 — 论文图 2：左边是 RBAC 数据集构造，右边是三种实验设置。这个图基本概括了整篇论文。

三种做法分别是什么

Setting 1

直接决策

输入问题、schema、用户角色和策略；同一个 LLM 先判断权限，有权就输出 SQL，无权就输出 Access Denied。

优点：链路短。
弱点：生成与授权混在一起，容易漏看某个受限字段。

Setting 2

生成器 + 核验器

LLM-A 只负责生成 SQL；LLM-B 解析 SQL 所涉及的表、列，再与用户策略比较，决定放行或拒绝。

优点：职责分离，容易审计。
弱点：仍然让 LLM-B 做策略推理，不能替代确定性校验。

Setting 3

权限感知微调

用带角色和 PERMIT / DENY 标签的数据对 LLaMA、Mistral 做 LoRA 微调，让模型直接学会权限边界。

优点：单模型推理。
弱点：跨数据库和跨策略分布泛化明显下降。

论文的形式化定义

设角色允许访问的表为 $$T_u$$ ，表 $$t$$ 上允许访问的列为 $$C_u(t)$$ 。候选 SQL $$y$$ 只有在所有引用表和列都落在许可集合内时才合规：

$$ \operatorname{tab}(y) \subseteq T_u \quad\land\quad \forall t\in\operatorname{tab}(y):\operatorname{col}(y,t)\subseteq C_u(t) $$

通俗讲：SQL 里只要有一个表或字段越界，就必须拒绝。真正工程实现时，这一步最好用 SQL AST + 策略引擎完成，而不是靠自然语言猜。

实验结果怎么看

论文把“应该拒绝的请求”当作正类。Precision 高表示拒绝时更少误杀，Recall 高表示更少漏放越权请求，F1 是二者折中。安全场景还要特别盯住 leakage，也就是本该拒绝却放行的比例。

比较口径：Setting 1/2 是基础模型的 zero-shot 或 few-shot prompting；Setting 3 是在 Spider 权限数据上做 LoRA 微调。它们训练条件不同，因此下面分表展示，不能把 0.933 与 zero-shot 数字简单理解为同条件下的直接胜负。

Setting 1 vs Setting 2：Spider 完整拒绝指标

模型	提示方式	Setting 1：直接决策			Setting 2：生成 + 核验
模型	提示方式	P	R	F1	P	R	F1
GPT-4o-mini	Zero-shot	0.912	0.708	0.797	0.893	0.862	0.877
GPT-4o-mini	Few-shot	0.836	0.828	0.832	0.703	0.864	0.775
DeepSeek-R1	Zero-shot	0.759	0.919	0.832	0.898	0.868	0.883
DeepSeek-R1	Few-shot	0.941	0.579	0.717	0.850	0.678	0.754
LLaMA 3.1	Zero-shot	0.935	0.577	0.713	0.866	0.876	0.871
LLaMA 3.1	Few-shot	0.996	0.568	0.724	0.876	0.627	0.731
Mistral-7B	Zero-shot	0.642	0.561	0.599	0.909	0.842	0.874
Mistral-7B	Few-shot	0.225	0.597	0.327	0.695	0.740	0.717

Setting 1 vs Setting 2：BIRD 完整拒绝指标

模型	提示方式	Setting 1：直接决策			Setting 2：生成 + 核验
模型	提示方式	P	R	F1	P	R	F1
GPT-4o-mini	Zero-shot	0.649	0.762	0.701	0.775	0.947	0.852
GPT-4o-mini	Few-shot	0.842	0.726	0.780	0.855	0.623	0.720
DeepSeek-R1	Zero-shot	0.636	0.936	0.757	0.773	0.948	0.851
DeepSeek-R1	Few-shot	0.520	0.846	0.644	0.679	0.733	0.705
LLaMA 3.1	Zero-shot	0.511	0.830	0.633	0.766	0.927	0.839
LLaMA 3.1	Few-shot	0.530	0.830	0.647	0.698	0.845	0.764
Mistral-7B	Zero-shot	0.502	0.613	0.552	0.769	0.869	0.816
Mistral-7B	Few-shot	0.492	0.445	0.467	0.863	0.597	0.705

读表结论：Setting 2 的 zero-shot 在所有四个模型、两个数据集上都提高 F1；few-shot 并不稳定，有时反而降低 recall，说明示例提示可能让模型过度依赖示例模式。

Setting 3：LoRA 权限感知微调

模型	Spider → Spider			Spider → BIRD
模型	P	R	F1	P	R	F1
LLaMA 3.1	0.839	0.922	0.878	0.566	0.754	0.646
Mistral-7B	0.936	0.929	0.933	0.562	0.807	0.663

这里最容易误读：两种模型都只在 Spider 权限数据上微调。Spider 内部测试很强，但迁移到 BIRD 后 F1 降至 0.646/0.663，说明它学到的权限行为还不能稳定跨 schema、跨策略分布泛化。

有权放行以后，SQL 本身写得对吗？

模型	提示方式	Setting 1 执行准确率	Setting 2 执行准确率	变化
GPT-4o-mini	Zero-shot	41.71%	67.60%	+25.89
GPT-4o-mini	Few-shot	60.92%	73.33%	+12.41
DeepSeek-R1	Zero-shot	57.11%	66.53%	+9.42
DeepSeek-R1	Few-shot	49.60%	56.40%	+6.80
LLaMA 3.1	Zero-shot	25.15%	33.27%	+8.12
LLaMA 3.1	Few-shot	53.13%	61.24%	+8.11
Mistral-7B	Zero-shot	8.93%	23.20%	+14.27
Mistral-7B	Few-shot	19.31%	31.13%	+11.82

这是 Spider 上的 execution accuracy，只统计被正确允许执行的查询。Setting 2 不仅更会拦截越权，也普遍提高了最终 SQL 的可执行正确率。

策略长度影响和核验器精确率召回率权衡 — 论文图 3/4：左图最关键，策略从短变长时三种方法都退化；两阶段虽然最好，也从 0.90 降到 0.69。右图说明不同 verifier 会形成不同的“严格程度”。

三种方法面对更长权限策略时的变化

策略长度	Setting 1：GPT few-shot	Setting 2：GPT→GPT zero-shot	Setting 3：微调 Mistral
短	0.81	0.90	0.77
中	0.71	0.79	0.66
长	0.63	0.69	0.55

三种方式都会随策略变长而退化。Setting 2 始终最高，但也从 0.90 降到 0.69；微调并没有消除长策略推理问题。

CoT 消融：显式推理是否有用

方法	有 CoT	无 CoT
Setting 1 GPT Few	0.832	0.743
Setting 2 GPT→GPT Zero	0.877	0.798

去掉结构化推理后，两种方法都下降约 0.08–0.09 F1，尤其容易错在部分合规查询。

Agent 仿真：提前检查权限的效率

指标	普通 Agent	权限感知 Agent
总行数	2000	2000
LLM 调用	5168	2734
浪费调用	3168	734
平均延迟	4.361s	0.543s

权限感知 Agent 先判断能否执行，减少无效 SQL 生成与最多三次重试，平均延迟约改善 8 倍。

别被总 F1 掩盖：最难的不是“完全有权”或“完全无权”，而是部分合规查询，例如 JOIN 了一个受限表、聚合了禁止读取的列，或只在 WHERE 条件里碰到敏感字段。

创新点与论文价值

把 access control 放进 Text-to-SQL 评测

过去通常假设数据库事后拦截。本文直接测模型能不能理解角色、策略和问题之间的关系。

构造表级 + 列级 RBAC 基准

同一问题按四级角色产生不同许可标签，比只有“敏感/不敏感”的简单拒答数据更接近企业问数。

比较三条工程路线

提示、独立 verifier、微调被放进同一实验框架，明确展示安全性、可用性和部署复杂度之间的取舍。

放到你的智能问数项目里，建议这样落地

1. 身份与策略

用户、角色、组织、数据分级、表列权限、行级条件。

→

2. 权限感知检索

只给 LLM 暴露当前用户可见的 schema、指标、样例值和文档。

→

3. 候选 SQL

LLM 生成 SQL，同时记录意图和所需数据对象。

→

4. 确定性执行门

SQL AST、策略引擎、数据库原生 RLS/CLS、脱敏、审计共同放行。

必须保留的底线：不要让 LLM verifier 成为最终授权源。它适合提前发现风险、解释拒绝原因和减少重试；真正的权限判定必须 fail-closed，并由可审计的策略系统再次执行。

审稿人视角：这篇论文还缺什么

角色策略是从基准数据合成的，和企业中复杂的继承、例外、动态属性、行级过滤仍有距离。
策略越长性能越差，说明让 LLM 阅读整段权限文本不具备扩展性；更现实的方案是预计算有效权限并结构化传入。
LoRA 在 Spider 上强，但跨到 BIRD 明显下降，不能据此宣称模型“学会了通用权限”。
论文重点是模型行为评测，不是完整安全架构；提示注入、侧信道、推断泄露、结果脱敏与审计仍需另行设计。

综合评价：对智能问数项目非常直接，最值得借鉴的是“生成与授权职责分离”和“按部分越权场景建立评测集”，而不是把 LLM 当成新的 IAM 系统。