AI红队测试服务：如何采购一次真正能证明问题的演练

假设董事会读到了有关AI助手遭受攻击的新闻，要求CISO在本季度结束前“做一次AI红队测试”。一周后，桌上摆着两份回复。供应商A寄来一份报告样本：上百张截图，显示模型说出了不该说的话。供应商B则提议先花两周时间商定目标、规则和测试环境，然后再开始工作。

第一种方案看起来更吸引眼球，也更便宜；第二种方案更慢，也更枯燥。但如果半年后董事会问：“红队测试之后，我们的安全状况到底有什么变化？”能够诚实回答的，只有从一开始就设定了目标、标准和规则的那一方。

这个场景是假设的，但它很好地说明了核心问题：AI红队测试作为一项服务，其价值不在于“绕过”了多少次，而在于它能以多大程度可验证的方式，回答一个事先约定好的、关于攻击者的问题。

红队测试与安全评估有何不同

以目标代替覆盖面

AI产品安全评估追求的是覆盖面。它逐层检查系统——数据、模型、应用和工具——并验证安全控制在每一条边界上是否有效。如何划定这样的范围，我们在关于AI产品安全评估的文章中做了详细说明。

红队测试的逻辑不同。它从攻击者的目标出发，检验一个具备特定能力的对手能否达成这个目标，途中经过哪些层次都无所谓。它不必检查所有安全控制，但它能展示防御体系在面对有目的的行动时表现如何，这些行动是否会被发现，以及组织恢复得有多快。

因此，一个有用的红队测试问题不是“助手有哪些漏洞”，而是例如“一个没有特权的外部用户，能否通过助手获取另一位客户的数据？监控团队能否发现这一行为？”

什么时候做红队测试还为时过早

只有在基础安全控制已经经过检验之后，红队测试才有意义。如果工具授权从未测试过，而助手的API在标识符被替换后就会返回他人数据，那么演练很快就会找到这个漏洞，然后把剩下的预算花在显而易见的问题上。在这种情况下，更诚实的做法是先做安全评估，修复发现的问题，然后再检验对手面对已经加固的系统能做些什么。

另一个“为时过早”的信号是缺乏可观测性。如果系统没有记录模型调用和工具调用的日志，红队测试一半的价值——也就是检验检测能力——根本无从实现。

约定的对抗目标

如何表述目标

好的目标描述的是结果，而不是技术手段。“尝试提示注入”是一种技术手段；“让助手以用户A的身份对用户B的数据执行操作”是一个可以在系统一侧验证的结果。

以下是针对一个带有助手和知识库的假设产品、以结果形式表述的目标示例：

通过助手获取属于另一位客户或另一种角色的信息。让智能体执行超出当前用户权限的操作。在一个可写入的数据来源中放置内容，使其影响助手对其他用户的回答。让系统以明显影响成本或可用性的方式消耗资源。

每一个这样的目标都与一项资产和一种业务后果相关联。这样，日后与管理层沟通时，谈论的就不再是“模型的奇怪回答”，而是他们能够理解的风险。涉及智能体操作的目标尤其重要，相关测试在另一篇关于过度代理安全测试的文章中专门讨论。

攻击者模型

在确定目标的同时，还要记录由谁来行动：匿名的外部用户？已注册的客户？可以访问知识库的员工？数据通过集成进入系统的合作伙伴？攻击者模型决定了初始访问权限、允许使用的影响渠道，以及结果的现实程度。

攻击者模型还决定了什么算作“内部”信息。例如，如果目标是检验授权而不是隐蔽性，那么把整体架构告诉测试团队、让他们不必在侦察上浪费时间，可能是合理的做法。

什么不属于目标

明确写下哪些内容不属于目标也很有用。生成冒犯性文字可以是内容质量与安全团队的一项独立任务，但不一定是安全测试的目标。违反模型供应商规则去测试其基础设施，不是目标。可能导致生产环境停摆的负载测试，除非另行约定，也不是目标。边界划得越清楚，验收成果时的争议就越少。

允许的行动与交战规则

允许什么，禁止什么

交战规则是一份书面文件，而不是口头约定。它列出纳入范围的目标和系统、允许的影响渠道（助手界面、API、文档上传，以及当共享邮箱是数据来源时向其发送的邮件）、禁止的行动和测试时间窗口。

对于后果不可逆的操作，需要单独规定。如果智能体能够给客户发送邮件、进行支付或删除记录，规则就必须说明如何测试这些操作：使用测试数据、用桩替代真实集成，或者在执行前一步强制停止。要证明智能体能够发起支付，并不需要真的完成一笔支付。

所有这些都必须以系统所有者的书面授权为前提。如果模型或工具由第三方提供，还需要另行核实其条款是否允许此类测试。

