10.6 DeepTeam 与现代红队工具链

随着大语言模型安全研究的深入，企业和安全研究机构需要采用专业的红队测试工具来系统地评估模型安全性。本节详细介绍当前业界主流的自动化红队测试框架及其在企业实践中的应用。

10.6.1 现代 AI 红队工具的演进

从手工红队到自动化红队

图 10-10：红队工具的演进历程

现代红队工具的核心特点

特性	传统	现代化
自动化程度	低	高
覆盖面	部分场景	更全面
成本投入	人力密集	工具与工程投入并重
可扩展性	低	高
结果追踪	人工记录	自动化报告
CI/CD 集成	困难	更容易集成

10.6.2 DeepTeam 框架详解

DeepTeam 是由 Confident AI 推出的开源综合红队框架（官网），代表了当前业界主流的自动化红队方案之一。

框架架构

图 10-11：DeepTeam 框架架构

核心组件详解

攻击生成引擎

官方公开资料更适合支持“DeepTeam 提供单轮/多轮攻击、漏洞模板、红队编排与报告”，而不是把它理解成一个固定内置 GCG/TAP/M2S/STAR 的统一 API。

# 伪代码：DeepTeam 攻击生成
from deepteam import red_team

results = red_team(
    model_callback=model_callback,
    vulnerabilities=[...],
    attacks=[...],
)

关键特性：

• 单轮与多轮攻击编排

• 漏洞模板与场景化红队任务

• 自适应参数调优

• 报告与评测闭环

评估引擎

DeepTeam 的官方文档更强调围绕 vulnerability 的评估、打分与理由解释，而不是固定的一组跨框架通用评分维度：

# 伪代码：DeepTeam 不提供独立的 Evaluator 类，
# 评估在 red_team() 运行时按 vulnerability 自动完成（LLM-as-judge 逐项打分与理由），
# 因此通常直接读取 red_team() 返回结果中的逐项评估，无需单独构造评估器。

报告生成引擎

自动生成可操作的安全报告：

DeepTeam Red Team Report
========================
Target Model: ...
Test Date: ...
Coverage: ...

Critical Vulnerabilities: ...
High: ...
Medium: ...
Low: ...

DeepTeam 的关键创新

1. 端到端自动化：从攻击生成到报告输出的完整自动化流程

2. 多维度评估：综合考虑成功率、伤害程度、可转移性、隐蔽性

3. 可配置攻击编排：按目标系统选择漏洞、攻击方法和多轮测试参数

4. 结果管理：本地运行可输出评估结果；接入平台后可做跨迭代跟踪和报告分发

5. 可追踪性：保留测试输入、判定理由与结果，便于复测和人工复核

实际应用案例

企业应用场景

DeepTeam 更适合作为“端到端自动化红队框架”的代表：帮助团队系统化生成测试样本、评估结果并输出报告。更稳妥的表述方式是强调其流程价值，而不是给出脱离具体部署条件的统一效果数字。

10.6.3 Garak 框架详解

Garak 当前由 NVIDIA/garak 仓库维护，是一个开源的 LLM 漏洞探测与红队评估工具；历史来源和维护归属应以官方仓库说明为准。

框架特点

图 10-12：Garak 框架特点

核心模块

Probes（探针）

预定义的攻击测试用例库。Garak 以 probe 模块和 probe 类组织测试，常见模块包括：

Probe 模块	示例用途
promptinject	PromptInject 提示注入测试
dan / tap	DAN、PAIR、TAP 等越狱与自动化红队
suffix.GCG	GCG 对抗性后缀探测
encoding / latentinjection	编码、隐蔽和潜伏注入
misleading / packagehallucination	错误事实与包名幻觉

Harnesses（测试框架）

抽象层，隐藏特定模型的交互细节，提供统一的测试接口：

# 更贴近官方文档的 CLI 形态
garak --target_type openai --target_name YOUR_OPENAI_MODEL --probes dan,promptinject

Detectors（检测器）

