LLM 红队测试

LLM 红队测试是一种在 AI 系统部署之前，通过使用模拟的对抗性输入来发现其漏洞的方法。

截至目前，LLM 架构存在多种固有的安全挑战。根据系统的设计，例如 RAG、LLM 代理 或 聊天机器人，您将面临不同类型的漏洞。

几乎每个 LLM 应用都可能存在生成与主题无关、不当或有害内容的问题，这些内容可能违反业务政策或其他指导方针。随着架构变得更加复杂，问题可能以信息泄露和访问控制（RAG 架构）、连接的 API 或数据库的滥用（在代理中）等形式出现，等等。

为了在这些问题进入生产环境之前识别它们，我们需要生成广泛的对抗性输入并评估 LLM 的响应。

通过系统地探测 LLM 应用，我们可以生成一份量化滥用风险并提供缓解建议的报告。

tip

准备好进行红队测试了吗？跳转到 快速开始。

为什么 LLM 红队测试很重要？

红队测试与其他 AI 安全方法不同，因为它在部署之前提供了风险的定量衡量。

通过运行数千次探测并评估 AI 的性能，开发者可以在离线测试环境中做出关于可接受风险水平的明智决策。许多组织将此纳入其开发周期和 CI/CD 等流程中。

这是大型基础实验室——OpenAI、Anthropic、微软和谷歌——在向公众发布模型之前评估其模型的过程。一段时间以来，AI 红队仅限于这些精英实验室。现在，随着工具的增多和最佳实践的出现，AI 红队测试变得越来越普遍。

这是一个新兴领域，标准正在全球范围内涌现，从 OWASP LLM Top 10 到 NIST 的 AI 风险管理框架 和 欧盟 AI 法案。

从我们目前所见，大多数法规/标准支持在部署前通过测试量化风险的系统基准测试/红队测试过程。

LLM 红队测试如何工作

红队测试 LLM 的过程通常需要一定程度的自动化以进行全面评估。这是因为 LLM 具有广泛的攻击面，并且本质上是随机的（即它们在每次生成之间不一致）。

系统方法如下：

1. 生成对抗性输入：创建或策划一系列针对潜在漏洞的恶意意图。对于每个意图，将其包装在一个试图利用目标的提示中。您可以在此步骤中结合提示注入和越狱等方法。

2. 评估响应：通过您的 LLM 应用运行这些输入，以观察模型的行为。此步骤非常适合自动化。

3. 分析漏洞：使用确定性和模型评分指标自动评估 LLM 的输出，并检查响应以识别弱点或不良行为。

一旦建立了流程，它可以通过两种主要方式应用：

• 一次性运行：生成一份全面的报告，允许您检查漏洞和建议的缓解措施。
• CI/CD 集成：持续监控部署管道中的漏洞，确保随着应用的发展持续安全。

管理 AI 风险的神奇时刻通常出现在组织能够设置一些 AI 风险的持续测量之后：无论是通过 CI/CD、内部要求，还是其他形式的定期运行。

模型与应用层威胁

一般来说，威胁分为两大类：模型（“基础”）或应用层。虽然存在一些重叠，但在红队测试目标中明确您想要测试的方面是有帮助的。

当研究实验室如 OpenAI 或 Anthropic 训练新模型时，他们有内部（和外部）测试人员对聊天调优模型进行压力测试，以确保安全和研究目的。模型层漏洞包括诸如生成以下内容的能力：

• 提示注入和越狱
• 仇恨言论、偏见、毒性及其他有害输出
• 幻觉
• 版权侵犯
• 专业建议（医疗、财务）
• 表现出过度代理或利用过度依赖的结果
• PII泄露（来自训练数据）

另一方面，存在一类漏洞，只有在将模型连接到更大的应用环境后才会显现。这些包括：

• 间接提示注入
• PII泄露（来自上下文，例如在RAG架构中）
• 基于工具的漏洞（例如未经授权的数据访问、权限提升、SQL注入 - 取决于API和数据库访问）
• 劫持（即离题使用）
• 数据/聊天外泄技术（例如Markdown图像、链接展开）

大多数应用程序集成现有模型，而不是需要专门的模型。因此，应用程序层的威胁通常是基于LLM的软件红队测试的重点，因为它们可能造成最大的技术风险。

