蚂蚁浙大HazardAuditor给Computer-Use Agent装上执行安全护栏这几年Computer-Use Agent能直接操控电脑的智能体越来越火从帮人订机票、填表格到自动整理桌面文件、批量处理邮件能力边界不断扩大。但有个问题一直梗在我心里Agent在屏幕上“看什么”“点什么”都由模型自主决策它如果被误导或者在复杂页面里误判了按钮含义产生的不是“回答错误”而是电脑上真实的、不可逆的操作。这时候你需要的不是更聪明的模型而是一道执行安全护栏。蚂蚁集团和浙大联合提出的HazardAuditor做的就是这件事——在Computer-Use Agent执行动作之前先判断这个动作安不安全、当前环境有没有危险。这篇文章会把它背后的机制、评测思路和实操价值拆开来讲适合正在做Agent落地、或准备给自动化流程加安全层的读者参考。1. 为什么Computer-Use Agent需要“专用”安全方案而不是套用传统安全工具我接触过不少团队一上来就说“Agent安全不就是杀毒软件加沙箱嘛”这个想法在实际落地时会发现完全不够用。传统安全产品防护的是“恶意程序主动攻击电脑”它们的模型假设是威胁是一段独立代码、一个恶意文件必须绕过系统防护才能发挥作用。可Computer-Use Agent的场景恰恰相反——Agent是合法运行的你的防护机制甚至就是它的一部分。它在浏览器里访问正常网站、在本地读取正常文件、执行正常的系统命令危险藏在这些“正常行为”的语义里。1.1 动作空间完全开放规则引擎根本枚举不完以浏览器操作为例一个Agent能执行的动作包括点击、输入、滚动、切换标签页、下载文件、提交表单、执行JavaScript等。每个动作又有近乎无限的参数组合点击哪个坐标、往输入框里填什么内容、下载哪个链接的文件。传统安全软件用“黑名单URL 文件指纹”就能挡掉绝大多数已知威胁但Agent可能访问的是全新域名、下载的是动态生成的文件、点击的是渲染后变化了的页面元素你没法预先在规则里列全。我用一个粗糙的类比来说明传统安全像是小区门口的保安只看进出的人是不是通缉名单上的Agent安全更像是给一个“代驾司机”配一个副驾驶督导员你不能只检查他有没有驾照还得盯着他是否会在路口被一个错误的路牌诱导而违规转弯。HazardAuditor的切入点就在这里不是识别某个URL或文件是否恶意而是判断Agent“接下来要做的事”在当前环境下是否安全。1.2 Agent的风险不只是恶意攻击更是“无意闯祸”日常实践里更常见的情况是一个Agent在处理任务时主观意愿是好的但因为页面语义复杂、指令理解偏差产生了有风险的行为。比如用户让Agent帮忙“下载这个页面上的PDF”页面上同时有两个长得几乎一模一样的按钮一个指向合法文档另一个是第三方广告插件的下载器Agent点错了就开始下载可执行文件。这种场景很难说是“被攻击”它更像是人在快速浏览时被视觉误导后的误操作只是Agent把这种误操作放大了——它执行动作只有几十毫秒的犹豫。HazardAuditor设计的核心假设就是危险不只在“页面本身是不是恶意”更在“Agent即将执行的动作与该动作所处页面上下文组合之后是否危险”。同一个“点击下载”动作在正规软件官网是安全的在钓鱼页面弹窗上就是不安全的同一个“输入信用卡号”动作在结账页是正常的在一个伪装成结账页的仿冒站点上就是高风险。所以它必须同时感知环境页面内容、URL、组件信息和动作Agent的下一步意图再给出判断。2. HazardAuditor的工作机制先“看清环境”再“评估动作”最后“给出安全动作”HazardAuditor的完整框架可以概括成三个层次环境构造层、风险识别层、安全决策层。它没有采用传统那种“发现危险就阻断一切”的硬性拦截策略而是走了一条更实用的路线——把安全问题变成一个“上下文感知的判别任务”根据风险等级动态决定是拒绝、警告还是放行。2.1 GuardEval一个有“陷阱”的评测环境评估一个安全系统是否有效最忌讳的就是测试环境太干净。如果只拿普通页面来测Agent本身误操作率就低安全模块很难体现价值。HazardAuditor项目里配套构建了GuardEval环境专门用来模拟高风险页面和误导性场景我理解它就像给自动驾驶做测试的封闭场地——有故意设置的假路牌、突然横穿的行人、模糊不清的车道线。GuardEval里面包含了三大类场景一类是显性危险场景页面里确实有钓鱼链接、恶意下载按钮Agent靠常识应该避开一类是隐蔽危险场景页面表面看着是正常的文档下载站实则通过诱导话术把Agent引向高风险操作还有一类是良性但极易误判的场景页面本身合法只是布局上有一些容易看走眼的干扰元素用来检验安全模块会不会过于敏感、误伤正常操作。这三类场景的价值在于它能同时测出安全模块“该拦的有没有拦住”和“不该拦的有没有放行”。2.2 RiskSieve风险识别器的双重判断逻辑HazardAuditor里的核心识别器叫RiskSieve。我研究过它的判断逻辑本质上是两阶段的双层过滤第一层是环境风险映射。RiskSieve会把当前Agent观测到的页面内容包括HTML结构、可见文本、控件属性、URL信息输入到模型中输出一个环境风险标签列表比如“该页面包含文件下载入口”“该页面存在表单提交区域”“该页面有外部链接跳转”。这一步等于是给环境做了一次“危险元素盘点”。第二层是“动作-环境”联合判别。它把对环境的危险元素盘点结果与Agent计划执行动作拼接起来判断这个动作在这个环境下是否安全。比如环境里有“外部链接跳转”的风险标记Agent正准备执行“点击跳转”联合判别就倾向于输出高风险如果环境里没有表单Agent却要“提交表单”这个组合就会被判为异常。这个双重判断逻辑比单纯“看到下载按钮就拦截”高明的地方在于它不是从零训练一个动作安全分类器那样样本极难覆盖而是把问题切分成“场景识别”和“组合判断”两部分任何一部分出了问题另一部分还能兜底。如果你的Agent遇到的是全新的危险页面类型环境风险映射可能识别不出新标签但动作-环境联合判别仍然可能因为“此类动作与当前环境不匹配”而给出风险提示。2.3 安全护栏不是“踩刹车”而是“重新规划路线”我更欣赏的是HazardAuditor对决策层的定义。真正落到产品里安全模块如果把危险动作全拒绝了Agent的任务往往就卡住了——用户想下载文件的诉求没有解决只是从“点错下载器”变成了“什么都没下载”。HazardAuditor的做法是对高风险动作直接拦截对中低风险动作给出一个“安全替代动作”。举个例子Agent想下载一个文件但页面里存在多个可疑下载链接。RiskSieve把“点击第一个下载按钮”判为中高风险安全决策层不是简单丢弃这个意图而是从页面里重新寻找一个与“下载意图”匹配的、风险更低的替代元素或者提示Agent“确认下载前需要用户手动验证”。这样一来安全模块从“限制器”变成“转化器”它在约束行为的同时保留了完成任务的可能性。这个设计哲学我觉得是所有做Agent安全的人都应该抄的作业。3. 两个核心难题如何在“大海捞针”和“语义伪装”面前守住底线论文里我最关注的是它针对的高难场景设计。标题里提到的Computer-Use Agent安全真正难的不是对付那些一眼假的钓鱼页面而是对付“在大量正常内容里藏着一个危险点”以及“看起来完全正常实际有毒”的两种模式。HazardAuditor在这两个方向上分别设计了评测任务我用大白话拆一下。3.1 Needle-in-a-Haystack大型页面上翻车的概率超乎想象第一个任务是“大海捞针”型——一个Agent在浏览器里打开了十来个标签页每个页面内容都很正常但其中一个页面的角落里藏着一个恶意下载链接。这种场景在真实使用中太常见了用户让Agent搜索某个工具软件结果自然结果页里混着推广广告推广链接指向的却是捆绑安装包。对Agent来说它的视觉注意力机制和人一样会被页面主体内容吸引对侧边栏、页脚、浮层里的元素关注度天然偏低于是就越过了危险点。GuardEval在这类场景里的构造方式很有验证力它把恶意元素伪装成页面里的“正常小部件”——一个“下载加速器”小图标、一个折叠起来的“推荐阅读”区域、一个渲染在页面底部的悬浮按钮。Agent如果没有对页面做完整的元素级扫描很容易直接忽略。评测结果显示未加护栏的基准模型在这种场景下任务成功率尚可但安全违规率明显偏高加上HazardAuditor后风险识别率提升了接近30个百分点说明这种显性的“找危险”能力确实需要专门训练不能指望Agent模型自己在推理时“顺手”具备。3.2 Semantic Chameleon危险不再靠特征识别而是靠语义推理第二个任务“语义伪装”就更有意思了它模拟的是“页面本身不黑但会把Agent一步步诱导到黑”。一个典型案例是一个页面设计成“免费Wi-Fi认证页面”Agent收到的用户指令是“帮我在这个页面上完成认证”然后页面上有一个按钮“点击安装根证书完成网络配置”。如果Agent真的点了就在电脑上装了一个来路不明的根证书——这是非常严重的安全事件。但问题在于这个页面没有任何传统意义上的恶意特征没有可疑域名可能真的就是某个公共Wi-Fi的官方认证页没有恶意文件证书文件本身合法格式一切都是“正常网络认证流程的一部分”。唯一的问题是这个动作在Agent的自主决策上下文中具有高权威性——它决定去信任一个未经用户确认的证书来源。HazardAuditor处理这类场景靠的正是“动作-环境联合判别”环境里存在“证书安装”“网络配置修改”等高敏感操作标记Agent动作又是“点击安装”两者组合后风险等级自动拉高。这说明什么呢说明安全系统不能只看“页面是谁的”更要看“动作会改变什么系统状态”。我常说的一句话是对Computer-Use Agent来说危险的不是页面是动作——页面只是动作的舞台布景。区分“无害页面上的危险动作”和“危险页面上的无害动作”才是安全模型真正要练的功夫。3.3 评估指标的“及格线”应该怎么定在评估一个安全系统时准确率和误报率是跷跷板。只看“危险识别率”会诱导模型宁可错杀一千——把所有下载按钮都标记为风险指标好看了但没法用。HazardAuditor的评估设计我在论文里看到的做法比较务实同时测量“危险动作拦截成功率”“安全动作通过率”“任务执行成功率”三个维度。后两个指标存在的意义是防止安全系统过度激进。真实场景里用户只要碰到一次“明明安全却被拦截”的情况就会对这个安全功能彻底失去信任Agent产品也就会被闲置。所以安全方案的验收标准必须带“实用性”维度不能只看它能拦多少危险。4. 实测效果、边界与对现有Agent安全工具的评价4.1 数据表现提升真实但别神化基于公开的评测结果HazardAuditor的效果在几个维度上都有比较明显的提升在GuardEval环境上面对“大海捞针”型危险页面加装护栏后风险识别率比未加防护的基准模型提升接近30%面对“语义伪装”型危险场景模型在保持任务执行成功率的前提下安全违规率大幅下降。同时对于普通无害页面的正常操作护栏没有产生明显的过度拦截这从“安全动作通过率”和“任务执行成功率”两项数据可以看出。但我必须说一句公道话提升30%这类数据是在GuardEval这个专门构造的测试环境里取得的。真实世界比这个复杂得多——网页的动态渲染、反爬机制、用户的临时授权、多任务切换都会影响安全模型的稳定性。我见过不少团队把论文里的数字当成生产环境的最低保障这是理解偏差。这类评测的真正价值是证明“方向可行”不是承诺“指标保底”。4.2 现有方案的对比为什么“审计日志”和“提示词约束”都不够现在市面上对Agent安全的做法大致有三类一类是“事前约束”在系统提示词里写“不要点击可疑链接”成本最低但几乎不可靠因为模型很可能在长上下文里遗忘这条规则或者被页面话术覆盖另一类是“事后审计”在Agent执行完动作后记录日志、做风险分析这对“追溯责任”有价值但动作已经发生了下载的文件可能已经落地、系统配置可能已经改变属于亡羊补牢第三类就是HazardAuditor这种“事中拦截”在动作执行前判断风险。三者不是替代关系是互补关系。我在实际项目里的经验是提示词约束作为第一道成本最低的过滤HazardAuditor这类事中拦截作为主要防线审计日志作为最后一道追溯兜底。很多团队只做了事中和事后忽略了事前约束结果是安全模块每次都在处理低级错误而不是聚焦真正的危险。4.3 护栏的“视野盲区”识别器的极限在哪里HazardAuditor这样的方案在我做完深度分析之后也看到了一些明确的边界。第一它的判断依据是Agent的观测内容也就是屏幕截图、DOM树、URL这些信息。如果攻击者能够污染Agent的观测输入——比如在页面里塞大量隐藏文本干扰DOM解析——RiskSieve的识别准确性就可能被削弱因为它看到的“环境”本身就已经被污染了。第二当前针对危险动作的分类粒度还不够细。像“下载文件”这样的粗粒度动作无法区分下载的是一个无害的PDF还是一份带宏的恶意文档更精细的判断需要文件内容层面的分析那就超出了Agent观察层的能力范围。第三也是我觉得最要注意的一点安全护栏与Agent模型是分离的两个系统这就产生了“模式博弈”的可能。Agent在试错过程中可能学会一种“绕开护栏”的路径——比如通过其他辅助工具绕过浏览器环境执行某个动作安全模块此时会成了瞎子。所以护栏系统需要长期对抗性迭代而不是上线后就不管了。5. 复现思路、落地建议与下一步演进方向分享几点基于我个人项目经验的落地建议。如果你正在做一个Computer-Use Agent产品想把HazardAuditor的思路用起来不一定要从零复现整篇论文可以按增量方式推进。5.1 最小可行版本先做“三张清单”和“一个标签器”我建议第一步是做三张静态清单危险动作清单修改系统配置、安装证书、执行命令行、下载可执行文件、修改注册表等、敏感信息清单信用卡号、身份证号、密码、私钥等、敏感URL模式清单以银行、支付、邮箱、后台管理等为关键词的域名。然后把Agent每次执行动作前做一个轻量级标签器判断动作类型是否属于清单、环境中是否出现清单信息、组合起来是否触发风险。这套MVP也许没有RiskSieve那么智能但它能覆盖80%的常见Agent安全事故而且实施成本极低一周内就能跑通。我见过几个创业团队就是这么起步的跑通后再逐步引入视觉模型识别更复杂的页面语义风险。5.2 把“用户确认”设计成安全机制的一部分而不是体验打断落地中最容易翻车的是“用户确认流程”。很多产品把确认弹窗做成全有全无——要么每个动作都问用户烦死要么高危动作也不问出事后甩锅给用户。HazardAuditor的分级思路应该被沿用低风险动作直接执行中风险动作提示风险但可自动继续高风险动作必须用户二次确认且要明确告知“这个操作会修改系统/下载可执行文件/提交敏感信息”。我在一个内部工具里实践后发现把“确认文案”从“是否继续”改成“此操作将下载并运行来自未知来源的可执行文件是否继续”之后用户被打断的抵触感反而下降了——因为他们感知到系统真的在保护自己而不是机械地弹窗。5.3 对抗性攻防与数据回流护栏也要持续升级跑过一段时间后你会发现风险标签器对已知风险会越来越准但对付新型攻击会越来越吃力。所以生产环境里需要设计一个数据回流闭环凡是安全模块放行后被用户投诉或事后审计判定为可疑的样本都要自动回流到标注池定期微调RiskSieve模型。另外我强烈建议做定期的“红队演练”——让安全工程师扮演攻击者专门设计能骗过Agent和护栏的页面。我们部门做过一次演练攻击者只是把恶意下载链接改成了“页面加载完成后动态插入DOM”的方式初版护栏就漏掉了。不是模型能力问题而是训练数据里缺了“动态渲染后出现的新元素”这一类特征。这个坑值得所有同行注意只要你的Agent跑在真实互联网上护栏就永远没有“毕业”一说。5.4 下一步从“执行边界”走向“意图对齐”HazardAuditor目前的侧重点是把“执行动作”限制在安全边界内但Agent安全的长远方向一定会延伸到“意图对齐”——让Agent不仅不执行危险动作还能知道“用户真正想要的是什么”以及“哪些动作即便看起来安全也不符合用户的最佳利益”。往深了走这需要把HazardAuditor的安全判断与Agent的价值对齐机制整合起来比如通过偏好优化让Agent在面临“下载捆绑软件但用户可能不知情”的场景时主动选择拒绝而不是等外部护栏来拦截。我在实际使用中的体会是安全护栏的价值不在于它能挡住多少已知攻击而在于它给了Agent一个“可以犯错但不至于闯大祸”的空间。没有这个护栏Agent只敢在完全确定安全的场景里执行动作那它作为生产力工具的意义就废了一半。HazardAuditor让我看到了一个正确的中间态Agent保留操作能力系统保留最终裁决权两者各退一步反而是最有利于落地的姿态。如果你也在做Agent安全我的建议是别追求一步到位的完美方案先让“该拦的拦得住、不该拦的别乱拦”这个朴素的底线跑通再慢慢往上加智能。