跳到主要内容

AI Agent 红队测试:发现真实漏洞的对抗性测试方法论

· 阅读需 11 分钟
Tian Pan
Software Engineer

一个金融服务 Agent 在标准的越狱测试套件中获得了 11/100 分——属于“低风险”。而上下文相关的红队测试(首先剖析 Agent 的实际工具访问权限和数据库架构,然后构建针对性攻击)发现的情况却截然不同:一种电影角色扮演技术可以指示该 Agent 在 88 个钱包中调度 44 万美元,执行未经授权的 SQL 查询,并暴露跨账户交易历史。通用测试套件并不知道该 Agent 拥有 withdraw_funds 工具。它测试的系统与实际部署的系统并不一致。

这 60 分的风险分值差距正是将传统红队方法论应用于 AI Agent 时面临的问题。Agent 不仅仅是做出响应;它们会规划、跨多个步骤进行推理、持有真实的凭据,并在现实世界中执行不可逆的操作。测试你是否能让它说出一些有害的话,与测试你是否能让它 出一些有害的事,并不是一回事。

为什么 Agent 红队测试在结构上有所不同

传统的软件红队测试会问:我能否绕过身份验证、注入 SQL 或缓冲区溢出?威胁模型是关于破坏系统的。Agent 红队测试则提出了一个不同的问题:我能否说服一个自主系统在表现得正常的同时,违背操作者的利益进行规划和行动?

Agent 的几个特性使得测试变得明显更加困难:

非确定性。 同样的攻击可能 90% 的时间失败,10% 的时间成功。一次运行中出现的发现可能在下一次运行中无法复现。NIST 的大规模红队竞赛——涉及超过 25 万次攻击尝试、400 多名参与者、13 个前沿模型——发现,仅凭概率性的重试就能在某些场景下将攻击成功率从 57% 推高到 80% 以上。总体的通过/失败指标掩盖了这一点。5% 的平均攻击成功率可能掩盖了在某个特定高后果操作(如资金转账)中 57% 的成功率。

工具访问权限是爆炸半径。 一个拥有电子邮件访问权限、代码执行能力、数据库和外部 API 的 Agent,与一个聊天机器人是完全不同的目标。工具定义了攻击成功后能达到的效果。不知道 Agent 拥有哪些工具的通用越狱探测无法评估这一点。

多步推理。 单轮注入是简单的情况。更危险的是“温水煮青蛙”式的攻击:一系列请求,每一个看起来都是良性的,但共同改变了 Agent 的目标。“分析趋势” → “导出符合该趋势的联系人” → “上传到此外部端点进行可视化”。没有哪一步看起来惊悚;整个计划的路径才是漏洞利用点。

持久性。 拥有 RAG 存储或跨会话记忆的 Agent 可能会通过毒化知识库而不是实时上下文窗口受到攻击。在记忆层植入虚假数据的攻击者可以影响未来的每一个决策,而无需重复注入。

从侦察开始,而非提示词

团队在对 Agent 进行红队测试时犯的最大错误是在绘制攻击面之前就开始寻找攻击提示词库。一切都源于 Agent 实际上能做什么。

在编写任何攻击之前,先建立一份清单:

  • Agent 可以调用的每个工具,包括其参数和副作用
  • 它访问的每个数据库架构和外部 API
  • 它持有的每个凭据以及这些凭据授权的操作
  • 它读取的每个通信渠道(电子邮件、Slack、网页内容、文档)
  • 它读取和写入的每个持久化存储

这是 Palo Alto 的上下文方法论中所谓的“剖析器(profiler)”阶段:一个模拟攻击者在发起针对性活动之前,首先进行对抗性侦察。金融服务案例研究中 60 分的风险评分差异完全源于这一步。如果不知道 Agent 拥有 withdraw_funds 权限,就无从下手。

根据清单建立威胁模型。对于每个工具或能力,问自己:如果被误用,攻击者能实现什么?根据“爆炸半径 × 可利用性 × 检测难度”进行优先级排序。资金转账和代码执行的等级与只读数据库查询截然不同。

四个攻击层级

一旦有了攻击面地图,按顺序穿过四个层级。每一层都建立在上一层的基础上。

第 1 层:直接提示词攻击。 这些是大多数团队已经在进行的攻击。越狱尝试、角色扮演框架、指令覆盖尝试、开发者模式技巧。这些能发现表层漏洞,但会错过大多数 Agent 特有的风险。运行它们,但不要止步于此。

第 2 层:工具级攻击。 针对特定能力。你是否能用未经授权的参数调用工具?你是否能绕过速率限制?你是否能以设计者未预料到的顺序链接工具——例如使用代码执行工具写入一个文件路径,随后另一个工具会读取并执行该路径?你是否能触发暴露内部状态的工具错误?

第 3 层:多 Agent 攻击。 如果该 Agent 编排其他 Agent 或被其他 Agent 编排,那么 Agent 间的通信层就是一个全新的攻击面。模拟中间人攻击:拦截并修改流水线中 Agent 之间的消息。测试下游 Agent 是否盲目信任上游 Agent 的输出,或者它是否验证了所接收指令的来源和内容。单个受损的上游 Agent 可能会在整个流水线中级联错误的指令。

