[控场AI]
· 4 分钟阅读· 2,294 字

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

一次基准测试暴露的访问控制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解析器验证零未授权数据读取。作者同时承认模型代际差异和评估维度局限,并强调外部基准测试在两天内找到了自建测试从未覆盖的边界条件。

schemagate基准测试结果

当大模型生成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回答了禁止的问题读取了未授权数据
schemagate0.9841.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仓库中公开。

#访问控制#LLM SQL生成#Spider-ACL#基准测试#RBAC#schemagate#数据库安全
分享:

相关推荐