ST-WebAgentBench：评估 Web Agent 安全与可信度的基准

现有网页智能体基准只记任务是否完成，不记完成时是否遵守安全与可信任约束。

• 采用前提：作者认为，自主网页智能体要进入关键工作流，必须避免非预期或不可逆动作，并遵守组织、用户或任务规则。作者引用 Tian et al. (2023) 与 Yu et al. (2025)，称底层 LLM 安全并不保证智能体系统安全；并引用 Kumar et al. (2024)，称嵌入浏览器控制器后越狱仍可能成功。
• 现有基准：Table 1 中 MiniWoB++、Mind2Web、WebVoyager、WebArena、VisualWebArena、WorkArena、WebCanvas 只报告完成率，不评策略遵守、人在回路或模态挑战。作者称，编造数据或删错记录仍可能在旧指标下得高分。
• 作者认为缺的条件：可信评测应同时有真实端到端任务、冲突策略层级（organization > user > task）、应用漂移（界面或业务逻辑在智能体训练后变化），以及允许推迟行动的人在回路钩子。
• 给出的基准：ST-WebAgentBench 含 375 个任务和 3,057 条策略，覆盖六个维度，并用 Completion under Policy（CuP）、Partial CuP（pCuP）和 Risk Ratio 打分。作者称这是面向企业级评测的第一步，也是把完成与合规放在一起的首个端到端框架。

作者按网页导航基准、运行时控制和安全评测来定位本文，并称这些工作没有在网页工作流上同时做多维策略计分。

网页智能体基准

• 任务完成导向：早期工作用浏览器仿真（Shi et al., 2017; Liu et al., 2018）。WebShop、RUSS、Mind2Web、WebVoyager 评离线导航；WebLinX、WebArena、VisualWebArena、WorkArena、WorkArena++、WebCanvas 评在线交互。作者称它们主要看完成和中间步骤。
• 仍不评策略：WebCanvas 另测关键节点完成率；AgentBench（Liu et al., 2023a）评多种任务上的 LLM 智能体，重点是底层模型。作者称这些基准忽略策略合规与安全。

运行时控制

• 动作约束：GuardAgent 用知识推理执行安全措施；论文称 AutoGen 以多智能体对话动态调整安全协议，并引用 Zeltyn et al. (2022)；SteP 与 Agent-E 试图控制动作。作者称这些控制器仍难保证完全合规，本文则是与应用无关、对每次违规打分的评测层。
• 嵌入后的越狱：Kumar et al. (2024) 讨论拒答训练模型作为浏览器智能体时仍易被越狱。作者并引用 Schwartz et al. (2023)、Anthropic (2024) 和 Microsoft (2024)，称规划、记忆加浏览器控制的架构难以满足企业规章。

安全评测与分类

• 其他场景的基准：SafeAgentBench 看模拟家居中的危险指令，Agent-safetybench 看工具安全失败，ASB 形式化提示注入和后门，R-Judge 给事后日志打分，MLCommons（Vidgen et al., 2024）量化单轮对话伤害，Chen et al. (2025) 讨论 GUI 智能体的隐私与安全评测。作者称它们都未建模网页工作流、编码多维 ST 策略，或把违规追溯到具体 UI 动作。
• 风险分类：Huang et al. (2024)、Liu et al. (2023b) 与 Shamsujjoha et al. (2024) 被用来整理非预期动作和系统失败等风险，作为维度推导的背景，而不是与本文比分数。

基线与环境

• 没有单独的安全检测基线：被评测的是 AWM、WorkArena-Legacy 和 WebVoyager。任务来自 WebArena 的 GitLab、ShoppingAdmin，并新增 SuiteCRM。Table 1 比的是基准是否含策略遵守、人在回路和模态挑战，不是各基准上的分数。

作者把本文与运行时控制器分开：控制器试图约束动作，本文是挂到每个任务上的评测层，并用 CuP 等指标把合规和完成一起计分。

ST-WebAgentBench 建在 WebArena 与 BrowserGym 上。每个任务带一条或多条策略，评估函数同时判定任务检查是否通过，以及六个安全与可信任维度上的违规。

问题设定与策略层级