白盒测试与黑盒测试

LLM的白盒测试涉及对模型的架构、训练数据和内部权重的完全访问。这使得高度有效的攻击算法成为可能，如贪婪坐标下降和AutoDAN。

这些白盒攻击的缺点是它们通常较慢，并且适应模型的特定特征。此外，大多数开发者并不是通过模型的权重来构建模型，因此这种方法对于大多数用例并不实用。

另一方面，黑盒测试将LLM视为一个封闭系统，其中只能观察到输入和输出。这种方法模拟了攻击者没有内部知识的现实世界场景。

两种方法在红队测试中各有优点：

• 白盒测试可以发现更深层次的结构性漏洞。
• 黑盒测试更能代表现实世界的攻击场景，并能揭示意外行为。

对于大多数开发者和AppSec团队来说，黑盒测试是更实际的方法，因为在大多数情况下测试者无法访问模型内部。黑盒方法更容易结合与RAG和代理相关的现实世界基础设施。

常见威胁

AI应用面临的威胁数量可能令人不知所措，因为AI应用通常通过定义提供具有不可预测结果的生成功能。正如Theory的风险投资家Tomasz Tunguz所写道，“随着AI的出现，规则已经改变。非确定性ML模型引入了不确定性和混乱行为。”

这种非确定性行为对产品方面有影响，但对我们这些更偏执的人来说也有影响。

隐私侵犯

显而易见的是：生成式AI应用依赖于庞大的数据源，而能够访问这些数据源的对手将对应用背后的公司构成巨大威胁。

即使用户隐私没有直接受到侵犯，拥有AI应用的公司也不希望外界知道他们使用的训练数据。但在2022年的一篇论文中，研究人员发现使用对抗性LLM相对容易揭示另一个LLM的训练数据（虽然这仅适用于基础模型和微调，但对于上下文中包含额外数据的RAG是相关的）。

然而，同一篇论文显示，通过类似的方法，隐私侵犯可以更加直接——从LLM分享不应该分享的电话号码到分享个人电子邮件地址。

个人身份信息（PII）的泄露本身就很糟糕，但一旦对手掌握了这些PII，他们就可以利用被盗的身份未经授权访问公司内部资源——窃取资源、勒索公司或插入恶意软件。

许多AI应用的最佳用例涉及通过在特定数据源上微调通用模型来适应特定上下文。如果公司不放心将私有数据源连接到易受攻击的AI应用，整个用例可能会被关闭。

提示注入

LLM呈现出一系列全新的漏洞，这些漏洞对许多安全团队来说可能很熟悉，但带来了新的风险和新的应对策略。 提示注入类似于SQL注入，但表现形式不同。提示注入是一种攻击类型，它将不受信任的用户输入与受信任开发者构建的受信任提示结合起来。（重要的是，这与越狱不同，我们将在下一节中讨论）。

在2023年的黑帽演讲中，安全研究人员展示了大量在野外有效的提示注入示例。例如，通过一次提示注入，研究人员劫持了一个LLM，说服用户透露他们的姓名，并让用户点击一个链接，将他们重定向到一个恶意网站。

当然，尽管研究人员将提示注入类比为更传统的SQL和shell注入，但基于AI的SQL和shell注入仍然是可能的。

在2023年的一篇论文中，另一组研究人员展示了提示到SQL注入可以非常有效。在论文中，该团队评估了7个LLM，并展示了“P2SQL攻击在语言模型中的普遍性”。

Shell注入也是如此。未经红队测试的AI应用经常容易受到执行未经授权的shell命令的攻击。

越狱

越狱指的是故意绕过支持AI应用的LLM中内置的基础安全过滤器和防护措施的攻击。这些攻击旨在使模型偏离其核心约束和行为限制。

即使是技术水平最低的最新ChatGPT用户，在某种意义上最终也会成为对手，当他们想到：“我怎样才能让这个东西忽略它的规则？”

越狱可能出奇地简单——有时只需复制并粘贴一个精心设计的提示，就能让生成式AI应用做一些它根本不应该做的事情。

