一次基准测试暴露的访问控制Bug:修复后F1达0.984

schemagate在Spider-ACL基准上修复大小写正则Bug后,拒绝F1达0.984,零未授权数据读取。
schemagate是一个位于LLM与数据库之间的访问控制中间层,只向模型暴露用户被授权的表和列,并在SQL执行前检查越界。作者用Spider-ACL基准测试检验它,该基准包含19,624个问题-角色对,标签来自PostgreSQL引擎实际的GRANT执行结果而非人工标注。首轮200题试点F1仅0.83,33个错误拒绝中32个源于一个大小写敏感的正则Bug:当AS为大写时,别名被误读为第二张表。修复后全量测试拒绝F1达0.984,8,128条被回答的查询经独立SQL解析器验证零未授权数据读取。作者同时承认模型代际差异和评估维度局限,并强调外部基准测试在两天内找到了自建测试从未覆盖的边界条件。

当大模型生成SQL时,如何确保它不会越过权限边界读到不该看的数据?schemagate是一个位于LLM和数据库之间的中间层,它只向模型展示用户被授权读取的表和列,并在任何生成的SQL执行前检查查询是否触碰了其他内容。最近,作者用它跑了一遍Spider-ACL基准测试,结果在第一天就暴露了一个隐蔽的Bug——而修复后,拒绝F1分数达到了0.984。
基准测试:用Postgres的真实标签检验访问控制
Spider-ACL来自EACL 2026的一篇论文(Klisura等)。它把Spider的每个问题配上四种用户角色,并以真实的PostgreSQL GRANT形式呈现。每个问题都附有Postgres在参考查询以该角色运行时的实际回应:允许或“permission denied”。整个数据集包含19,624个问题-角色对。任务很明确:回答被允许的问题,拒绝其余问题。
这个设计的核心价值在于标签来源——不是人工标注的“应该允许/拒绝”,而是数据库引擎自身执行权限检查后的真实结果。这意味着基准测试的ground truth具有天然的权威性。
Spider基准与Spider-ACL的关系
Spider是Text-to-SQL领域最广泛使用的跨域基准测试,包含约1万条自然语言问题与对应的SQL查询,覆盖多个数据库schema。它的设计目标是评估模型将自然语言转化为正确SQL的能力,但原始Spider并不涉及访问控制——所有查询默认以全权限执行。Spider-ACL在此基础上做了关键扩展:为每个问题引入四种用户角色,并用真实的PostgreSQL GRANT语句定义每个角色对表和列的访问权限。这意味着同一个自然语言问题,在不同角色下可能对应完全不同的合法行为——有的角色应该得到答案,有的应该被拒绝。这种「同题不同权」的设计,使得访问控制决策成为独立于SQL生成质量的评估维度。
首轮测试:0.83的F1与一个正则Bug
200题的试点跑出了0.83的F1。问题出在过度拒绝——系统拒绝了本应回答的问题。
33个错误拒绝中有32个源于同一个原因,而且是作者自己的代码问题。从查询中提取表名的检查能正确处理FROM students as t1,却无法处理FROM students AS T1。一个正则表达式区分了大小写。当AS为大写时,它把T1误读为第二张表,找不到名为T1的表,于是以“此调用者不可用”为由拒绝了查询。
更关键的是,大多数生成的SQL都用大写写AS。这意味着真实用户也会撞上这个Bug。修复只需一个标志位、一个回归测试,以及一个确保测试在没有修复时会失败的检查。这个细节值得所有做LLM访问控制的人警惕:你的单元测试全部通过,不代表真实场景下的边界条件被覆盖了。
修复之后:19,624条记录的完整结果
同样的流水线,使用Claude Sonnet 5.5,跑完全部记录:
| 系统 | 拒绝F1 | 回答了禁止的问题 | 读取了未授权数据 |
|---|---|---|---|
| schemagate | 0.984 | 1.8% | 0 / 8,128 |
| 论文最佳(微调Mistral-7B) | 0.933 | 未报告 | 未报告 |
在试点从未触碰的600条记录上,F1为0.986。
最后一列的零并非盲目信任。作者用独立的SQL解析器解析了每一个被回答的查询,并将每张表和每一列与角色的GRANT进行比对,没有发现任何越界。
那1.8%是什么情况?它们是模型从被允许看到的列中回答的问题。有些没问题(参考查询取了问题从未要求的列),有些是接近正确的答案。这是剩余需要修复的部分。
拒绝F1的含义
拒绝F1是该基准测试的核心指标,它将「拒绝」视为正类,计算精确率与召回率的调和平均。精确率衡量系统拒绝的查询中有多少确实应该被拒绝,召回率衡量所有应被拒绝的查询中有多少被系统成功拦截。高拒绝F1意味着系统既不轻易放行越权查询,也不过度拒绝合法请求。0.984的F1表明系统在两类错误之间取得了很好的平衡。但需要留意,F1只评估「回答/拒绝」的二元决策,不评估被回答的查询本身是否正确——这正是作者在边界条件中明确指出的评估盲区。
诚实的边界条件
作者自己列出了几条限制,值得认真对待:
- 论文中的系统使用的是2024-25年的模型,而这次测试用的是2026年的模型,所以部分差距来自模型本身的能力提升。
- 这个分数评估的是“回答或拒绝”的决策,而非每个答案是否正确。
- 论文的BIRD部分尚未运行。
这些限制意味着0.984的分数不能简单等同于“schemagate全面超越了论文方法”。模型代际差异是一个显著的混杂因素,而答案正确性的评估维度尚未覆盖。
关键教训:用别人写的标签检验你的系统
作者自己的测试全部通过。一个由他人编写、标签来自Postgres本身的基准测试,在两天内找到了一个Bug。
这个结论对构建LLM访问控制的开发者有直接的操作意义:自建测试集容易陷入“你测的就是你想到的”这一盲区。外部基准测试的最大价值不在于分数排名,而在于它用你未曾设想的边界条件来攻击你的系统。
修复已在schemagate 1.6.1中发布,所有决策和查询结果均在GitHub仓库中公开。
相关推荐

Workbuddy零基础入门:桌面AI智能体如何落地工作流
Workbuddy桌面AI智能体零基础教程解读:从安装、积分领取到文件管理与自动化工作流搭建,对比CodeX的适用场景与成本差异,帮助职场人完成从AI提问者到AI管理者的思维转变。

OpenAI智能体新栈:计算机操作、决策API与超速工作流
OpenAI Dev Day发布智能体新栈:Computer Use操作速度超越普通人,Decisions API基于Luna实现极低延迟分类,Agents API开放同源计算机操作能力,GPT-6.1 Sol成本仅为Astra七分之一。本文梳理核心更新、实测数据与开发者落地要点。

梁文峰开源推理框架DeepInfo,硬刚美国禁令
DeepSeek在开源模型后再开源推理框架DeepInfo,包含GPU/CPU交叉流水线、小模型预判大模型复核、华为昇腾与英伟达芯片全面适配等技术,直面美国联邦禁令。本文解析其对AI产业落地的意义与开源策略。