• 操作者与环境：附录 G.1 假设人是良性的，意图与组织一致；网页环境只是部分可信，页面和记录里可以有误导文本、对抗文本、不得复用的敏感值，以及弹窗或未完成表单。主要威胁被写成智能体自身的不安全行为。
• 范围内的四类：环境中的提示注入、编造输入、策略冲突处理错误、未经同意就做高影响动作。网络层攻击、模型权重威胁、供应链破坏和多智能体共谋在附录 G.1 被标为范围外。
• 三级优先级：动作前要调和组织策略 Porg、用户偏好 Puser 和任务指令 Ptask，次序为 Porg ≻ Puser ≻ Ptask。允许动作集写为 H_t={a∈ A(S_t):a satisfies P_org∧ P_user∧ P_task}，即动作须同时满足三层。违反 Porg 被定为安全失败；违反 Puser 或 Ptask 分别损害可信任和任务成功。
• 扩展方式：新任务用 JSON 实例化可复用模板，并填入该模板的参数，例如禁止 URL、确认字符串或被监视的字段。附录 D 给出各维的缩短配置。

六个维度与模板

• 怎么定出六维：先从 36 份事件摘要和既有框架得到 10 个种子维度，再由 10 名资深企业相关方回答三类问题。合并后留下六维。作者称它们解释了 95% 被引用的事件原因。附录 B 给出专家提及次数：User Consent 10/10、Boundary 9/10、Strict Execution 8/10、Hierarchy 7/10、Robustness 6/10、Error-Handling 6/10。
• 维度与模板：User Consent 用 ask_the_user，不可逆操作前征求确认。Boundary & Scope 用 access_management、navigation_limitation。Strict Execution 用 irreversible_actions、hallucinated_information。Hierarchy Adherence 用 policy_contradiction。Robustness & Security 用 jailbreaking、sensitive_information。Error Handling 用 popup_error、missing_params。
• 数量为何不均：作者解释，同意和严格执行最多，因为它们守住不可逆动作，而且确认提示和取值核对容易编码。边界、鲁棒和错误处理依赖特定页面状态，只在能增加诊断信号时注入。层级冲突较少，但出现时是关键，因此保证覆盖而不让该维主导。
• 策略计数：Table 2 合计 3,057 条。Boundary 1,120，Strict Execution 959，Security & Robustness 386，User Consent 322，Hierarchy 152，Error Handling 118。

指标

• 完成：Ct 仅当该任务的全部成功检查通过时为 1，CR 是 Ct 的任务平均。长流程任务可只通过部分检查，PCR 统计至少通过一项检查的比例。
• 合规完成：单任务 CuP 为 CuP_t=C_t1[∑_d V_dt=0]，即完成之外还要求各维违规之和为零，再对任务平均。pCuP 把同一零违规条件用到部分完成上。作者认为这样既不奖励未完成，也不奖励带违规的完成。
• 风险与重复：Risk Ratio 用该维违规量除以该维策略数，表示按策略数归一的违规频率。公式中的 all-pass@k 是 k 次运行全部完成的任务比例；k=1 时等于 CR。作者称指标设计与 safe-RL（Gu et al., 2022）及 Kara et al. (2025) 把有效性和合规合在一起的主张一致。

任务、注入与判定

• 应用与分档：GitLab 197 个任务，平均 7.8 条策略；ShoppingAdmin 8 个任务，平均 8.1 条。SuiteCRM 在 Table 2 中分成 General 30（平均 12.6）、easy、medium、hard 各 20（平均 7.0、11.4、18.6）。正文称难度分三档、各 20 题。
• 模态挑战：另有 80 题，Vision-Advantage 与 DOM-Advantage 各 40，平均各 4.2 条策略。前者的关键信号只在像素层，后者只在语义 HTML 和 ARIA 中。Section 3.5 与图 12–16 用配色、旋转、画布、屏外行和隐藏属性说明这种拆分，正文未在这里给智能体分数。
• 评估函数：包括 element_action_match、is_sequence_match、is_url_match、is_ask_the_user、is_action_count、is_program_html、is_sensitive_data、is_input_hallucination。询问用户和弹窗错误的消息用 RapidFuzz 对照策略模板做字符串相似度。附录 H.3 称整体判定是确定的，不用 LLM 裁判。
• 如何把策略交给智能体：Section 4.2 写每次观察都附加 POLICY_CONTEXT。附录 E 写约束放在任务指令之前，运行时填入当前任务的策略，并放进系统提示。人在回路是自动批准的模拟确认，强制请求仍要通过对模板的模糊匹配。动作空间在 BrowserGym 上增加 human_in_the_loop。作者称实现同一 API 的网页智能体都可被评测，并计划把扩展贡献回 BrowserGym。

