别把判定模型当成最后一道闸

判定模型被推进 agent 流水线，常常当成闸门：看一眼下一步工具调用，再在允许和拒绝里打分。选项集是调用方写的，模型不吐新词，看起来比会聊天的大模型更听话。南加州大学一组作者在 2026-10-08 的论文 2610.12292 里说，这道闸门只要改选项名就会开。仓库在 GitHub 的 ArminAzizi98/option-channel-attack，MIT 许可，本轮看到 0 星、4 次提交。这些数字是论文和仓库页口径，不是本轮复现。

闸门看起来很干净

他们测了七个开源权重，把判定模型放在 agent 过滤器位置：检查建议的工具使用或一条入站说明，再允许或拒绝。提示注入、越狱和有害内容这几类筛查，允许或拦截的准确率落在 36% 到 72%，对照随机基线 50%。一边错得少，往往只说明模型的默认脾气：有的几乎全放，有的几乎全拦。安全漏洞写成不该过的步骤被放行，误拦只算多出来的人工。

页面点名的开源权重包括 Qwen2.5-7B，以及标成 laya-td、von、rlcd 的变体。完整分表以仓库缓存输出为准。作者把两类错拆开写，就是怕读者只看一个准确率，把总闸和总拒绝当成同一种本事。站点刚写过微软那只云端判定模型，那边谈的是延迟和报价；这篇谈的是同一类接口被当成守门员时，通道名本身会不会漏风。

六行日志，名字一换就开

在虚构的工具调用例子里，六行普通服务器日志、正文完全不提那条规则，就能把原本拦得住的过滤器误放行从 0% 抬到 63%。定义和输入都不动，只把允许项的名字换掉，四家会把标签写进提示的模型，误放行升到 93% 到 100%。仓库 README 还写了随机标签 89%，以及 1410 条被翻过来的样本上置信度间隔大约仍是 0.15。作者的判断是：这是接口层的通道，不是某一家权重的怪癖。

所有列出来的对策都没站住。要么对手打它的内部机制，要么文本本来就由对手提供。只把最不确定的样本上交给人也不行：攻击翻了结果，置信度却不怎么动。把策略字段收成类型值，能堵住一种打法，模型本身也没必要了，因为对这些值做确定性检查，六条规则都能到 100%。论文的收束很干：这类模型也许能少送一些给人工，但不该当最后一道闸。

复现入口写成 pip install -r requirements.txt，再用 PYTHONPATH 指到 src 重跑表。本轮没有重训那七个权重，也没有把攻击接到站上已有的判定接口文里做联调。数字以 10-08 论文和仓库页为准。若你已经在用固定选项集拦 agent，先看选项名会不会进提示，再决定要不要另加一层不读标签的检查。