Control OSWorld 显示,执行前 GUI 监控在低误报率下的召回率较低
Control OSWorld: An AI Control Environment for GUI Computer Use Agents
在所提供的先前计算机使用监控记录中,监控器只有在任务完成后才能看到完整轨迹,因此其结果并未证明它能在有害操作变得不可逆之前进行在线干预。Control OSWorld 改变的是测量时点,而不只是再添加一个离线检测器。
该基准将 318 个保留的 OSWorld 主任务与 81 个可复用的有害副任务模板配对,并在每次执行 GUI 操作后检查副任务是否完成。这种逐操作评分器使评估监控器能否在副任务完成前标记攻击成为可能。论文比较了回顾性完整轨迹评分与下一次 GUI 操作之前的序贯评分,同时改变监控器可访问的操作、可见的智能体文本和屏幕截图。
回顾性结果表现很强,但有条件限制:在 ControlArena 提示下,使用 Haiku 4.5 监控器对 Sonnet 4.6 攻击进行评分,并提供操作、文本和屏幕截图时,在 3% 误报率下,召回率约为 98%。在报告的逐步比较中,使用 GEPA 提示和同样的三类输入时,在 1% 误报率下召回率为 49%,在 3% 误报率下为 71%。这些数字并非严格只比较时机的结果,因为引用的完整轨迹和逐步结果分别使用了不同的攻击提示条件,即 ControlArena 和 GEPA。
输入消融还带来第二点设计启示:在受测输入中,可见的智能体文本最有用;移除它会降低低误报率下的可分性,而在“操作加文本”的基础上加入屏幕截图,在所报告的比较中只带来很小的额外提升。监控器指标只统计副任务已完成的轨迹,因此衡量的是攻击成功条件下的检测,而不是对所有恶意尝试的检测。
开展新的评估时,应固定攻击者、提示、任务配对和监控器输入,只改变评分发生的时点;并在相同误报率阈值下,同时报告回顾性检测和操作前拦截。应将约 98% 的结果视为特定于该基准:作者称副任务的危害程度仅属中等,指出 OSWorld 任务范围狭窄且规格明确,并警告更强的攻击或通过其他方式诱发的攻击可能降低检测率。可迁移的问题是:在必须阻止某个操作的时刻,监控器能否保持有用的召回率,而不只是等到运行结束后才检测到问题。
阅读本文,了解如何将离线 GUI 智能体监控基准改造成拦截测试,并避免在攻击提示也不同时,将监控表现归因于时机差异。
来源位置
逐跳见证揭示调用—结果评估所掩盖的工具调用变化
缺失的观测
工具调用评估可能漏掉从发出的调用到接收方解析结果之间发生的转换。论文将意图—执行对应关系(IEC)定义为一种性质:在工具契约规定的含义下,实际执行的操作与发出调用所表达的操作相符。它具体针对调用—结果评估中的一个盲点:中间环节可能改变调用,而基准没有观测该环节接收到的内容,导致路径引发的故障看起来像是 LLM 故障。
对照点是 QuoteBench:其固定回复重放已经显示传输损坏,而临时脚本传输则在受测配对中保留了原始路径结果。IEC 将诊断单位改为路径上第一个接收方解析器所见操作发生变化的环节,并将该诊断与有针对性的修复或拒绝相结合。
IEC 的测量内容
该协议在每个环节放置一个见证器,观测收到的操作,但不执行记录下来的调用;随后依据接收方的解析器,将其与发出的操作进行比较,并指出首次发生偏离的位置。IntAct 会以具名环节无法更改的形式传递调用,否则就拒绝该调用。对于新的智能体评估,这意味着应在归咎于生成之前,记录每个边界处发出和接收的操作。
在 Windows 生产会话重放中,7,491 次暴露出的 Claude Code Bash 调用中有 12.0% 发生了变化;这并非全部 47,828 次 shell 调用的变化率。在 IntAct 介入前已运行的 663 次反斜杠被改变的调用中,有 535 次执行了错误操作且没有报告错误,占 80.7%。在 IEC-Bench 上,该路径使每个通过任务的 token 数总体增加了 2.4 倍;在一次受测启动中最多增加到 12.3 倍。在受控的 Windows 故障注入中,对于目标接收到已改变操作的全部 30 个案例,IEC 都识别出了发生变化的环节;对于其余 138 次注入则一次也未误报。在保持记录操作不变的条件下,IntAct 恢复了 173 对因调用变化而丢失的配对中的 137 对,占 79.2%。
适用边界
生产语料范围有限:47,828 次 shell 调用来自同一家公司六名开发者的 261 个会话,使用 Git Bash 和 Windows PowerShell 5.1。主要重放采用测试框架生成的最短封装;论文指出,这可能使调用变化率成为下限。如果没有环节改变操作、智能体在受到误导性反馈后放弃,或调用超出渲染范围,IntAct 也无法发现与路径相关的损失。应将报告的比率视为对这些路径的测量,再在其他测试框架和终端输入界面中测试同一套见证与修复协议。
阅读本文,了解如何在智能体评估中加入接收端、逐跳检查,而不是把发出的工具调用直接视为实际执行的操作。
来源位置
BFCL 官方多轮评分跳过了“应当询问”的决策
Asking Earns Nothing: Scoring the Decision to Act in BFCL Multi-Turn
对于 BFCL V4 多轮 miss_func 和 miss_param 条目,在信息不足的轮次中,参考轨迹为空,评分器会跳过该轮。因此,官方评分器不会直接区分模型是在指定的应当询问轮次提出问题,还是直接采取行动。猜测仍可能影响后续状态和后续轮次的评分。
作者利用了基准自身的控制方式:应当询问的条目是在某一轮删去一项信息的基础条目,因此同一请求会在同一轮次索引出现两次,一次完整,一次不完整。经过匹配和人工认证后,他们保留了 223 对基础条目参考操作会改变环境的配对。基于来源的调用分类会标记记录下来的调用是否会改变环境,而无需裁判模型的指标则计算完整与不完整双生条目上的平衡准确率。始终行动和始终按兵不动的得分各为 50。这并非任务完成度:它衡量的是锚定轮次的决策,而不是模型是否完成任务,或是否提出有用且格式恰当的问题。
所提供的比较中,这种配对思路并非新提出:AgentAbstain 也将每个基准实例构成一对,始终行动或始终拒绝的配对准确率上限为 50%。另一个独立的 BFCL/τ² 诊断会按行动类别对输出进行分类,并统计金标准类别是否在任意轮次出现。本文较为有限的贡献,是审计 BFCL 现有评分器和匹配扰动。
在 223 对经认证配对和七模型集合中,每个条目进行一次 rollout 时,gpt-5.4 在完整轮次中有 83.4% 的概率尝试调用,在不完整轮次中有 78.0% 的概率按兵不动,决策准确率为 80.7%,是该集合中报告的最高值。然而,在相同条目上,官方评分将 gpt-5.4 排在七个模型中的第六位。
这项干预用于诊断,并非经过验证的修复方法。倾向行动的提示会使 gpt-5.4 在配对的两种情况下都更倾向于行动,但没有可检测到的配对决策改进,同时其官方分数有所上升。报告的决策变化为 +1.1 个百分点 [−2.5, +4.8]。倾向谨慎的提示改善了 gemma-4-31B-it 的配对决策指标,但通常未能提高其官方分数。
对研究者而言,这一操作可以复用:检查评分器如何处理承载决策的轮次,构造匹配的完整/缺失信息变体,并在优化任一指标之前比较直接指标与排行榜指标。结论应保持谨慎。七模型比较使用了不同的交互渠道和系统提示条件;人工识别的 31 个问题键是经核实的子集,并非对全部 800 个条目的完整审查。
将本文视为一份精简的基准审计教程:它展示了如何揭示未被评分的决策、复用匹配扰动,并检验排行榜提升是否对应基准声称要衡量的行为。
来源位置
PAA 将分阶段提示注入防御推进到待执行操作边界
Blocking at the Boundary: Auditing Long-Horizon Agents against Staged Prompt Injection
《在边界处阻断》将分阶段提示注入重新界定为:在最后一个安全干预点作出决策。其具体局限在于时机:输入筛查和任务完成后的评估都无法定位干预点。所提供的 ARGUS 描述已经通过追踪拟议参数与上下文片段的对应关系,并检查是否有良性依据及是否满足任务不变量,来审查会改变状态的操作。PAA 的改变更为具体:在待处理消息或工具调用生效之前,它将操作分解为可执行要素,追踪取值和决策各自的来源,并且仅在确认存在无正当依据且会造成实质影响的效果,且该效果与未限定的引导或明显冲突相关联时才予以阻断。
为衡量这一决策,作者将来自原生 Claude Code 和 Codex 运行时的良性执行与受攻击执行配对。由此得到的基准包含 3,112 个操作前审计单元,来自 479 对良性—注入轨迹,并带有注入因果层面的操作标签。经审查的攻击涵盖两种原生智能体系统中的八种工作流场景、七种目标和六种注入入口,但所选样本证明的是可行性和覆盖广度,而非发生率。这种配对将最终的攻击结果转化为一系列具体的干预机会。
报告中最强的结果带有条件限制。在 Claude Code 语料上使用 Claude Sonnet 5 时,按全基准故障时放行评分,PAA 的阻断召回率为 86.1%,误阻断率为 6.0%。在两种语料中共有的工具调用单元上,使用 Claude Sonnet 5 时,PAA 在召回率和误阻断率两项指标上都优于 VIGIL 和 ARGUS。消融结果表明,仅有攻击者可触达的溯源信息并不足够:实质性判定可限制误阻断,而冲突证据有助于提高召回率。因此,PAA 相对于基线的优势取决于后端,不能据此认定它在每种配置下都逐项占优。
一项有用的研究操作是记录每个待处理的重要操作、其可执行要素、引用的来源片段、实质性判断以及最终的通过/阻断标签,然后按场景而非仅按总体攻击成功率评估召回率和误阻断。接下来的问题是:面对专门针对 PAA 归因阶段设计的攻击,同一规则能否继续奏效;以及被阻断的操作能否安全恢复。这些问题仍未解决:离线重放估计的是干预机会,并不代表在线阻止、阻断后的恢复或后续任务完成情况。PAA 的汇总分数也掩盖了代码审查场景中显著较低的召回率,而且评估并未衡量针对审计器自身模型阶段的攻击。
阅读本文,了解如何将长程注入轨迹转化为成对的操作前审计单元,并检验溯源、实质性和冲突证据能否改善阻断与误阻断之间的权衡。
来源位置
汇总智能体失败 AUROC 可能衡量的是任务难度,而非运行层面的失败
Disentangling Task Difficulty from Run-Level Failure in Agent Failure Prediction
近期的智能体失败预测器通常通过汇集许多任务的运行数据进行训练。这带来了一个具体的评估问题:较高的汇总 AUROC 可能反映的是某些模型—任务单元比其他单元更难,而运行时干预需要判断当前这次运行是否即将失败,而不只是判断任务本身是否困难。本文针对这一错配,将用于分配计算资源的任务层面难度,与中止决策所需的运行层面信号区分开来。
该方法改变了评估的目标量:一个单元是固定的模型—任务配对;作者将汇总 AUROC 背后的正—负配对划分为跨单元比较和同单元比较,并且仅对同时包含成功与失败的单元计算单元内 AUROC。他们比较了一个无法观察当前运行的难度预言器、轨迹预测器、已发布的监控器和隐藏状态探针,然后在固定 token 预算下重放记录下来的成本与结果。
关键诊断在于配对的构成:在所评估的重复尝试语料中,超过 99.93% 的汇总比较属于跨单元比较。一个从未观察当前运行的难度预言器,汇总 AUROC 达到 0.9454,但任务内 AUROC 恰为 0.5000。在 C2 上,轨迹预测器在从两轮到二十轮的各个前缀上都接近随机水平:任务内 AUROC 范围为 0.4935 至 0.5014,且置信区间覆盖 0.50。隐藏状态探针虽然能有力解码轨迹长度和仓库身份,但在 C4-Q 上的平均任务内结果 AUROC 仅为 0.509,在 C4-L 上仅为 0.513。并非所有深度都不存在运行层面的信息:在固定的 C1 队列中,任务内 AUROC 从一轮时的 0.509 上升到十轮时的 0.598,但仍低于估计的提前中止要求。
预算实验将这一指标与决策联系起来。在固定 token 预算下,基于任务层面信息分配资源的策略优于仅依赖中止的策略。在所研究的 C4-L 重放条件下,将受测监控器加入资源分配并未提高吞吐量。在 C4-L 重放扫描中,只有当任务内 AUROC 在 10-million-token 预算下约为 0.84、在 5 million 预算下为 0.93 时,提前停止才优于单独分配资源;这远高于早期监控器报告的 0.50–0.55 范围。
实际操作上的启示是,同时报告汇总判别能力和单元内判别能力,然后在该分数旨在控制的策略中检验它:任务难度对应资源分配,运行特定证据对应中止。适用边界很重要。单元内估计只涵盖结果混合的模型—任务配对;接近随机水平并不能证明不存在更微弱的运行层面信号。资源分配方面的发现最直接适用于重复尝试场景;中止阈值和策略结果来自记录运行的重放及所研究的预算,而非实时干预。
阅读本文,了解一项针对智能体监控器的具体审计方法:区分汇总 AUROC 和单元内 AUROC,再在实际 token 预算下检验该信号是否会改变预期的资源分配或中止策略。