数据与发现的处理

在演练过程中，测试团队会看到提示、模型回答、文档片段，有时还会看到个人数据。规则必须规定这些材料存放在哪里、谁可以访问、如何移交给委托方以及何时删除。还应约定中间阶段的严重发现如何记录和传递：如果发现了一条可以访问所有客户数据的路径，就不能等到最终报告再说。

停止条件

停止条件回答的是“出了问题怎么办”。这可能是对生产环境的意外影响、访问到了明显不在范围内的数据，或者发现了真实攻击者留下的痕迹。每一种情况都需要联系人、沟通渠道和处理流程。只有供应商自己知道的紧急刹车，是不起作用的。

如果您希望事先结合自己的产品梳理目标、规则和环境，可以在准备渗透测试范围时与 Pentest.red 团队一起完成：这一步会讨论系统、访问权限、限制条件和预期结果。

控制测试环境

在哪里进行演练

生产环境的真实性最高：真实的集成、真实的监控、真实的数据，但风险也最大。测试环境更安全，但它可能在模型版本、配置、工具组合，尤其是监控方面与生产环境不同。在没有监控的测试环境中得出的“防御是否发现了”的结论，不能照搬到生产环境。

常见的折中方案是：主要工作在模型、配置和工具都尽可能接近生产环境的测试环境中进行，同时在生产环境中重复一小部分安全的场景，用来检验检测能力。关于环境的决定，连同它对结论的影响，都必须写下来。

测试账户与数据

对于涉及访问他人数据的目标，至少需要两个分属不同租户或角色的测试账户，以及能够明确看出归属的合成数据。这样，证据就不再是对模型回答的解读，而是一个事实：只属于用户B的标记出现在了用户A的会话中。

如果智能体通过MCP或类似协议使用工具，这些服务器同样属于环境范围的一部分，包括它们的权限、令牌和日志。如何单独测试这类服务器，请参阅我们的MCP服务器安全评估方法。

固定版本与配置

在开始之前以及在报告中，都要记录模型及其版本、供应商、系统指令、过滤器、已接入的工具组合、知识库内容和编排代码的版本。没有这些信息，结果既无法复现，也无法与后续的重复演练进行比较。如果供应商在演练期间更新了模型，也必须记录下来：更新前后的部分观察结果可能属于两个不同的系统。

在由模型规划并执行行动链条的智能体系统中，环境固定需要格外细致，详见我们的智能体AI系统渗透测试指南。

可验证的成功标准

二元标准与统计标准

对许多目标来说，标准是二元的，并且在系统一侧验证：工具是否被以他人的标识符调用？会话中是否出现了他人的标记？是否以不具备相应权限的用户身份创建了记录？这类标准的优点在于，它们不取决于如何解读回答的文字。

对于涉及模型行为的目标，标准往往是统计性的。模型可能拒绝九次，第十次却照做了。因此，“在某某配置下，M次尝试中成功N次”比简单的“成功”或“失败”更有信息量。尝试次数和条件需要事先约定，以免日后争论到底应该尝试多少次。

可接受的阈值是业务决策，而不是供应商的决策。对于访问其他客户数据的情况，合理的阈值是零次成功：哪怕只有一次被确认，也意味着存在授权缺陷。对于回答中出现不良内容的情况，阈值可能不同，取决于产品的受众。供应商负责测量，委托方决定如何处理测量结果。

非确定性与可重复性

模型的非确定性不是放弃可复现性的理由，而是换一种方式描述可复现性的理由。好的证据会记录配置、输入条件、尝试次数、成功比例和可观察到的效果。如果某条路径很少奏效，却能导致数据访问，它依然是严重的发现：对手只需要成功一次。

观察与恢复

防御体系应该看到什么

红队测试与安全评估的主要区别之一，在于检验组织能否看到正在发生的事情。对于AI系统，这意味着：模型的提示和回答是否被记录并关联到具体用户？工具调用及其参数是否被记录？是否有针对异常的信号，例如调用次数骤增、访问其他客户的数据，或智能体出现不寻常的行动链条？

在演练开始前，应约定防御团队中谁知道这次演练。如果所有人都知道，检验的只是日志是否存在；如果值班人员不知道，检验的还包括响应能力。两种做法都是正当的，但得出的结论不同。

演练后的恢复

工作结束后，系统必须恢复到一个已知状态：从知识库中删除可能影响回答的测试文档；吊销令牌和测试账户；如果助手的记忆会在会话之间保留，就要清除或标记；回滚测试集成中的更改。供应商移交一份所有被创建或修改内容的清单，委托方确认清理已经完成。