实验设置

• 被测智能体：AWM（AgentWorkflowMemory）、WorkArena-Legacy、WebVoyager，均不改代码。论文给 AWM 和 WorkArena-Legacy 标注的 WebArena 排行榜成功率是 35.5% 和 23.5%，这不是本基准的分数。结论写三个智能体共享 gpt-4o 骨干；Section 4.1 未再写模型版本。
• 任务：375 个任务、3,057 条策略，应用为 GitLab、ShoppingAdmin、SuiteCRM。规模与分档见 Table 2，包括 80 个 Modality Challenge 任务。
• 指标：CR、PCR、CuP、pCuP、Risk Ratio、all-pass@3。Section 4.1 写全部指标使用 pass@3，三次中任一次成功即计成功。Section 3.3 的 all-pass@k 公式只要求每次都完成；Section 4.2 称图中的 all-pass@3 还要求每次都策略合规。
• 判定：不用 LLM 裁判。完成和违规由评估函数判定；需发消息时用 RapidFuzz 对照模板（附录 H.3）。
• 运行：GitLab 与 ShoppingAdmin 用 WebArena AMI 托管在 AWS，SuiteCRM 在本地 Docker。机器为 MacBook Pro（M1，32 GB）。每个智能体执行一遍 375 任务，平均每任务 4 分钟，合计约 12 小时。结论另称因 API 成本使用 pass@k。
• 策略送达：POLICY_CONTEXT 附在每次观察上，写入层级和当前规则。用户确认由自动批准的模拟机制放行，请求本身仍做模糊匹配。

主结果

下表只收正文点名的 pass@3 数字。平均一行出自引言，其余出自 Section 4.2。正文没有单独给出的格子写未报告。

表格较宽，可左右滑动

智能体	CR	CuP	PCR	all-pass@3
AWM	未报告	20%	46.9%	5.0%
WebVoyager	12.8%	10.3%	未报告	2.0%
WorkArena-Legacy	26%	15%	未报告	3.0%
三智能体平均	24.3%	15.0%	未报告	未报告

• 作者的总判断：作者称原始完成率不是企业就绪的可靠代理。摘要称平均 CuP 不到名义完成率的三分之二。引言称相对下降约 38%，并称大约 38% 的已完成任务至少违反一条策略，约 62% 的名义完成满足全部策略。
• 分智能体的违规：作者猜想 AWM 的经验学习在推进任务时绕过 ask_the_user，并报告同意违规 37 次、risk ratio 0.44%。WorkArena-Legacy 为同意 4 次、严格执行 16 次。WebVoyager 的这两维风险被写为 0.176 与 0.221。作者称它的完成率与 CuP 差距窄，是因为很少到达策略适用的状态，不是因为动作更安全。
• 重复与图注：作者把 all-pass@3 偏低归因于运行间脆性。Figure 2 文字层还可见 33.8、26.9、23、17.5、18.7，正文未把它们逐项对应到图例，故未写入上表。结论另称完成率最高到 34%，约 70% 的违规集中在同意和严格执行。

维度影响

• 测了什么：作者把完成率与 CuP 做相关。六维都约束时 ρ_full = 0.48。去掉一维 d 后重算 CuP，Table 3 用 Δρd > 0 表示强制该维会压低完成与安全的对齐，因而该维重要。
• Table 3：去掉 Consent、Boundary、Strict、Hierarchy、Security、Error 后，ρ 分别为 0.61、0.50、0.63、0.55、0.57、0.51，Δρd 为 +0.13、+0.02、+0.15、+0.07、+0.09、+0.03。
• 作者的解读：作者称六维都有贡献，同意和严格执行占了大部分错位；边界和错误处理的变化较小，并称这与 Figure 2 中较低的违规率一致。纯文本看不到各维柱高。作者另假设边界规则出现在长流程后段，所以很少被触发，而同意和执行检查早且频繁。

策略负荷

• 测了什么：附录 C 把 375 个任务按活跃策略数分成 1、2–3、4–5、多于 5 四箱，重算 CR、CuP 和平均每任务 Risk Ratio。
• 结果：CR 的 Spearman ρ = −0.14。CuP 从 1 条策略时的 18.2% 到多于 5 条时的 7.1%，ρ = −0.71，p < 0.001。引言把同一组端点写成“五条及以上”。每任务风险比随模板数上升，斜率 0.11 ± 0.02。中间两箱的 CuP 正文未给出。
• 作者的解读：作者称当前智能体缺少同时处理多条约束的机制；若五条左右就下降，企业里几十条并存时差距会更大。图 3 的图注称 CR 保持平、CuP 下降、风险比随策略数上升，误差棒被省略。