例如，Interviewed的创始人Chris Bakke通过一个简单的提示，给了机器人一个新的目标，说服了一个雪佛兰经销商的ChatGPT驱动的客服应用以1美元的价格卖给他一辆2024款雪佛兰Tahoe。

这个例子很有趣，但它展示了一个更深层次的问题：能够覆盖模型的核心约束。

研究表明，自动化方法可以深入得多，并带来更严重的风险。在2023年的一篇论文中，研究人员发现，一种使用树状思维推理迭代提炼提示的攻击树与剪枝（TAP）方法，可以在不需要不切实际的暴力破解的情况下成功越狱目标。

研究人员写道：“在实证评估中，我们观察到TAP生成的提示在仅使用少量查询的情况下，成功越狱了最先进的LLM（包括GPT4和GPT4-Turbo），成功率超过80%。”

在另一篇论文中，其他研究人员通过找到并添加后缀到查询中，使LLM更有可能响应请求不良内容，从而展示了类似的漏洞，绕过了其内置的伦理约束。

而且不仅仅是关于不同的输入措辞。在2024年的一篇论文中，研究人员展示了ASCII艺术可以成功绕过AI防护措施，展示了另一种颠覆基础安全措施的方法。

生成不良内容

除了越狱，AI应用有时会由于基础模型的广泛知识库（可能不限于应用的具体用途）而生成不良或不受欢迎的内容。

当AI应用生成此类内容时，在孤立的情况下，这似乎是一个相对较小的问题——类似于责怪Google搜索。但在规模上，就内容的访问和分发而言，更严重的风险开始显现。

例如，推广犯罪活动的内容可能会使生成该内容的AI应用（及其背后的公司）看起来很糟糕。Google可能会指向某人发布的与犯罪相关的信息，但当你的公司为犯罪分子提供分步指导时，问题就严重得多了。 同样，错误信息在某一层面可能显得微不足道，而在另一层面则可能带来灾难性后果。在足够大的规模下，依赖于产生幻觉的AI应用的用户可能会导致大规模的妄想。但在这两者之间的步骤同样危险，从仅仅是错误信息（使公司显得愚蠢）到误导性、不安全的信息（可能真正伤害用户）。

AI开发者努力确保这些结果不会出现，但始终是一场在实施安全措施与模型庞大知识库可能产生不期望输出之间的紧张竞赛。

而且，确实有人真的吃了胶水披萨。

最佳实践

基于我们作为部署大型语言模型（LLMs）的实践者的经验，我们推荐以下有效的红队测试最佳实践：

第一步：定义你的策略

在运行红队测试之前，定义一个系统化的流程，包括：

1. 漏洞聚焦：确定哪些类型的漏洞对你的应用程序最为关键。这将取决于你的使用场景（例如，RAG、代理、聊天机器人）和行业。

2. 开发周期中的时机：决定在你的流程中红队测试将在何处进行。考虑的检查点包括：

   • 模型测试，甚至在开始构建应用程序之前就可以进行，特别是在微调时尤为重要。
   • 部署前测试，一旦模型与应用程序、工具、数据库等连接后。
   • 持续集成/部署（CI/CD）检查，以捕捉回归和异常。
   • 部署后监控，以建立反馈循环并保持对应用程序在生产环境中行为的理解。

3. 资源分配：平衡测试的深度与可用的时间和资源。某些自动化攻击策略消耗大量令牌，单次红队测试可能从几分钱到数百美元不等！

4. 法规遵从性：考虑任何行业特定的或地区性的要求（例如，GDPR、HIPAA）以及标准（例如，NIST AI RMF、OWASP LLM）。

第二步：实施

一旦你定义了你的目标，你的流程可能看起来像这样：

1. 生成多样化的对抗性输入：

   • 创建针对你已识别的漏洞类型的广泛输入。
   • 自动化生成工具非常有帮助，特别是覆盖广泛的使用场景。但人类的创造力仍然有用，特别是在已知问题领域。

2. 设置评估框架：

   • 选择或开发一个用于系统化LLM测试的工具。
   • 如果适用，将其集成到你的开发管道中。

3. 执行测试：

   • 通过你的LLM应用程序运行对抗性输入。
   • 确保你在一个高度模拟生产环境的环境中进行测试。最好进行端到端测试——这样你可以压力测试完整的工具访问和/或防护栏。

