AI 红队测试详解：红队测什么，又会留下什么

大多数 AI 红队评估项目都以错误的成果物来评判。一周的工作产出一份幻灯片，幻灯片上说助手可以被诱导写出钓鱼邮件，而事后没人能说清这种行为是否可复现、有多严重，或者哪项控制措施本可阻止它。这门学科有真正的产出，而且不是幻灯片：它是一组经得起重新运行的发现，每一条都对应一个被越过的边界，以及越过该边界的证据。这也正是AI 事件档案所保存记录的样子——400 条条目，覆盖 2024 年 12 月至 2026 年 10 月，取自 743 个不同来源，并对每一条都给出是否有人实际受到伤害的判定。

这种混淆可以理解，因为“red teaming（红队测试）”被用来指两项工作，而这两项工作除了共享词汇之外几乎没有共同之处。本指南将介绍这两者、各自应产出的证据，以及 AI 红队测试真正偏离大多数安全团队已经知道如何开展的网络版红队测试的四个地方。

框架问题：谁拥有测试

在讨论范围之前，还有由谁开展演练、针对什么开展演练的问题。Microsoft 就此发布了较为完整的公开立场之一，值得把它当作一张地图而不是产品页面来读。其 AI Red Team 中心区分了 概念层面的 AI 红队演练与 操作方法，然后按一种本身就是论证的顺序来编排这些实践：概述，接着是构建 LLM 红队的指南，然后是参考资料——用于对机器学习系统攻击进行分诊的缺陷门槛、机器学习故障分类法、共享责任模型，以及开发者威胁建模指南。

读懂这条序列，方法论自然就出来了。一套分类体系决定什么算作失败。一个缺陷门槛决定这些失败中哪些值得修复。一个共享责任模型决定一旦发现后由谁负责。威胁建模决定下一步该往哪里看。没有这四项，红队只是在编轶事，再硬加一列严重性，而这一列严重性不过是测试人员当天下午的感觉。

微软的开源自动化框架 PyRIT 被归入同一类目，而这一归类方式恰恰是有价值的部分。编排工具包并不等同于方法论；它只是当分类体系和缺陷门槛已经存在之后，你用来指向目标的工具。那些从框架入手的团队，往往最终得到的是庞大的提示语料库，却无从对结果进行排序。

两支红队，两个不同的问题

这个领域里最有用的一条区分，几乎没人会写下来：红队测试一个模型，和红队测试一个系统，回答的是不同的问题，测试对象不同、输出不同、负责人也不同。把二者混为一谈，正是越狱攻击被当作安全发现上报、真正的权限提升漏洞被登记为模型质量问题投诉的原因。

模型层面的安全评估是一个测量问题。你要问的是模型是否会生成某一类内容，而诚实的回答方式，是使用足够大的样本，以便对某个比率作出有意义的判断。被测单元是一层薄 API 背后的模型，方法是对抗性提示——越狱、人设攻击、多轮施压——而产出是一份对话记录加上一项危害判定。当权重发生变化，或供应商的安全层发生调整时，整个结果就过时了。这就是为什么这类测试通常由模型构建方或独立评估方来运行，也是为什么其发现很少能对应到你应用中的某个具体修复。

系统级对手模拟是一个工程问题。你问的是攻击者能否让已部署的系统采取行动——读取它本不该读取的文件、调用它本不该调用的工具、花费它本不该花费的钱。被测单元是附带了工具、检索能力和凭据的智能体。方法都是熟悉的那一套，只是重新定向：通过检索内容而非用户回合进行注入、工具滥用、由单个看似合理的权限拼装而成的权限链、跨越租户边界泄露的数据路径。输出是一项发现，包含复现步骤、被跨越的边界，以及明天就能更改配置的负责人。

两者产生不兼容的产物，而这种不兼容具有诊断意义，而不是令人困扰。模型层面的结果，你的团队无法“修复”，除非更换模型。系统层面的结果，供应商根本无法修复。如果一份报告没有说明它属于两者中的哪一种，你就无法对其中的任何条目作出归属判断。

一旦模型拥有工具，攻击面会变成什么样

大多数团队仍在测试的表面是提示词。它也是最无趣的一个，因为它是模型供应商投入最多精力去加固的那个，也是攻击者最难以施加影响的那个。真正有回报的表面是应用额外添加的那些：智能体可以调用的工具、它读取的检索索引、它在轮次之间携带的记忆，以及输出通道本身。