其他消融与分析

• 智能体实验里其余带数字的分析就是 Table 3 和附录 C；论文未再单列其他超参数扫描。
• 作者称边界类规则很少触发，同意和严格执行模板主导风险分布（Section 4.2）；结论中的 70% 未在 Table 3 里另行分解。

作者指出的局限与后续方向

• 智能体范围：只评测三个开源智能体，共享 gpt-4o；未纳入专有 computer-use 栈，例子是 Claude、Gemini 2.5、Kimi，原因是目前缺少稳定的 BrowserGym 式集成。作者称目标是可复用基准，不是覆盖全部商业系统的排行榜（Conclusion）。
• 任务范围：作者称 375 个任务和三个应用只是真实工作流的一片，只做英语交互，领域范围有限，并属早期覆盖；同时称六维与领域无关（Conclusion）。
• 重复预算：作者称因前沿 LLM 的 API 成本，任务用 pass@k 评估（Conclusion）。
• 策略与对抗：作者称模板编码的是一套特定优先级，层级为 organization > user > task；鲁棒性检查聚焦提示注入，而不是完整对抗图景（Conclusion）。附录 G.1 把网络层攻击、模型权重威胁、供应链破坏和多智能体共谋标为范围外。
• 后续工作：作者称基准是基础而非部署门禁，并计划增加数据点、智能体和策略合规，用真实交互记录与 LLM 自动标注扩展（Conclusion）。附录 I 的策略控制器是建议架构，不是已评测系统。
• 维度来源：附录 B 写明十名专家虽来自不同部门，但共享组织语境，可能引入偏差；作者把六维视为起点，并邀请跨行业参与。

实验覆盖范围

• 被测系统：Section 4.1 运行 AWM、WorkArena-Legacy、WebVoyager，不改代码；结论写明共享 gpt-4o。35.5% 与 23.5% 是 WebArena 排行榜参照。
• 任务构成：Table 2 为 375 个任务、3,057 条策略。GitLab 197，ShoppingAdmin 8；SuiteCRM 为 General 30，easy、medium、hard 各 20，两种 Modality 各 40。
• 已报告分析：Section 4 在 pass@3 下报告 CR、CuP、PCR、分维度风险和 all-pass@3；Table 3 去掉一个维度后重算相关；附录 C 按策略数 1、2–3、4–5、多于 5 分箱。
• 判定：附录 H.3 写明不用 LLM 裁判，询问用户和弹窗错误用 RapidFuzz。Section 3.6 的人在回路是自动批准的模拟确认。
• 论文未报告的项：论文未报告 Modality Challenge、难度分档和三个应用分开的 CR 或 CuP；未说明 pass@3 与“每个智能体执行一次”如何对应；未报告与人工判定的一致性。

ST-WebAgentBench 用来检查网页智能体做完企业式浏览任务时，有没有同时守住安全与可信任策略。

• 问题：既有基准多只报完成率。作者认为组织规则、用户偏好和当前任务可能冲突，智能体仍可能编造字段或做不可逆操作并拿到高分。
• 做法：375 个任务分布在 GitLab、ShoppingAdmin 和 SuiteCRM，配 3,057 条策略和六个维度。规则经 POLICY_CONTEXT 进入观察。人在回路用模拟确认，请求文本用 RapidFuzz 对照模板，不用 LLM 裁判。CuP 要求成功检查全部通过，且违规向量为零。
• 主结果：pass@3 下三个开源智能体平均 CR 为 24.3%，平均 CuP 为 15.0%。AWM 的 PCR 为 46.9%、CuP 为 20%；WebVoyager 的 CR 为 12.8%、CuP 为 10.3%；WorkArena-Legacy 的 CR 为 26%、CuP 为 15%。AWM、WebVoyager、WorkArena-Legacy 的 all-pass@3 为 5.0%、2.0%、3.0%。
• 策略变多：附录 C 中，1 条策略时 CuP 为 18.2%，多于 5 条时为 7.1%。作者称同意和严格执行解释了大部分完成与合规的错位。
• 作者的结论：只优化完成率会放过违规成功，当前智能体还不能直接用于高风险企业流程。作者把该基准当作可扩展的起点，而不是上线门禁。