4. 收集和组织结果：

   • 以结构化的格式存储输出，以便随后进行分析。大多数评估框架会为你完成这一步。

第三步：分析和修复

1. 审查标记的输出：

   • 设定定期审查测试结果的节奏。这可能涉及安全团队和开发团队共同参与审查过程。

2. 优先处理漏洞：

   • 并非所有问题都是平等的。AI安全和AI安全问题之间有一条模糊的界限，如上所述，有些问题落在模型侧，而有些则落在应用程序侧。
   • 我们交谈的大多数团队发现，专注于技术安全漏洞最为高效，因为基础模型问题随着AI研究的进展正在不断改善，并且往往影响较小。

3. 制定缓解策略：

   • 对于每个优先漏洞，集思广益可能的修复方案。
   • 这可能包括提示工程、额外的防护措施或架构变更。

4. 实施并验证修复：

   • 应用选定的缓解措施并重新运行评估套件，以确认你的解决方案的有效性。

5. 持续改进：

   • 定期用新的对抗性输入更新你的测试套件，并重新生成红队输入以测试变体和更新方法。

案例研究：Discord的Clyde AI

Discord在2023年3月推出的Clyde AI是一个完美展示为何彻底红队测试至关重要的例子。Clyde，一个由OpenAI驱动的聊天机器人，旨在通过回答问题和促进对话来帮助用户。但其高调的推出也带来了一些教训。

部署

Discord通过逐步引入Clyde采取了谨慎的做法。他们最初只将其提供给一小部分服务器，这使他们能够在测试和改进的过程中进行。起初，情况看起来很有希望。一项调查发现，74%使用Clyde的Discord版主对其感到满意。

野外的漏洞

用户很快找到了利用系统的方法。著名的例子是，一位Discord用户发现了GPT的“奶奶漏洞”，这是一种经典的越狱攻击。用户发现他们可以通过将请求框定为角色扮演场景来诱使Clyde输出禁止的内容。例如：

这种提示让用户绕过了OpenAI的对齐和Clyde的内容过滤器，带来了几个风险：

• 政策违规：Clyde生成了违反Discord指南的内容，可能使用户接触到有害或不适当的内容。
• 声誉损害：该漏洞引起了关注，导致负面宣传并引发了对Discord用户安全承诺的担忧。
• 用户信任侵蚀：用户开始质疑Clyde的可靠性和Discord保护他们免受有害内容的能力。

红队测试和评估

参与此报告和其他类似报告的团队有很多：工程、产品、安全、法律、政策和市场营销。

• 采用评估框架（实际上，他们使用了Promptfoo的早期版本！）。评估框架是一种自动将输入传递给LLM并测试其输出的方法。
• 设定一个惯例，即每个提示/工作流程更改都需要进行评估。
• 尽可能使评估自动化且无摩擦。

这为所有利益相关者提供了一种定量、数据驱动的方式来衡量风险变化并标记异常波动。

除了红队测试，Discord还部署了被动审核和可观察性工具来检测对抗性输入的趋势，并开发了专门的报告机制。

关键要点

此案例突显了AI红队测试的几个实际方面：

1. 全面的部署前测试：测试广泛的对抗性输入，以在发布前发现潜在的漏洞。
2. 逐步推出：通过控制、渐进的部署限制潜在损害并收集实际使用数据。
3. 持续监控：培养持续测试和风险监控的文化，以捕捉回归。
4. 用户反馈循环：鼓励用户报告问题，并将这些问题反馈到红队测试设置中。

其他例子

Promptfoo是一个开源软件，将LLM的失败模式分解为称为“插件”的对抗性测试者。以下是一些插件的例子：

• 有害内容：在领先AI模型中触发的仇恨言论、攻击性内容和其他有害输出的例子。
• 对象级授权失效（BOLA）：测试属于其他用户的资源未经授权访问的用例。
• 功能级授权失效（BFLA）：试图执行超出授权范围或角色的操作的提示。
• 竞争对手背书：AI可能无意中推广竞争产品或服务的场景。

有关模型和应用程序漏洞的更多信息，请参阅LLM漏洞类型。

下一步是什么？

要开始并运行您的第一个红队测试，请参阅快速入门指南。