WebAgentGuard：给 Web Agent 加一道并行安全闸门

今天介绍的这篇论文名字叫《WebAgentGuard: A Reasoning-Driven Guard Model for Detecting Prompt Injection Attacks in Web Agents》。

它聚焦的是 Web Agent 在真实网页环境里的提示注入风险：恶意指令可能藏在 HTML 文本里，也可能被渲染到页面可视区域里，最终影响 Agent 的判断与执行。

WebAgentGuard 的核心：在 Agent 前面加一道并行安全闸门

作者的核心判断是，Web Agent 在执行任务时，天然会更偏向”完成当前任务”，这会削弱它对外部恶意指令的独立识别能力，因此需要把”安全裁决”从”任务执行”中拆开。

论文提出的框架很清晰：在每一轮执行中，网页观测会同时送给 Web Agent 和 Guard。Web Agent 负责生成下一步动作，Guard 负责输出”允许 / 拒绝”信号。最终由一个 Action Gateway 决定这个动作是否真的执行；如果 Guard 拒绝，还可以进入人工确认流程。这个流程分成两段：第一段是 Guard 审批，第二段是用户审批。

这个设计的价值，在于它把 Agent 系统里两个原本缠在一起的能力拆开了：一边负责做事，一边负责裁决风险。在很多现有方案里，任务规划、页面理解、工具调用、安全判断都塞进同一个模型里完成，结果往往是模型在强任务驱动下，更容易顺着网页里的伪指令继续往前走。WebAgentGuard 选择单独训练一个守门模型，让它只做一件事：判断当前观测里有没有提示注入风险。这个思路更接近传统安全体系里的”旁路审计 + 执行前拦截”。

什么是 Web Agent 的间接提示注入

论文里对 Web Agent 的观测定义很明确：每一步输入由两部分组成，一部分是网页截图，另一部分是处理后的 HTML 文本表示。

攻击者可以把恶意指令写进原始 HTML 中，让这些内容通过文本模态、视觉模态，或者两者同时被 Agent 感知。最终，Agent 可能在用户本来要求它完成正常任务的前提下，转而执行有害动作，例如泄露密钥、发送错误信息、跳转到攻击者指定目的地。

这一定义有两个值得注意的点：第一，论文讨论的不是传统聊天场景里的直接越狱，而是环境注入。第二，它强调攻击载体同时存在于文本层和渲染层。

这意味着很多只看 prompt 文本、只看 DOM 结构、或者只在 Agent system prompt 上做约束的方案，天然会有盲区。Web 环境里的攻击面，比单轮对话复杂得多。

WebAgentGuard 是怎么训练出来的

这篇论文没有去大规模采真实互联网网页，而是采用了一套合成式多模态数据构造流程。

作者使用 GPT-5 生成网页 HTML，覆盖 164 个主题和 230 种视觉 / UI 风格，再为这些 HTML 获取对应截图，并保留 Agent 真正可感知的内容。随后，在正常网页基础上插入恶意指令，构造成正负样本对。整个数据被拆分为 SFT、RL 和 Evaluation 三部分，其中 SFT 集 1921 条，RL 集 3454 条，评估集 1000 条。

更值得关注的是它的训练目标设计。作者不是简单把这个任务当成二分类，而是专门让 GPT-5 给 SFT 数据补上带推理过程的答案，要求模型输出结构化的 reasoning 和最终判断。然后再用 GRPO 做后训练，把”格式正确”和”判断正确”作为奖励依据。也就是说，作者想让 Guard 学到的不是一句”有攻击 / 没攻击”，而是一套相对稳定的安全分析模板。

防护效果

在作者自建评测集上，WebAgentGuard-8B 达到 99.20% Accuracy、98.40% Recall、100.00% Precision、99.19% F1；4B 版本也达到 98.20% Accuracy、96.80% Recall、99.59% Precision、98.17% F1。

相比之下，不少通用闭源模型、开源视觉模型，以及已有 guard 模型，最大的问题不是精度低，而是召回不足，容易漏掉真正危险的样本。比如 Qwen2.5-VL-Instruct-7B 的 Recall 只有 3.51%，Llama-Guard3-Vision-11B 只有 1.40%。

