安全监控跑得很准，和它监控的日志根本不记关键事件
给工具调用型智能体装护栏，主流做法是应用级规则：这条链路不许转账、那个域名不许访问。问题是规则一复杂就不可审计、不可复用。arXiv 2610.09793（10 月 7 日提交，已被 ACM CCS 2026 同期研讨会 CPSIoTSec '26 接收）走了另一条路：用形式化时序逻辑 MFOTL 当监控语言，拿现成的 MonPoly 监控器，把 AgentDojo、STAC、R-Judge 三个基准已经录好的轨迹离线重放——不跑智能体，直接审历史。
结果很有戏剧性：五条通用义务（obligation）能标出 71.8% 的 STAC 攻击链、70.1% 的 AgentDojo 成功攻击——但同时也在 29.3% 的良性运行上拉响警报。
误报的锅，逻辑不背，数据背
论文最值得品味的结论是：这个不精确不是逻辑的错，是语料的错。三大基准的轨迹很少记录「审批」事件，也从不记录时间戳——于是那些依赖历史的义务（比如「敏感操作前必须有过授权」）统统退化成「识别危险动作类型」。监控器在跑一条比真实执行更单薄的故事。论文有句话可以直接抄走：形式化时序监控的价值，恰恰发生在「轨迹暴露了可信历史」的时刻。
溯源（provenance）的实验更刺激。当轨迹里确实带了关系上下文（比如这个动作引用了哪次查询的结果），溯源感知的策略判别力明显更好——但这上下文本身可被攻击：在轨迹里植入一行，就能让朴素的溯源检查在 94%–99% 的、本来会被标记的运行上失效。论文的补丁是把溯源信息绑定到「产生它的那次查找」上，攻击者就没法凭空伪造一条来源——检出率和误报率都不牺牲。
十二个字段：给「执行就绪的轨迹」立个最低标准
论文最后提了一份十二字段的执行就绪轨迹模式（twelve-field enforcement-ready trace schema），直指当前评测基建的缺口：如果轨迹不记授权决定、时序和数据血缘，那么外部监控到底是在「执行策略」还是「认可疑工具名」，根本分不清。往细处说，一个动作仅仅被记下还不够，还得能回答三个问题：谁批准的、什么时候发生的、引用的数据从哪来——三个问题缺一个，历史依赖的义务就没法执行。这和本站 1594 的 PACE（每次调用执行前 mediate）、1816 的 NOMOS（静态校验加确定性闸门）是同一条防线的不同厚度：前者在动作发生前拦截，这篇在动作发生后审计——但两者的共同前提一样：日志得先成为安全边界的一部分，而不是调试排气管。
对做智能体平台的团队，这篇的落地含义很具体：你的轨迹里有没有审批事件、时间戳、引用链？没有的话，任何「我们的监控覆盖率 99%」的宣传都缺少证据基础。对评测基准方，这是一份现成的 checklist。形式化运行时验证在安全关键系统里有多年积累，MonPoly 这类监控器也是其中被反复使用的一环——这篇的价值是把这套老方法迁到智能体语境后，顺手量出了「迁移的最后一公里」：不是逻辑不够强，是轨迹不够用。当然要标注口径：以上检出与误报数字来自论文在三个既有语料上的离线实验，不是生产环境成绩；十二字段模式是提议，采纳与否取决于社区。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。