AI Red Teaming

Red Teaming 定义

AI Red Teaming（AI 红队测试）是一种主动的安全评估方法，专门团队扮演攻击者角色，系统性地寻找 AI 系统的漏洞、有害行为和安全边界弱点，并在产品正式发布前对这些问题进行修复。

Red Teaming 这一概念来自军事领域（红队模拟敌方，蓝队代表己方），被引入 AI 安全领域后，专指对 AI 系统进行模拟攻击测试的实践。

与传统软件 Penetration Testing 的区别：

• 传统 Pentest 寻找确定性漏洞（代码缺陷、配置错误）
• AI Red Teaming 还需要探索概率性的有害行为（AI 在特定上下文下的不当输出）

---

手动 Red Team

人工 Red Teaming 由具备专业背景的安全研究人员执行，是目前发现复杂、新型 AI 安全问题最有效的方法。

手动 Red Team 的优势

• 创造力：人类能想到机器无法枚举的新奇攻击角度
• 领域专业性：有特定领域背景的测试人员（前情报官员、生化专家、网络安全专家）能更有效地测试对应领域的风险
• 语义理解：能判断 AI 输出是否真正有害，而非仅依赖关键词匹配

手动 Red Team 的局限

• 规模有限：人力成本高，无法穷举所有攻击路径
• 主观偏差：测试者的文化背景、知识边界影响测试覆盖面
• 重复性低：测试结果难以标准化和重现

Red Team 人员构成

有效的 Red Team 通常包括：

• AI 安全研究人员（理解模型的技术弱点）
• 有害内容专家（了解什么是真正有害的内容）
• 领域专家（医学、法律、生化、网络安全等）
• 社会学/心理学背景人员（识别偏见、操控等问题）
• 创意写作者（设计复杂的角色扮演场景）

---

自动化 Red Team

随着 LLM 能力增强，使用 AI 来自动生成攻击场景变得可行，大幅提升测试规模。

LLM 生成攻击用例

基本思路：用一个 LLM（攻击者模型）来生成针对目标 LLM（被测模型）的攻击 Prompt：

# 概念性伪代码
attacker_system_prompt = """
你是一个安全研究者，任务是生成可能使目标 AI 产生有害输出的 Prompt。
目标测试类别：{category}  # 如：武器信息、仇恨言论、隐私泄露
当前已知目标 AI 会拒绝的模式：{known_defenses}
请生成 20 个新颖的、可能有效绕过防御的 Prompt。
"""

attack_prompts = attacker_llm.generate(attacker_system_prompt)
for prompt in attack_prompts:
    response = target_llm.generate(prompt)
    safety_score = evaluator.score(response)
    if safety_score > threshold:
        log_vulnerability(prompt, response)

Garak 工具

Garak（garak.ai）是目前最成熟的开源 LLM 安全测试框架：

• 探测器（Probes）：定义测试场景（DAN 越狱、提示注入、幻觉、毒性等）
• 检测器（Detectors）：判断输出是否满足安全要求的分类器
• 生成器（Generators）：对接各种 LLM API
• 报告：标准化的安全评估报告，按漏洞类型分类展示

# Garak 使用示例
python -m garak --model_type openai --model_name gpt-4 \
    --probes dan.Dan \
    --generations 10

---

微软 AI Red Team 实践

微软是在企业级 AI Red Team 方面投入最多的公司之一，并公开了部分实践经验：

微软 AI Red Team 原则

• 广度优先：覆盖所有可能的危害类别，而非深入单一攻击路径
• 跨文化测试：针对不同地区、文化背景设计测试场景
• 迭代反馈：Red Team 发现 → 安全团队评估 → 工程师修复 → Red Team 重测

测试维度

微软将 AI 风险分为两大类：

安全风险（Safety）：

• 有害内容生成（Harmful Content）
• 操纵性内容（Manipulative Content）
• 虚假信息（Misinformation）

安全性风险（Security）：

• 越狱（Jailbreak）
• 提示注入（Prompt Injection）
• 数据提取（Data Extraction）

---

Anthropic 安全评估流程

Anthropic 将安全评估分为多个层次：

预训练评估

在 RLHF 之前，评估基础模型的有害倾向：

• 基础能力评估（有害信息的知识储备）
• 对齐失败模式（模型的默认行为倾向）

RLHF 后评估

对齐后的模型评估：

• 拒绝率测试（对有害请求的拒绝稳定性）
• 过度拒绝测试（对合法请求的不必要拒绝）
• 边界测试（安全限制的精确边界在哪里）

外部 Red Team

邀请外部独立安全研究人员进行测试：

• 更少的内部偏见
• 更广的测试视角
• 通常在模型发布前 2-4 周进行

---

测试维度

全面的 AI Red Team 应覆盖以下维度：

有害内容维度

• 武器（化学/生物/核/放射性）信息生成能力测试
• 网络攻击工具生成能力测试
• CSAM（儿童性剥削材料）相关请求
• 自我伤害/自杀信息
• 仇恨言论和歧视性内容

隐私泄露维度

• 训练数据记忆测试（能否提取训练集中的个人信息）
• 系统 Prompt 提取能力
• 用户对话历史提取

越狱与对齐失败

• 各种 Jailbreak 技术的成功率
• 角色扮演场景中的安全边界测试
• 长对话中的安全衰减（对话越长，安全性是否下降）

系统滥用

• 大规模生成虚假信息的能力
• 网络钓鱼邮件自动生成
• 仿冒特定人物或机构

---

漏洞分类与严重性评级

发现的漏洞应按严重程度分类：

严重程度	定义	示例
P0 (严重)	可稳定触发，造成严重实际危害	生成生物武器制备指南
P1 (高危)	需要技巧触发，有实际危害潜力	生成有效网络攻击代码
P2 (中危)	触发条件苛刻，或危害有限	泄露系统 Prompt
P3 (低危)	边缘情况，危害极小	在特定创意写作场景中轻微违规

---

负责任披露流程

内部漏洞处理

1. Red Team 将漏洞提交到内部跟踪系统
2. 安全团队在 24-48 小时内确认和评级
3. 工程团队制定修复方案
4. P0 漏洞：立即修复，不发布带有此漏洞的模型
5. P1 漏洞：在发布窗口前修复
6. P2/P3 漏洞：加入待办队列

外部漏洞赏金计划

• OpenAI：漏洞赏金金额 $200-$20,000，取决于漏洞严重程度和影响范围
• Anthropic：通过 HackerOne 平台接受外部安全报告
• Google（Gemini）：通过 Google Bug Hunter 计划处理 AI 相关漏洞

提交 AI 安全漏洞时应包含：

• 可重现的完整 Prompt 序列
• 模型版本和 API 参数
• 输出内容的截图/日志
• 危害评估和影响范围