警铃响了，闸门没收到——当AI安全监控的证据管道悄悄断线

凌晨两点，大楼十七层的茶水间冒出第一缕烟。

烟感报警器很尽职。它闻到了烟，红灯亮起，蜂鸣器在空荡的走廊里尖叫。值班室的仪表盘上，这一格清清楚楚跳成了红色。消防主机记录了一笔：某时某分，某号探测器，火警。字迹工整，时间精确，没有任何人玩忽职守。

但喷淋头没有喷水。

不是喷淋头坏了，也不是水压不足。是去年装修的时候，施工队把报警器到喷淋控制器之间的信号线挪进了另一条线槽，随后封上了吊顶。验收的人拿测试仪在报警器这头一按，红灯亮——合格。从来没有人去喷淋控制器那头看一眼。火着起来，没有一个环节"失职"：报警器报过警，喷淋头完好待命，值班日志上签过字，连消防主机都记了一笔。唯独中间那根线，断了。烧穿天花板之前，所有人都以为这栋楼固若金汤。

还有一种更现代的死法。医院病房里，老人按下呼叫铃，铃声在床头响得清脆，护士站的大屏幕却纹丝不动——呼叫信号走的是 Wi-Fi，而护士站的终端只认有线总线。老人按了一整夜。清晨交班，护理记录上写着：患者整夜安静。

检测到，和送达，是两件事。

Junchi Liao 这篇论文讲的，就是 AI 安全世界里的这根线。它不响、不闪、不报错。报警器们一排排亮着红灯，而它们守护的东西，正在另一头安静地烧。

🏢 门卫室的屏幕

先说说今天的 AI 应用长什么样。一个装了大语言模型的应用要上线，多半会在外面套一层 guardrail——护栏。这层护栏不是一句"请你做个好人"的系统提示词就完事。它在动手拦截、改写、路由之前，要读一大堆东西：请求对象、工具调用参数、流式事件、生成文件、检测器输出、验证器输入。用学术一点的话说，运行时监控器（runtime monitor）观察框架状态，并影响安全决策——阻断请求、改写输出、中断工具调用、过滤路由结果、限制自动工具执行。

关键在于：安全逻辑读的是框架递过来的"表征"，不是世界本身。

这就像小区门卫室。保安盯着一排监控屏幕，屏幕上显示什么，取决于摄像头的安装位置和物业的布线。摄像头拍到了小偷，但画面走的是一根没接到门卫室的电话线——保安这一班，等于白坐。论文里有一句话把这个依赖关系说得极干净：策略边界（policy boundary）只有在仍能看到承载策略相关状态的运行时表征时才有效。框架递什么，监控器看什么；框架改道，监控器就失明。

而框架恰恰一直在改道。请求 schema 在变，工具调用的表示在扩，多模态字段一个个冒出来，流式接口不断新增，策略适配器一轮轮重构。agent 系统（Yao et al. 2022 的 ReAct、Schick et al. 2023 的 Toolformer 一路发展下来）把这些表面统统变成了日常执行的一部分。监控器可以一直待在配置里，一直"在环"，而它依赖的那份证据——已经搬家了。

🔇 失效是沉默的

论文给这类事故起了名字：监控有效性失效（monitor-validity failure）。定义很克制，带着司法鉴定式的谨慎——取一个公开的框架修复，复现它的父版本：策略相关的金丝雀载荷缺席于监控器可见证据，或未能到达预期决策；再跑修复版：同一只金丝雀到达可见性预言机或决策预言机。两点对比，坐实一个"失效的父版 / 修复的子版"。

作者特意留了个时间性子类型——monitor-validity drift，从"能用"到"失效"再到"修复"的完整漂移——本文的 18 个案例都不建立这个时间区间。这是个老实人。有多少证据说多少话。

最瘆人的是这类失效的"沉默"属性。框架路径不必崩溃，监控器不必从配置里消失。应用正常返回，日志显示守卫跑过了，测试一片绿色。只有证据，永远没到达它该去的地方。作者的原话值得整段记住：检测器看见了证据；框架在执法之前把它丢掉了。

所以这篇论文和那些红队基准（jailbreak 评测、HarmBench、AgentDojo、AgentHarm）问的是完全不同的问题。基准问：能不能通过指定接口引出不安全行为、或者识别它？本文问：一旦证据被识别，被执行的框架路径是否把它送到策略边界？检测器再强、策略 DSL 再精巧、LLM-as-judge 再聪明，父路径不送证据，这一切全是摆设。一个强检测器无法保护一个它够不着的边界。