这组结果很说明问题。在安全场景里，低召回比低精度更危险。误报会打断体验，漏报会直接放过攻击。很多通用模型看起来”能答”，也能给出一本正经的解释，但真到 Web prompt injection 这种多模态、环境驱动、执行型风险上，漏检问题非常明显。WebAgentGuard 的优势，在于它是围绕这个任务单独训练出来的。

真实环境的收益

论文没有停留在分类分数，而是把 WebAgentGuard 直接接到了两个 Web Agent 框架上：Claude Agent（Claude 3.7 Sonnet）和 Browser-use Agent（Gemini 2.0 Pro）。在没有防御时，Browser-use Agent 在 Amazon、Booking、BBC 三个场景上的攻击成功率分别高达 96.5%、84.2%、84.2%；Claude Agent 对应是 31.7%、36.7%、16.7%。

接入 WebAgentGuard 后，结果非常明显。对于 Browser-use Agent，WebAgentGuard-8B 在三个站点上都把攻击成功率压到 0%；Claude Agent 接入后分别降到 1.7%、0%、0%。

这部分结果的意义非常直接：Guard 不是一个离线检测器，而是一个能进入执行链路、并且真的改变实际攻击成功率的运行时组件。

对可用性的影响

有影响，但整体可控。论文在 WebArena 的 Shopping 和 Map 两类任务上测试了 Guard 接入后的效用变化。结果显示，开启 Guard 后，任务成功率会有小幅下降，尤其在 Shopping 场景里更明显；但如果允许一次用户验证，这部分损失可以被部分拉回。

时延方面，WebAgentGuard-4B 推理约 2.15 秒，8B 约 3.24 秒；而不同 Web Agent 生成动作通常需要 5.43 到 7.74 秒。由于 Guard 和 Agent 是并行运行的，Guard 的耗时短于 Agent 本身，因此不会明显拉长端到端执行时间。

RL 到底有没有用

论文的消融结果很有意思。以 8B 为例，基础模型在作者数据上的 Accuracy 是 53.20，加上 SFT 后直接到 99.20；只做 RL，仍然是 53.20，几乎没有提升。到了 SFT+RL，在 VPI-Bench 上 Recall 从 84.31 进一步提高到 87.58。

这说明在这种安全裁决任务里，先把结构化输出和基础安全推理训稳，比直接上强化学习更重要。模型连模板都学不会时，RL 很难给出稳定有效的优化信号。等 SFT 先把”该怎么看网页、怎么识别注入、怎么按格式输出判断”这些基本能力立住后，RL 才能进一步把边界做细。

局限性

第一，数据核心仍然是合成数据。 虽然作者尽量把主题、页面风格和注入方式做得很丰富，也做了外部数据集验证，但真实互联网里的长尾网页、动态脚本行为、复杂多轮状态切换，依然可能超出当前训练分布。

第二，它解决的是检测与拦截，还没有走到”识别攻击后，如何安全恢复任务流程”这一步。 当前框架下，Guard 给出的主要是允许、拒绝和人工确认信号。对于很多企业场景来说，这已经很有价值，但离完整的”安全执行编排层”还有一段距离。

第三，论文没有重点考虑 white-box 场景下的针对性攻击。 现实中，攻击者通常拿不到 Guard 参数，这个假设在商用系统里往往成立；但如果未来某类 Guard 被大量复用，它仍然可能面临长期探测和自适应绕过问题。

三点启发

第一，Web Agent 的提示注入防御，应该从”提示词设计问题”升级为”运行时控制面设计问题”。 只把 system prompt 写得更严，远远不够。真正关键的是：风险判断能不能独立完成，风险信号能不能进入动作执行链路。

第二，Guard 最好单独训练，而且要同时看文本和视觉。 在网页场景里，攻击不会只出现在 DOM，也不会只出现在对话文本。一个只看单模态的安全组件，很难覆盖真实攻击面。

第三，产品化落地时，Guard 应该尽量走并行推理 + 前置网关 + 必要时用户确认。 这篇论文给出的，不只是一个新模型，更像是一套可以被 Agent 平台直接吸收的架构思路。对浏览器 Agent、办公自动化 Agent、企业助手、RPA+LLM 系统来说，这条思路都有参考价值。