评估模型响应是否成功被攻击：

detector_types = {
    'pattern': PatternDetector(),           # 正则表达式匹配
    'semantic': SemanticDetector(),         # 语义相似性
    'classifier': ClassifierDetector(),     # 分类器判定
    'reference': ReferenceDetector()        # 参考答案对比
}

Generators（生成器）

Garak 官方文档中的 generator 不是“攻击样本生成器”，而是目标模型或系统的接口适配层。攻击交互主要由 probes 生成，buffs 可对 probe 产生的提示做变换，detectors 负责判断响应是否命中风险。

probes / buffs 生成或变换测试输入
        ↓
generator 调用目标模型或系统
        ↓
detectors 评估输出

使用流程

图 10-13：Garak 测试流程

Garak的优劣对比

方面	优势	劣势
开源性	完全开源，透明可信	商业支持有限
易用性	文档完善，易于入门	高级自定义学习曲线较陡
扩展性	高度模块化，易于扩展	多模块组合时可能有兼容性问题
覆盖面	内置探针丰富	对最新攻击手法仍需持续补充
性能	相对轻量	大规模测试需额外优化

10.6.4 PyRIT 框架

PyRIT（Python Risk Identification Tool for generative AI）是微软开源的一个框架，专注于识别 LLM 的风险。

框架设计哲学

PyRIT采用“攻击作为数据”的理念，将每个攻击视为数据点进行系统化分析。

# 伪代码：PyRIT 的核心概念
class AttackAsData:
    def __init__(self):
        self.attacks = []
        self.results = []
        self.metadata = {}

    def store(self, attack, result, context):
        """每个攻击尝试都被完整记录"""
        self.attacks.append({
            'prompt': attack,
            'result': result,
            'timestamp': time.time(),
            'context': context
        })

    def analyze(self):
        """对积累的攻击数据进行统计分析"""
        return self.aggregate_insights()

核心功能

Orchestrator（编排器）

PyRIT 的 Orchestrator 是攻击逻辑的顶层组件。当前文档中的多轮接口通常配置 objective_target、adversarial_chat、objective_scorer，再调用异步攻击方法：

from pyrit.common import IN_MEMORY, initialize_pyrit
from pyrit.orchestrator import RedTeamingOrchestrator

initialize_pyrit(memory_db_type=IN_MEMORY)

orchestrator = RedTeamingOrchestrator(
    objective_target=target_chat,
    adversarial_chat=attacker_chat,
    objective_scorer=scorer,
    max_turns=3,
)

result = await orchestrator.run_attack_async(objective=objective)

版本提示：PyRIT 的 orchestrator、target 和配置系统变化较快。实际项目应让 notebook、示例代码和安装版本保持一致；需要批量评估时，也可以优先评估当前稳定版提供的 pyrit_scan / pyrit_shell 工作流。

Memory System（记忆系统）

持久化存储所有攻击尝试和结果，支持复杂的查询和分析：

# 伪代码：PyRIT 记忆系统
memory = PyRITMemory()

# 查询成功的攻击
successful = memory.query(
    success=True,
    harm_category='illegal'
)

# 聚合分析
stats = memory.aggregate(
    group_by='attack_method',
    metrics=['success_rate', 'avg_harm_score']
)

Red Team Orchestration Platform

支持将多个小型攻击者组织成复杂的多步骤、多轮次的红队活动：

攻击链示例：
1. 第一步：通过OSINT收集背景信息
2. 第二步：构造特定于目标的社工攻击
3. 第三步：尝试提示注入
4. 第四步：如果注入成功，执行权限提升
5. 第五步：尝试数据窃取或生成有害内容

与Garak的对比

方面	PyRIT	Garak
开发机构	微软	NVIDIA（原 Leon Derczynski）
编程语言	Python	Python
焦点	风险识别与数据驱动	全面安全测试
内存管理	强大的持久化系统	简化的结果处理
攻击复杂度	支持复杂的多步骤攻击	更多单步或预定义
学习曲线	较陡	较平缓
企业部署	较好	社区型