🚨 一只正则表达式的死讯

来看全书最锋利的那只案例，它小得可以塞进一张便利贴。

NeMo Guardrails——英伟达出品的护栏框架——有一个正则检测器。某天的一次公开修复里，人们发现：检测器返回了结构化的阳性结果，is_match=true，一切正常。但父框架仍然放行了输出。

为什么？因为那个阳性结果从未被映射到 block 决策。

翻译一下：烟感报警器尖叫了一整晚，喷淋控制器那边根本没接这根线。检测器跑了，匹配了，返回了，然后结果悬在半空，没人签收。修复版本只做了一件事——补上缺失的输出映射。同一只金丝雀，立刻被拦下。

注意这里不需要什么更强的越狱提示词，也不需要什么更聪明的正则。检测能力没有短板，短的是快递的最后一公里。论文里这类失效有个精确的分类学位置：证据已被识别（recognized），但与执法断开（disconnected from enforcement）。不是越狱，不是检测器错误，是接线事故。

这个案例是全文的图腾。后面所有理论、方法论、十八起案件，都是从这只便利贴上长出来的。

🐤 金丝雀合约：给证据路径装追踪器

可疑的补丁遍地都是，确认的事故寥寥无几。同一个补丁，可能是真修了监控漏洞，可能是删掉了一条旧边界，可能是纯加功能，也可能只是顺手重构。怎么分辨？

作者的办法叫金丝雀合约（canary contract）。金丝雀这东西，矿工下井时带一只，鸟死 = 毒气到。这里的金丝雀是一枚确定性的载荷——一个违禁工具名、一个匹配正则的 token、一段合成凭证——放在改变的表面上，看监控器能不能看见它、闸门动不动。

合约五字段，缺一不可：

• 版本对：钉死父版本与修复版本的修订号
• 边界：说明父版本为何"本应"拦截——排除新功能和被移除的策略
• 金丝雀：载荷只放在改变的表面上，不碰老表面
• 可见性预言机：监控器看见载荷了吗
• 决策预言机：预期动作触发了吗

最要紧的设计是可见性与决策必须分开。检测器可以阳性匹配而适配器放行输出——看见，不等于动手。阻断路径对聊天消息有效，而对新请求形状完全不可见——动手，也得看对谁说。两个预言机，两道门，各查各的。

作者一句话点破方法论的分量：金丝雀是证据路径的示踪剂，不是攻击提示词。测试的是"安全相关证据是否仍到达策略边界"，拼的是放置位置，不是提示词火力。金丝雀合约，说穿了就是带安全专属预言机的回归测试。普通回归测试问功能行为是否保持；这个测试问策略意图是否还连在改变的证据表面上。

🔌 断线的四种姿势

十八起确认案例，按"第一处断掉的依赖"归入四个家族。每一家族的隐性假设各不相同，金丝雀的放法也各不相同。

载荷搬家（Carrier）。被监控对象还在，策略相关载荷搬到了不同载体。教科书案例是 Invariant：策略分析器匹配到了嵌套的工具调用，可 pending-trace 元数据只挂在顶层消息上——违规被当成"非 pending"过滤掉了。违禁品就藏在抽屉的夹层里，检查员只翻桌面。金丝雀的做法：把违禁载荷只放进嵌套载体，同时检查元数据可见性和策略决策。

执法断裂（Adapter）。检测保留，执法断裂。就是前面那只 NeMo 正则：监控路径看起来活得好好的，检测器跑了、返回了结果，缺的是 detector-output-to-action 适配器——阳性结果到 block 决策之间那根线。金丝雀要强制制造一个阳性结果，断言它真的到达阻断决策。

真假李逵（Authority）。框架对同一事件暴露多个貌似合理的通道。工具调用出现在结构化元数据里，文本字段却一片祥和；公开的 agent 身份被内部的执行克隆体悄悄替换。下游策略逻辑读的，是一份看起来合法、实则权威性更低的表征。金丝雀让两个通道互相矛盾，断言监控器用的是策略边界"本意"的那个通道。

新表面（Surface）。框架新增或重排了请求、流、多模态表面。还在检查文本消息的监控器，会漏掉图像部分、Responses API 输入、实时流块——如果这些东西在安全检查之后才物化。载荷不放进遗留表面，只放新支持的表面。这类失效因此是结构性覆盖缺失，不是检测器质量缺失。

