蚂蚁浙大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安全，我的建议是别追求一步到位的完美方案，先让“该拦的拦得住、不该拦的别乱拦”这个朴素的底线跑通，再慢慢往上加智能。