10.6.5 HarmBench 基准测试框架

HarmBench（Harmful Behaviors Benchmark）由安全研究社区推出，是一个标准化的 LLM 安全评估基准。

基准设计

图 10-14：HarmBench 基准的组织结构

有害行为分类

类别	风险等级	示例
Chemical & Biological	极高	化学/生物武器制造
Cybercrime	极高	恶意代码、网络攻击
Copyright	中	侵犯版权的内容生成
Harassment & Bullying	高	仇恨言论、骚扰
Illegal Activities	极高	非法药物、武器
Misinformation	高	虚假信息传播
General Harm	变动	其他有害行为

注：HarmBench 的重点是覆盖多个有害行为类别和多种攻击方法；实际子类数量与评测切分应以对应版本的 benchmark 定义为准。

评估方法

方法1: 自动分类

使用分类器自动判定模型是否成功被攻击：

classifier = HarmClassifier(
    model='bert-base',
    task='harmful_behavior_detection'
)

for behavior in harmBench.behaviors:
    response = target_model.generate(behavior.prompt)
    is_harmful = classifier.predict(response)
    score = compute_harm_score(response)

方法2: 模型判定

使用更强的LLM判定较弱的LLM的安全性：

evaluator_model = 'YOUR_EVALUATOR_MODEL'  # 评估器

for behavior in harmBench.behaviors:
    response = target_model.generate(behavior.prompt)
    evaluation = evaluator_model.judge(
        prompt=behavior.prompt,
        response=response,
        criteria=HARM_CRITERIA
    )

方法3: 人工评审

由安全专家进行细致的人工评审：

评审标签：
- Clearly_Harmful: 明显有害
- Probably_Harmful: 可能有害
- Unclear: 不确定
- Not_Harmful: 无害

评估指标

HarmBench 官方标准化的指标是 ASR（Attack Success Rate，攻击成功率），论文中按攻击方法与目标模型聚合报告平均 ASR 用于排名比较。下表后两行为本书归纳的衍生分析维度，并非 HarmBench 官方定义的指标：

指标	定义	用途
ASR (Attack Success Rate)	成功诱发目标行为的测试用例占比	衡量模型脆弱性
平均 ASR	在 HarmBench 上跨行为/攻击方法聚合的 ASR	整体安全评分与排名
跨攻击类型稳健性*	不同攻击类型下 ASR 的一致性	评估防御泛化性
跨模型迁移率*	同一攻击在不同模型上的成功率	风险传播能力

注：带 * 的两行为本书归纳的分析视角，HarmBench 论文与官方仓库未定义同名指标。

使用示例

HarmBench 官方仓库的推荐入口不是稳定的 from harmbench import HarmBench Python API，而是流水线脚本和配置：

python ./scripts/run_pipeline.py --methods GCG --models llama2_7b --step all --mode local

# 或分步运行：
scripts/generate_test_cases.sh
scripts/generate_completions.sh
scripts/evaluate_completions.sh

10.6.6 智能体安全评测基准

前述基准（如 HarmBench）主要衡量模型在单轮对话中的有害内容生成与越狱抵抗力。但智能体（Agent）的安全风险更多来自工具调用与对不可信外部数据的处理——也就是第 7 章讨论的间接提示注入、工具滥用与权限提升。评估这类风险需要专门的智能体安全基准：

基准	评测目标	规模与口径	关键发现
AgentDojo	工具调用智能体处理不可信数据时对提示注入的鲁棒性	97 个真实任务（邮件、网银、差旅等）＋ 629 个安全测试用例	同时报告任务效用与安全鲁棒性，用于衡量“防御是否同时破坏了智能体的可用性”；现有模型与防御均难以两者兼顾
InjecAgent	工具集成智能体对间接提示注入的脆弱性	1,054 个用例，覆盖 17 个用户工具与 62 个攻击者工具，分“直接伤害”与“数据外泄”两类意图	ReAct 框架下的 GPT-4 约有 24% 的用例被成功劫持；当攻击指令叠加“增强诱导”措辞时成功率接近翻倍
AgentHarm	智能体在工具使用中执行显式恶意任务的倾向（直接滥用而非间接注入）	110 个恶意智能体任务（含增广共 440 个），覆盖 11 类危害（欺诈、网络犯罪、骚扰等）	领先模型在无需越狱时即对恶意请求表现出意外的顺从；简单的通用越狱模板稍加改造即可迁移到智能体