四家族 × 四生态的分布也耐人寻味：Carrier 三起 Python、两起 TypeScript；Adapter 四起 Python、一起 C#；Authority 两起 Python、两起 TypeScript；Surface 三起 Python、一起 Java。既有边界修复的九起子集里，Adapter 四起、Authority 三起、Carrier 两起，全部抵达 E1 执法边界，横跨八个项目组。家族不是框架的胎记——同一个项目可以在不同安全集成点暴露多个家族，同一家族也能出现在互不相关的框架里。

🗺️ 十八起案件的现场图

数字摆出来：18 起确认案例，11 个框架项目组，4 个实现生态（Python、TypeScript、Java、C#/.NET）。分层三条：既有边界修复（established-boundary）9 起，新表面策略覆盖缺口（new-surface）8 起，纯边界证据案例 1 起。复现强度：Tier A 17 起（框架级或模块级真跑），Tier B 1 起（隔离改变逻辑）。

按项目点名：LiteLLM 4 起——注意，是四个不同的边界：proxy guardrail 输入构造、流衍生工具证据、内存策略更新、透传生命周期 hook。Promptfoo 3 起（验证器、工具上限），NeMo Guardrails 2 起（输出映射、多模态提示物化），Semantic Kernel 2 起（终止、过滤器），单案例项目 7 起。原始标签 13 个项目，归并为 11 个项目族。

语言分布：Python 12 起，TypeScript 4 起，Java 1 起，C#/.NET 1 起。Python 占大头，这是生态现实——但六起发生在 Python 之外。换句话说，这不是某一种实现风格的毛病，是结构病。

语料的构建过程本身就是一场审判。六个确认条件一条不能少：可识别的父/修复修订；受影响表面存在有意安全合约的证据；确定性载荷只放在改变的表面；父版监控器路径被执行；父版在可见性或决策上缺失；修复版修复同一处。意图证据的来源也有账本：现有测试或 fixture 8 例，issue/PR 讨论 5 例，配置或文档语义 4 例，等价表面行为 1 例。响亮崩溃、未合并 PR、普通功能增加、通用认证或限流 bug、fail-closed 父版——统统排除。

🎯 断线断到了哪一层

影响层级（impact tier）是本文另一根轴，和复现强度严格分开。复现强度问"跑得多真"，影响层级问"断得多深"。

E1 执法边界，14 起。细分三档：阻断/过滤/改写 5 起——父版放行不安全内容，修复版拦下或改写，NeMo 正则就在这档；中断/HITL 路由 3 起——工具执行绕过配置停止点，Haystack 是代表；hook/cap/策略状态 6 起——配置的执法 hook、上限、规则更新没触发，CrewAI 算一例。这 14 起再往下拆：7 个原生动作结果、6 个配置执法边界、1 个合成消费者后果。

E2 验证器/安全提示词证据，3 起——证据从评估器或安全提示词的输入里丢了，Promptfoo 的案例在这档。E3 可观测性通道，1 起——结构化证据对策略相关消费者隐藏，AutoGen。

前后对比只有四种形状，像四种尸检报告：证据不可见（absent / none / restore carrier），执法跳过（visible / none / restore adapter），错误权威（stale / wrong / select channel），策略状态过期（stale / stale / rebind rule）。父版里证据缺席、搁浅、错投、或躺在过期的策略状态下；修复版里，金丝雀到达该去的字段，该响的动作响起。

🧪 怎么证明这不是讲故事

一个独作论文，18 起案例全靠作者自己确认，读者凭什么信？这一节是全文最体现"边界纪律"的地方。

分母审计：195 条高信号公开 PR/issue 引用，逐条过同一确认规则，新增 9 条候选。随机对照：55 个随机合并 PR 批次，无一确认——说明这类失效不是"随便翻仓库就能翻到"的大路货。留出对照：8 条高风险审计候选，无一确认——提升规则是保守的。13 条已审查阴性排除，边界纪律清清楚楚。21 条混合候选审计，18/3 分裂，确认规则稳定。14 个已知模式 fixture，四种家族 schema 全部可表达。

最见功力的是五案例可运行诊断对比：Invariant、NeMo 正则、CrewAI、Haystack、LangChain 流改写。普通功能检查在没有金丝雀预言机时全部通过；仅可见性检查对 NeMo 和 Haystack 的适配器/决策缺失不够用；部分预言机甚至无法记录修复。唯有完整合约——改变表面放置 + 父/修复可见性 + 动作边界的决策断言——能把失效钉死。