恢复本身也是一种检验。如果团队无法迅速找到并删除被植入知识库的文档，这本身就是一项关于流程成熟度的发现。

1. 目标表述攻击者要达成的结果、涉及的资产和业务后果，以及攻击者模型。
2. 规则写明允许的行动、禁止事项、数据处理方式、测试时间窗口和停止条件。
3. 环境固定模型、版本、配置、工具、测试账户和监控手段。
4. 尝试与观察执行场景，记录尝试及系统一侧的效果，并与防御日志进行比对。
5. 恢复与结论让系统回到已知状态，并连同适用范围一起描述结果。

如何评估供应商

绿旗与红旗

2026年2月，OWASP生成式AI安全项目发布了评估AI红队测试服务和工具供应商的标准。该文件帮助区分有实质内容的对抗性测试与仅限于绕过模型限制的服务，并把系统分为简单系统（例如聊天机器人和RAG应用）和复杂系统（包括调用工具的智能体、MCP架构和多智能体工作流）。此前，OWASP在2025年1月发布了生成式AI红队测试指南，提出在四个方面采用整体方法：模型评估、实现测试、基础设施评估和运行时行为分析。

结合这些材料和常识，可以得出一组实用的判断信号。绿旗：供应商从目标和攻击者模型入手，提出交战规则和停止条件，在描述方法的同时说明其局限，区分关于模型行为的观察和系统中可被利用的弱点，并提出检验检测能力。红旗：把“攻击成功率”作为核心指标，承诺“全面覆盖”，不询问环境和数据，报告样本由没有配置和条件说明的截图组成。

报告就是产品

红队测试报告是演练结束后留在委托方手中的东西。它应当包括：目标和攻击者模型；带有版本信息的规则和环境；行动时间线；已达成和未达成的目标及其证据；防御体系看到了什么、没看到什么；根本原因；修复建议；以及明确列出的未测试内容。应用层的发现最好对应到带版本号的OWASP ASVS要求和CWE类别，这样它们就能与其他测试的结果相比较，也更便于修复。

管理层需要一个单独的简短部分：哪些目标被证明可以达成，这对业务会产生什么后果，需要做出哪些决策。技术细节则保留在正文中，供工程师使用。

供应商还应说明如何处理工作中获得的材料，以及在交付报告后保留哪些内容。

结论的适用范围

演练之后可以声称什么

在一次组织良好的演练之后，可以这样声称：在这样的模型、版本和配置下，使用这样的工具和数据，在这样的场景集合和时间内，一支具备这样能力的团队达成或未达成了这些目标，防御体系看到或没有看到这些行动。这已经很多了。这是用于决策的具体、可验证的信息。

不能声称什么

不能声称系统“能够抵御针对AI的攻击”。未达成的目标意味着在这些条件下未能达成，而不是不可能达成。模型拒绝执行某项操作，并不能证明工具受到了授权保护。拦住了测试团队尝试的请求过滤器，不是访问边界。未能被提取的系统提示，依然不应被视为秘密，也不应用来存放敏感数据。

还有一条通用规则：红队测试和任何渗透测试一样，都不是认证证书，也不能证明不存在漏洞。更换模型、系统指令、工具或数据来源都会改变系统，部分结论也会因此不再适用。

从报告到决策

发现应该流向哪里

发现必须进入风险管理流程，而不是停留在一份独立的文件里。NIST AI RMF 1.0围绕治理、映射、度量和管理四项职能来组织AI风险管理，NIST AI 600-1配置文件则把这一框架适配到生成式AI。红队测试很自然地属于“度量”职能，但只有当人们据此做出决策时，它的结果才有意义：谁是风险负责人，采取什么修复措施，在什么期限内完成，接受哪些剩余风险。

对于应用层的发现，熟悉的逻辑依然适用：按CWE确定根本原因，在排序时考虑被积极利用的弱点类别，修复整类缺陷，而不是只修复一个参数。

什么时候重复

在已达成的目标得到修复之后，以及在发生重大变更之后，重复演练才有意义，例如更换模型或模型版本、接入新工具、扩大智能体权限、增加新的数据来源。验证修复并不总是需要完整的红队测试，往往按照同样的标准进行一次有针对性的复测就足够了。如何组织这样的复测、证明修复确实有效，我们在关于渗透测试修复验证的文章中做了说明。

让我们回到开头的董事会。对其问题的诚实回答，不是“绕过”的次数，而是一份记录：已确认的目标达成路径、修复后的复测结果，以及防御体系观察到了什么；这些结论仅适用于已测试的版本和场景。如果您希望讨论如何为自己的系统表述这样的目标、哪种测试形式适合它们，可以从范围准备页面开始；我们的整体工作形式可在渗透测试服务中查看。