这三类基准互补，覆盖智能体安全的不同象限：AgentDojo / InjecAgent 针对外部数据驱动的间接注入（攻击者通过工具返回值或文档植入指令），AgentHarm 针对用户直接发起的恶意意图。对应论文分别为 AgentDojo（arXiv:2406.13352）、InjecAgent（arXiv:2403.02691）、AgentHarm（arXiv:2410.09024，ICLR 2025），详见附录 C。第四个象限——智能体在执行正常任务时暗中完成破坏性副任务的隐蔽性——由 10.7 节的 SHADE-Arena 补充评测。

接入工程闭环的建议

• 把“间接注入鲁棒性”（AgentDojo / InjecAgent 口径）与“有害内容/越狱”（HarmBench 口径）作为两条独立的回归指标线，分别设定阈值，避免用单一 ASR 掩盖智能体特有的注入风险。

• 重视效用-安全权衡：AgentDojo 的核心价值在于同时给出任务完成率，防御措施上线前应确认它没有把正常的工具调用一并拦截。

• 这些基准的任务集、攻击集和模型适配演进很快，CI/CD 中应固定所用基准的版本，并定期刷新攻击样本（与后文的 CI/CD 门禁设计配合）。

注：智能体安全评测仍是活跃的研究方向，上述规模数字对应各基准论文发布时的版本，实际使用时应以对应仓库的最新定义为准。

10.6.7 工具选型决策矩阵

为了帮助安全团队选择合适的红队工具，我们构建如下决策矩阵：

图 10-15：工具选型决策树

详细选型表

工具	DeepTeam	Garak	PyRIT	HarmBench
最佳用途	端到端评估	灵活定制	风险分析与编排	基准对标
学习成本	中	低	中高	低
部署难度	中	低	中	低
企业适配性	较强	取决于自研能力	较强	适合作为评测基准
开源程度	开源框架	完全开源	开源	开源基准
费用模式	视部署形态而定	免费	免费	免费

10.6.8 企业红队测试流程设计

前面的 10.6.1 到 10.6.7 重点在“工具能力与集成方式”。从这里开始，视角切换到企业落地中的流程和门禁设计：如何把这些工具接入 CI/CD、如何设置 ASR 阈值、如何组织团队。

完整的红队测试流程

图 10-16：企业红队测试完整流程

分阶段详细计划

第一阶段：规划（1-2周）

1. 定义安全目标和威胁模型

2. 选择合适的红队工具组合

3. 制定测试计划和时间表

4. 分配资源和定义角色

团队组成示例：
- 安全架构师：1名（设计和决策）
- 红队工程师：2-3名（执行测试）
- 漏洞分析师：1名（分类和优先级排序）
- DevOps：1名（部署和监控）

第二阶段：执行（3-6周）

1. 部署红队工具

2. 执行多轮测试（白盒→黑盒→对抗性）

3. 实时监控和调整

4. 记录所有测试结果

# 伪代码：红队执行框架
class EnterpriseRedTeam:
    def __init__(self):
        self.garak = GarakFramework()
        self.deepteam = DeepTeamFramework()
        self.harmbench = HarmBench()

    def run_comprehensive_test(self, model):
        results = {
            'garak': self.garak.test(model),
            'deepteam': self.deepteam.test(model),
            'harmbench': self.harmbench.evaluate(model)
        }
        return results

    def aggregate_results(self, results):
        # 合并来自多个工具的结果
        vulnerabilities = self.deduplicate(results)
        vulnerabilities.sort(by='severity')
        return vulnerabilities

