系统:运行中
← 返回所有攻击
RESEARCH MEDIUM NEW

Vera:大规模安全测试发现工具型智能体 93.9% 的失败率

2026 年 7 月的一个框架自动生成 1600 个可执行安全用例,并依据真实环境状态判定结果——揭示当工具返回被篡改时,生产级智能体几乎全面失守。

2026-07-06 // 6 min affects: ai-agents, tool-use, computer-use-agents, claude-code, codex

这是什么?

Vera 是一个面向工具型 LLM 智能体的自动化安全测试框架,相关论文于 2026 年 7 月 2 日发布在 arXiv 上(arXiv:2607.01793)。其动机源于当前智能体安全度量方式的一个现实局限:现有测试套件大多针对一组固定的、由专家设计的违规行为,并用硬编码规则来评判,因此每当智能体获得新工具、或攻击者找到新手法时,扩展这些套件的成本都很高。Vera 将该问题重新表述为对非确定性系统的软件测试:一条自我强化的流水线,从文献中发现风险,将其编译为可执行的测试用例,并依据环境中真实发生的情况来验证结果,而不是依据模型声称自己做了什么。

主要结论发人深省。在四个生产级智能体框架上——论文列出了 OpenClaw、Hermes、Codex 和 Claude Code——在最强的测试条件下,攻击平均成功率达到了 93.9%。作者还发布了 Vera-Bench,一个公开的、包含 1600 个可执行安全用例的集合,覆盖三种执行设置下的 124 个风险类别。

工作原理

Vera 分为三个相互衔接的阶段。首先,持续风险探索阶段阅读研究文献,将新出现的问题组织成三套不断扩充的分类体系:安全风险、攻击方法和工具执行环境。其次,可执行测试用例构建阶段将这些分类体系中的元素组合成具体用例。每个用例是一个三元组:一个具体的安全目标、一个由程序构建的初始环境状态,以及一个确定性的验证谓词——因此「用例」是带有机器可校验成功条件的可运行场景,而非散文式描述。最后,自适应执行阶段在隔离的、带状态的沙箱中运行目标智能体。

对防御者而言最重要的设计细节是威胁模型,它区分了攻击者施加影响的两个通道。每个基础场景被扩展为三种变体:无对手的良性基线;对手仅控制用户消息的单通道变体;以及对手额外篡改工具返回结果的多通道变体。这种篡改通过一个可配置的「工具网关」完成——它以 Model Context Protocol 上的中介服务实现——位于智能体与每个工具端点之间,能够以四种模式之一改写工具返回值:identity(不变)、append 或 prefix(攻击者内容与真实结果并存),或 override(结果被完全替换)。

# 威胁模型通道(示意;无可操作载荷)
良性        -> 无对抗性输入
单通道      -> 攻击者仅控制「用户」消息
多通道      -> 攻击者「还会」改写「工具返回」
             模式:identity | append | prefix | override

另有两个部分让结果可信而非轶事。一个控制智能体将每次测试驱动为多轮对话:先建立一个可信的合法任务,再逐轮自适应——被拒绝后重新措辞,当智能体选用意外工具时改变策略,或当被污染内容未被检索到时改变注入点。而一个基于证据的验证器通过检查记录的工具调用和最终环境状态来判定安全目标是否真正达成,并且明确地采用智能体的自我报告。由于已部署的框架会暴露工具调用与响应、却通常不暴露内部推理,Vera 依据已执行的动作及其可观测效果来评判安全性。

为什么重要

三种设置之间的差距才是真正的发现。当只有用户提示是对抗性时看似可接受的智能体,一旦工具返回通道也被攻陷,就变得高度可被利用——正是多通道条件产生了 93.9% 的平均值。这为防御者早已怀疑的一条原则提供了直接且有量化的论据:在智能体中,工具输出是不可信输入,任何只对用户提示做扰动的测试,都会严重低估真实暴露面。

验证方法带来第二条教训。通过询问模型是否做了有害之事来判定智能体安全性并不可靠;将结论锚定在环境状态和工具调用证据上,会改变你究竟能看到哪些失败。对于自建智能体评测的团队而言,这一区分——可观测产物优于自我报告——其重要性大概不亚于任何单一的攻击数字。这项工作被定位为防御性评估基础设施,发布的是基准而非可直接使用的漏洞利用,且以开放许可与公开代码发布。

防御

  • 将每个工具返回都视为不可信输入。 多通道结果表明,工具响应通道是智能体失守最严重之处。在工具输出重新进入模型上下文之前,对其进行校验、净化,并在可能时签名或标注来源;切勿仅因为工具是被合法调用的,就假定其结果是真实的。
  • 测试工具通道,而不仅是提示。 在你的智能体红队测试中加入「工具返回被攻陷」这一条件。只改变用户消息的套件复现的是单通道设置,会漏掉此处导致几乎全面失败的暴露面。
  • 依据可观测产物验证结果,而非自我报告。 通过检查最终环境状态和记录的工具调用轨迹来判断一次运行是否安全,而不是让智能体给自己打分。记录完整的工具调用历史,才能实现事后验证与监控。
  • 对每次测试运行进行沙箱隔离。 Vera 为每次执行提供各自的智能体实例、网关和外部服务。在你自己的测试中照做,使各用例之间互不污染,并使触发破坏性动作的测试无法触及任何真实资源。
  • 保持风险目录的更新与组合性。 静态检查表老化很快。定期刷新你所测试的风险、攻击方法与环境集合,并加以组合,使覆盖面跟上智能体不断扩展的工具面,而非滞后其后。
  • 在工具网关上实施最小权限。 如果一个中介层能够为测试改写工具流量,它在生产中同样能做到。限制一个智能体会话能触及哪些工具,并将不可逆或高影响的动作置于确认之后。

状态

项目
成果Vera —— 智能体安全测试框架;Vera-Bench 基准
披露arXiv 预印本,2026 年 7 月 2 日(CC BY 4.0)
范围1600 个可执行安全用例;124 个风险类别;三种执行设置
受测框架OpenClaw、Hermes、Codex、Claude Code
实测影响多通道(工具返回)攻击下平均成功率 93.9%
性质防御性评估研究;公开代码,未发布可操作漏洞利用

关键日期:2026 年 7 月 2 日 —— Vera 与 Vera-Bench 首次发布于 arXiv。这是一个测试框架与基准,并非针对某个具名部署的真实事件。

本文出于防御目的,总结公开可得的安全研究。

Sources