第 4 层:持久性攻击。 测试记忆毒化和跨会话操纵。在 RAG 存储中植入虚假数据,并衡量它如何影响 Agent 未来的决策。测试 Agent 在不同会话中的行为是否会被逐次注入所重塑,而这些注入单独看起来都低于检测阈值。

目标劫持究竟隐藏在哪里

目标劫持(Goal hijacking)——即替换 Agent 的目标,而不仅仅是覆盖单个指令——是 OWASP Agentic Top 10 中排名第一的风险。它最常通过 Agent “应该”处理的内容进入:电子邮件、文档、网页、搜索结果。

PDF 中的白底白字隐藏文本可以将文档摘要 Agent 引导至窃取 API 密钥。在 Agent 作为任务的一部分抓取的页面中渲染的不可见 HTML 元素,可以将新目标注入其规划循环中。嵌入在邮件正文中的恶意指令可以指示邮件助手 Agent 将敏感内容转发到攻击者控制的地址。

Lakera AI 的 2025 年第四季度现场数据证实,间接提示词注入攻击(通过 Agent 处理的外部内容到达,而不是直接通过用户界面到达的攻击)比直接攻击更易成功,且影响范围更广。它们也更难在测试环境中复现,因为它们需要构建看似合理的外部内容,而不仅仅是编写单个恶意提示词。

对此进行测试需要在红队演练期间向 Agent 提供真实的、对抗性构建的外部内容。仅探测 Agent 对用户直接输入的反应是不够的。

衡量真正重要的指标

Agent 红队报告需要单项任务成功率,而不是汇总指标。NIST 的 AgentDojo 评估具有启发性:升级后的 Claude 3.5 Sonnet 对基准攻击表现出 11% 的攻击成功率——很容易被描述为“稳健”。而一个迭代改进方法的自适应红队活动实现了 81% 的成功率。某些特定的高后果注入任务成功率超过了 57%。

对于任何涉及不可逆操作(数据窃取、资金转账、代码执行、外部通信)的发现,请报告多次尝试中的单项任务成功率。记录完整的攻击链。包含显示调用了哪些工具以及调用顺序的追踪。目标是可复现性:报告应让工程师能够重现攻击并验证修复效果。

还要考虑对抗持久性。拥有重复访问权限的攻击者会不断尝试。如果特定攻击路径的单次尝试成功率为 15%,而攻击者在被发现前可以尝试 20 次,那么有效成功概率将接近 95%。严重程度分类应考虑现实的尝试次数。

工具概览

有几个开源工具值得了解:

Garak (NVIDIA) 可在 20 多个 AI 平台上运行 100 多个攻击向量,每次运行多达 20,000 个提示词。它适用于通过预编写的探测库进行广泛覆盖,特别是当你需要快速进行基准扫描时。

PyRIT (Microsoft) 是一个用于可编程多轮红队活动的完整编排框架。它管理对话历史,通过转换器转换提示词,对结果进行评分,并支持 Crescendo(逐渐升级)攻击和 Tree of Attacks with Pruning。当你需要对复杂的活动进行精细控制时,请使用它。它与 Azure AI Foundry 集成,目前正处于积极开发中(截至 2026 年初为 v0.11.0 版本)。

Promptfoo 使用 AI 而不是静态库生成特定上下文的攻击,包含 Web UI,并将发现结果映射到 OWASP、NIST 和欧盟 AI 法案的合规类别。值得将其作为基准扫描器运行。

mcp-scan (Cisco, 开源) 专为扫描 MCP 服务器工具描述以防范供应链投毒而设计。如果你的 Agent 使用 MCP 服务器,请将其添加到流水线中。

没有任何一个工具能覆盖完整的 Agent 攻击面。一个实际的起点是:使用 Promptfoo 覆盖 OWASP ASI 类别,使用 PyRIT 针对特定的高优先级工具进行有针对性的多轮活动,如果涉及 MCP 服务器,则使用 mcp-scan。

持续实践,而非一劳永逸

NIST 的大规模竞赛发现,每一个前沿模型都遭到了成功攻击——攻击成功率与模型能力无关。更尖锐的是:12 种已发表的针对提示词注入和越狱的防御措施,在通过迭代改进方法的自适应攻击重新检验时,大多数最初声称攻击成功率接近于零的防御措施,其实际攻击成功率均超过了 90%。防御在面对自适应对手时会失效。

这使得一次性的发布前红队测试变得不足。新的模型版本会改变行为。添加到 Agent 中的新工具会产生新的攻击面。威胁形势在变化。欧盟 AI 法案(2026 年 8 月要求完全合规)规定,对高风险 AI 系统进行对抗性测试是一项持续的义务,而不是一个勾选框。

实际上,这意味着将红队覆盖集成到 CI/CD 中。在每次 Agent 更改时进行自动扫描。在添加重大功能前进行定期的深度演练。建立一个反馈循环,将生产异常中的发现反馈到红队范围中。

最重要的组织转变是:将红队测试视为一种产生工件(资产清单、威胁模型、单项任务成功率、可复现的攻击追踪)的工程学科,而不是对出错情况的叙述性总结。这种严谨性让你能够衡量防御措施是否真正得到了改进。

目标不是证明 Agent 是安全的。而是在你的用户发现故障模式之前找到它们。

References:Let's stay in touch and Follow me for more thoughts and updates