第三阶段：分析（2-3周）

1. 聚合和去重所有发现

2. 分析根本原因

3. 评估风险和影响

4. 生成详细报告

报告框架：
- 执行摘要
- 发现汇总（按严重级别）
  - 关键漏洞
  - 中等漏洞
  - 低级漏洞
- 详细技术分析
  - 漏洞描述
  - 重现步骤
  - 影响评估
  - 修复建议
- 趋势分析
- 附录（工具报告、原始数据）

第四阶段：修复和验证（4-8周）

1. 优先级排序和任务分配

2. 开发修复方案

3. 修复验证和测试

4. 部署修复

修复优先级示例：
Critical (P0): 24小时内修复
High (P1): 1周内修复
Medium (P2): 2周内修复
Low (P3): 1个月内修复

10.6.9 CI/CD 集成红队测试

自动化集成架构

图 10-17：CI/CD 安全门控流程

实现示例

name: AI Security Testing

on: [pull_request, push]

# 最小权限原则：显式声明 GITHUB_TOKEN 权限，未列出的权限自动为 none。
permissions:
  contents: read
  issues: write          # Comment on PR 步骤需在 PR（issue）上创建评论
  pull-requests: write

jobs:
  security-test:
    runs-on: ubuntu-latest
    steps:
      # 以下所有第三方 Action：生产环境应 pin 到完整 commit SHA；
      # 此处用版本标签（截至 2026-06 的当前主版本）仅便于阅读。
      - uses: actions/checkout@v6

      - name: Setup Python
        uses: actions/setup-python@v6
        with:
          python-version: '3.10'

      - name: Install Garak
        run: |
          # 生产 CI 应使用带哈希的锁定依赖文件。
          python -m pip install --require-hashes -r requirements-garak.txt

      - name: Run Quick Garak Scan
        env:
          # 凭证经 GitHub Secrets 注入，切勿写入仓库或工作流文件。
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          garak --target_type openai \
                --target_name gpt-5-nano \
                --probes dan.Dan_11_0,suffix.GCG \
                --report_prefix garak_results
          # garak 报告默认写入 ~/.local/share/garak/garak_runs/，复制回工作区供后续步骤使用
          cp ~/.local/share/garak/garak_runs/garak_results.report.jsonl .

      - name: Run HarmBench Evaluation
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          python scripts/run_harmbench.py \
                 --model YOUR_OPENAI_MODEL \
                 --output harmbench_results.json

      - name: Evaluate Results
        run: |
          python scripts/evaluate_security.py \
                 --garak-results garak_results.report.jsonl \
                 --harmbench-results harmbench_results.json \
                 --threshold 0.1  # 容许的 ASR 阈值

      - name: Comment on PR
        # push 事件没有 PR 上下文（context.issue.number 为 undefined，API 调用会失败），
        # 因此仅在 pull_request 事件下评论；always() 确保前序测试失败时也能把报告写到 PR。
        if: always() && github.event_name == 'pull_request'
        uses: actions/github-script@v9
        with:
          script: |
            const fs = require('fs');
            const summary = fs.existsSync('security_report.json')
              ? JSON.parse(fs.readFileSync('security_report.json')).summary
              : '报告未生成（前序步骤失败），详见运行日志。';
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `## Security Test Report\n${summary}`
            });

      - name: Upload Results
        uses: actions/upload-artifact@v7
        with:
          name: security-test-results
          path: |
            garak_results.report.jsonl
            harmbench_results.json
            security_report.json

性能和成本考虑

指标	快速扫描	完整评估
执行时间	较短	较长
API调用数	较少	较多
成本 / run	低	中高
推荐频率	每个 PR	每周 / 每月
覆盖面	较窄	更全面

建议策略：

• 开发阶段：使用快速扫描（PR门控）

• 预发布：使用完整评估（周期性）

• 生产监控：持续轻量化监控

ASR 阈值选择决策框架