工具是语言模型成为行动者的地方，而有趣的问题从来不是“它能否调用这个工具”，而是“这个工具本来可以拥有的最小权限是什么”。一个接受自由文本查询的工单查询工具，通常可以被诱导接受另一个客户的标识符。检索是进入模型上下文的内容通道，这意味着任何能够写入语料库的人——共享驱动器、客服宏、抓取器能访问到的网页——都在写入提示词。记忆把单个回合变成持久化：在第二轮植入的指令到第四十轮仍然存在。输出是模型的文本落到某个会解释它的地方，而渲染、Markdown、链接预览以及与 shell 相邻的管道都会解释文本。

只测试提示词的评估项目会报告一份干净的结果，却在错误的问题上判断正确。

为什么转录稿不算研究发现

一项发现需要具备三个特性，而聊天窗口的截图并不具备这些特性。第一个是可复现性：从干净状态再运行一次，它还会再次发生。模型是非确定性的，因此可复现性是一个比率，而不是一个布尔值——“十次尝试中有九次”是一项发现，“只发生过一次”则是传闻。第二个是越界：要用应用自身的术语，而不是模型的术语，来指出本不该发生的事。不是“模型很无礼”，而是“智能体读取了属于租户 B 的文档”。第三个是可追溯到影响的严重程度，而不是测试人员的直觉；这正是缺陷门槛的作用所在。

其余一切——对话转录、提示词、模型的推理——都是支持那三项发现的证据。它本身并不是发现，这正是为什么一个由两千条越狱提示词组成的语料库，其价值不如五项可复现、且附有具名对照的系统性发现。

AI红队测试与网络红队测试的四个不同之处

来自网络或应用安全领域的团队带着良好的直觉，也带着四个错误的假设。

• 没有需要固守的边界。网络项目有目标清单；智能体项目则有一个上下文窗口，它在请求时由你可能尚未盘点过的来源组装而成。范围必须表述为数据源和工具权限，而不是主机名。

• 目标是非确定性的。同一输入周二可能成功、周三可能失败。这打破了“一次干净复现”的证据标准，并迫使你报告发生率。

• 利用手段是语言，而语言没有补丁。 你可以修复缺失的授权检查。你无法给“模型可以被说服”打补丁。对语言层面弱点的缓解措施是别处的控制——过滤器、范围限制、权限边界——这就是为什么发现项需要指明控制措施，而不只是行为。

• 供应商处在沟通闭环内。当其他人发布新版本时，你的目标就会发生变化。模型层面的结果只对你测试的那个构建版本有效；如果你没有记录版本和日期，就等于没有结果。

如何界定首次合作的范围

那些进展不顺的交付项目，几乎总是被界定为“测试 AI”。一个能经受排期考验的范围界定，更像是这样：一个智能体，在预发布环境中，使用生产形态的数据和生产形态的权限；一份列出五个关键边界的清单（租户隔离、凭据访问、支出、数据外泄、工具范围）；明确哪些属于越界范围的交战规则；说明谁可以中止运行的停止条件；以及一份已定义的、在第一次尝试之前达成一致的证据格式，以便报告由工件组装而成，而不是凭记忆重建。

授权值得单独用一句话说明，因为当测试目标是自家产品、而工具却由他人提供时，团队最容易跳过的正是这一项。测试一个并非由你运营的模型、在并非你拥有的基础设施上、用旨在攻破安全层的提示词进行测试，这与测试你自己的部署是两种不同的活动——而书面范围正是区分二者的关键。我们自己的网络安全层级所运行的验证关卡，其存在也是出于同样的原因：模型层面的授权安全工作，需要双方各有一位具名且可问责的负责人。

事件记录补充了什么

红队演练会告诉你目标会做什么。它无法告诉你现场会发生什么，而控制措施的论证恰恰是在现场才真正成立的。这正是事件台账所填补的空白——而它带来的纪律性才是有用之处：没有至少一个来源的记录就不存在，没有危害裁定的记录就不算事件。

把这两份材料放在一起读，闭环就合上了。红队产出一个可复现的发现，并点明本可拦住它的控制措施。记录则告诉你，该领域里是否已有人撞上过那条边界，造成的危害是什么，以及该控制措施在其他地方是否守住了。一个没有现场先例的发现，是值得修复的假设；一起没有可复现发现的现场事件，是你尚无法关闭的缺陷。做对这件事的团队，不再把“我们对模型做了红队测试”当作一项交付物，而是开始把它当作自己台账中的一项输入。

这就引出了诚实的收尾说明。AI 红队测试并不会带来安全保障，任何把它当作安全保障来出售的服务，卖的都不是正确的东西。它带来的是一组你现在已经知道会被越过的边界，附带可以复跑的证据，并按边界被越过时会发生什么来排序。这足以让你据此做决策——而且远比一份演示文稿有用。