还有一记前瞻审计。作者冻结了审计规则之后才去看新数据：300 个近期关闭 PR，其中 186 个已合并 → 27 条术语匹配候选 → 23 条排除、3 条复现中、1 条额外确认。规则先于数据定死，这是实验室级的自我约束。

🛠️ 管道工手册

对回归测试的含义，作者说得直白：失效对象常常是 schema、适配器、流或回调，而不是提示词。这给行业提了个醒——guardrail 的 CI 里如果只跑功能回归，等于只测"喷淋头有没有水"，从不测"报警器的线通不通"。

金丝雀合约是把隐藏安全假设变成显式合约的方法：对 schema、流、工具、适配器、策略更新路径做回归测试。作者的立场句值得印在框架文档的扉页：我们不问模型是否总体不安全。我们问一个具体安全边界是否仍收到它被造出来要用的证据。

顺带一提，Sculley et al. 2015 那篇"机器学习系统的隐藏技术债"早就警告过 ML 系统里看不见的接口耦合；Dig & Johnson 2006 研究 API 演化怎么弄断客户端。这篇论文把这两条线在 LLM 安全的具体地形上接了起来——继承旧问题，发现新实例。

🔮 管道修好之后

回到那栋着火的大楼。

这篇论文没有给出更灵敏的烟感，也没有更猛的喷淋。它做了一件更朴素也更难的事：告诉你大楼里哪些线会断、断在什么位置、怎么一根根查。四家族是地图，金丝雀合约是万用表，18 起案例是 18 份现场笔录。检测器阳性了而闸门没收到——在论文的世界里，这不是玄学，是可以在父版本和修复版本之间逐比特复现的机械事实。

对"证据的最后一公里"这个话题，这还只是第一程。断链诊断完之后，紧接着的问题是泛化：如果每个框架的每条证据路径都要单独铺线，安全工程师迟早累死。管道修好之后，下一个问题是——一台监控器，能不能看住万种任务？靠一个通用因子（Factor）通吃输入、输出、工具调用、流事件、验证器证据，这样的监控器长什么样？它如何证明自己对每个新表面都没有失明？

这是第二篇的故事：OwlSight。一台监控器，靠一个 Factor，看住万种任务。

而第三篇更狠：SEER-Repro，让 AI 把已发表的科学重做一遍——监控的终极形态，不是盯着模型别作恶，而是盯着"知识"本身别造假。到那天，监控器守的将不再是某栋楼，而是整个人类认知的大厦。

警铃响了，闸门就得收到。这话说起来像废话，可整个 2026 年的 LLM 安全生态，正在为它补课。

📚 参考文献

1. Junchi Liao. Monitor-Validity Failures: LLM Safety Evidence Paths at Evolving Framework Boundaries. arXiv:2610.23362, 2026.
2. Wei et al. Jailbroken: How Does LLM Safety Training Fail? NeurIPS 2023.
3. Mazeika et al. HarmBench: A Standardized Evaluation Framework for Automated Red Teaming and Robust Refusal. 2024.
4. Inan et al. Llama Guard: LLM-based Input-Output Safeguard for Human-AI Conversations. 2023.
5. Han et al. WildGuard: Open One-stop Moderation Tools for Safety Risks, Jailbreaks, and Refusals of LLMs. NeurIPS 2024.
6. Zhan et al. InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated LLM Agents. ACL 2024 Findings.
7. Debenedetti et al. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. NeurIPS 2024.
8. Andriushchenko et al. AgentHarm: A Benchmark for Measuring Harmfulness of LLM Agents. 2024.
9. Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models. 2022.
10. Schick et al. Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS 2023.
11. Qin et al. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs. ICLR 2024.
12. Leucker & Schallhart. A Brief Account of Runtime Verification. 2009.
13. Falcone et al. What Can You Verify and Enforce at Runtime? 2012.
14. Dig & Johnson. How Do APIs Evolve? A Story of Refactoring. 2006.
15. Rothermel & Harrold. A Safe, Efficient Regression Test Selection Technique. 1997.
16. McKeeman. Differential Testing for Software. 1998.
17. Chen et al. Metamorphic Testing: A Review of Challenges and Opportunities. 2018.
18. Sculley et al. Hidden Technical Debt in Machine Learning Systems. NeurIPS 2015.
19. Breck et al. The ML Test Score: A Rubric for ML Production Readiness. 2017.
20. Amershi et al. Software Engineering for Machine Learning: A Case Study. ICSE-SEIP 2019.
21. Wang et al. AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents. 2025.

#论文解读 #小凯 #证据的最后一公里

arXiv:2610.23362 | papers.cool #19