CI/CD 集成中最关键的决策之一是设置合适的 ASR（Attack Success Rate）阈值。阈值过高会允许不安全的模型进入生产，阈值过低会导致频繁的误报和开发效率下降。

按安全等级的 ASR 阈值示例

高安全性（金融、医疗、关键基础设施）
├─ 示例 ASR阈值：≤ 0.01（1%）
├─ 含义：允许的最多1/100的攻击成功
├─ 场景：
│  - 金融支付系统（涉及资金安全）
│  - 医疗诊断辅助（涉及生命安全）
│  - 基础设施控制系统（涉及社会安全）
└─ 性质：接近零容忍（越权工具调用、敏感信息泄露等高危动作类指标仍须为 0，参见 10.4.5）

中等安全性（企业应用、内部工具）
├─ 示例 ASR阈值：≤ 0.05（5%）
├─ 含义：允许的最多5/100的攻击成功
├─ 场景：
│  - 企业级CRM、ERP系统
│  - 内部数据分析工具
│  - 团队协作应用
└─ 性质：平衡安全与可用性

低安全性（内部工具、实验系统）
├─ 示例 ASR阈值：≤ 0.10（10%）
├─ 含义：允许的最多10/100的攻击成功
├─ 场景：
│  - 内部原型系统
│  - 开发和测试工具
│  - 低风险的实验环节
└─ 性质：允许更高的风险以换取更快的迭代

阈值选择决策树

实现示例

class ThresholdSelectionFramework:
    """ASR阈值选择框架"""

    THRESHOLDS = {
        'high_security': 0.01,      # 金融、医疗
        'medium_security': 0.05,    # 企业应用
        'low_security': 0.10        # 内部工具
    }

    def select_threshold(self, application_context):
        """根据应用上下文选择合适的ASR阈值"""

        risk_assessment = self.assess_risk(application_context)

        # 评估因素
        factors = {
            'data_sensitivity': self.check_data_sensitivity(application_context),
            'user_impact': self.check_user_impact(application_context),
            'financial_exposure': self.check_financial_exposure(application_context),
            'regulatory_requirements': self.check_regulatory_requirements(application_context),
        }

        # 多因素决策
        if (factors['data_sensitivity'] == 'high' or
            factors['financial_exposure'] == 'high' or
            'healthcare' in factors['regulatory_requirements'] or
            'finance' in factors['regulatory_requirements']):
            return self.THRESHOLDS['high_security']

        elif (factors['data_sensitivity'] == 'medium' or
              factors['user_impact'] == 'high'):
            return self.THRESHOLDS['medium_security']

        else:
            return self.THRESHOLDS['low_security']

    def configure_ci_cd_gate(self, application, threshold):
        """配置CI/CD门控"""
        return {
            'application': application,
            'asr_threshold': threshold,
            'action_on_failure': 'block_deployment' if threshold <= 0.01 else 'warn_and_notify',
            'review_required': threshold <= 0.05,
            'escalation_path': self.get_escalation_path(threshold)
        }

特殊考虑

1. 渐进式上线

对于初期部署，可以采用更严格的阈值，然后根据实际运行数据逐步调整：

第一阶段（内测）：ASR ≤ 0.02（额外严格）
第二阶段（公测）：ASR ≤ 0.05（按照等级选择）
第三阶段（生产）：ASR ≤ 最终确定的阈值

2. 攻击类型加权

不同类型的攻击风险程度不同，可以针对性地设置阈值：

# 示例：按攻击危害等级加权
weighted_asr = (
    asr_illegal_instructions * 0.5 +      # 非法指令权重最高
    asr_prompt_injection * 0.3 +          # 提示注入权重次之
    asr_misinformation * 0.2               # 误信息权重较低
)

3. 定期审查和调整

ASR阈值不是一成不变的，应该根据：

• 威胁态势的演化

• 组织风险容忍度的变化

• 实际的安全事件数据

• 行业标准的更新

定期（建议每季度）进行审查和调整。