Wiki Notes

Appearance

AI红队测试专题 ​

版本：v1.3

最后更新：2026-07-09

适用对象：需要为 Agent、RAG、客服、审批助手、工具调用系统和多租户 AI 产品建立系统化对抗测试能力的产品、研发、平台、安全与合规同学

很多团队会把 AI 评测理解成：

  • 看准确率
  • 看主观效果
  • 看模型是否能完成任务

但只要系统进入真实业务，另一个同样重要的问题就会出现：

  • 它会不会被人故意搞坏

这就是红队测试要解决的问题。

根据 2026-07-08 可访问的 OpenAI Red teaming / Safety best practices / Building agents / Guardrails and human review、Anthropic Mitigate jailbreaks and prompt injections，以及 NIST AI RMF / 对抗机器学习资料，可以先建立一个关键共识：

  • 红队测试不是“找几个刁钻 prompt 试一试”，而是围绕风险面系统设计对抗样例，并把失败结果回流到 guardrails、权限、审批、门禁和回归集里。

1. 什么是 AI 红队测试 ​

OpenAI 当前 Red teaming 文档把它定义为：

  • 使用 adversarial test cases 去发现 unsafe、insecure 或 policy-violating behavior

工程上可以把它理解为：

  • 普通评测更关注“正常情况下好不好用”
  • 红队测试更关注“异常和恶意情况下会不会出事”

1.1 红队测试不是普通 eval 的替代品 ​

它更像是：

  • 对普通评测看不到的风险面做补充

换句话说：

  • 正常评测负责看“会不会做事”
  • 红队测试负责看“会不会被带坏”

1.2 红队测试的对象不只是模型输出 ​

真正该被测试的，通常还包括：

  • 检索链路
  • 工具调用
  • 审批门禁
  • 多轮状态
  • 租户边界
  • 日志与审计链

2. 红队测试为什么不能省 ​

AI 系统和传统软件不同，很多风险不是简单 bug，而是行为风险：

  • 越权回答
  • prompt injection
  • 敏感信息泄露
  • 工具被诱导误调用
  • 输出高风险建议
  • 审批与 guardrail 被绕过

这些问题如果只用正常样例测试，往往很难暴露。

2.1 很多安全问题不会直接报错 ​

比如：

  • 没有任何异常码
  • 系统也没有崩
  • 但它已经把敏感信息带出来了

2.2 很多风险来自“组合攻击” ​

例如：

  • 恶意文档 + 检索召回 + 工具说明污染
  • 多轮对话累积诱导
  • 角色扮演绕过 + 审批缺失

NIST 当前对对抗机器学习与生成式 AI 风险的资料也都在强调：

  • 需要用结构化测试主动探查脆弱面，而不是只依赖事后事故

3. 红队测试和安全评测、guardrails、回归分别是什么关系 ​

这几个概念很容易混在一起，但角色不同。

3.1 红队测试 ​

重点是：

  • 发现脆弱点

3.2 guardrails ​

重点是：

  • 拦住已知高风险行为

3.3 安全回归 ​

重点是：

  • 修复过的问题别再回来

3.4 上线门禁 ​

重点是：

  • 这次变更到底能不能进生产

一句话串起来就是：

  • 红队发现问题
  • guardrails 拦住问题
  • 安全回归防止复发
  • 门禁决定放不放行

4. 哪些系统最应该优先做红队测试 ​

尤其建议优先覆盖这些场景：

  • Agent 系统
  • 企业知识库
  • 客服自动化
  • 语音与实时交互
  • 具备工具调用和外部动作能力的系统
  • 多租户知识与审批系统

只要系统能：

  • 访问私有数据
  • 调用外部工具
  • 触发真实动作

红队测试价值就会显著上升。

5. 红队测试通常测什么 ​

5.1 Prompt Injection ​

典型风险包括：

  • 诱导忽略系统指令
  • 诱导泄露内部提示词
  • 诱导绕过权限边界

5.2 数据泄露 ​

典型风险包括：

  • 敏感字段暴露
  • 跨租户内容召回
  • 私有知识被无权限用户拿到

5.3 工具越权 ​

典型风险包括：

  • 不该调用时调用工具
  • 使用错误参数调用工具
  • 执行高风险动作却没有审批

5.4 输出风险 ​

典型风险包括：

  • 危险建议
  • 违法违规内容
  • 不符合领域规范的误导内容

5.5 流程与审批风险 ​

典型风险包括：

  • human review 没被触发
  • guardrail 被绕过
  • 拒绝后工作流仍继续执行

5.6 多轮状态与 handoff 风险 ​

典型风险包括：

  • 上一轮敏感上下文继续被利用
  • handoff 后状态边界失效
  • 不同角色共享了不该共享的中间信息

6. 红队样例不该“随便写”，而要按风险面设计 ​

好的红队样例通常不是：

  • 随便写一句刁钻提示

更实用的设计方式通常是按风险面来建模：

  • 输入攻击
  • 上下文污染
  • 工具诱导
  • 角色扮演绕过
  • 多轮累积偏移
  • 文件 / 网页 / 检索内容中的恶意注入

6.1 样例设计的关键不是数量，而是覆盖结构 ​

OpenAI 当前 Safety best practices 文档明确建议：

  • 用广泛输入和刻意试图“破坏”产品的行为来测试系统

这说明红队测试更像：

  • 风险建模问题

而不是：

  • 样例越多越好

6.2 样例最好和真实系统对象绑定 ​

例如：

  • 哪个工具被攻击
  • 哪个租户边界被尝试突破
  • 哪类知识源最容易被注入

这样后续修复更容易落到具体位置。

7. 红队样例最好怎么分桶 ​

一个更实用的分桶方式通常是：

  • injection
  • data_exfiltration
  • tool_misuse
  • unsafe_output
  • approval_bypass
  • tenant_boundary
  • context_poisoning
  • handoff_leak

7.1 分桶的价值是什么 ​

它可以帮助团队看清：

  • 哪类风险在上升
  • 哪类问题修复后又复发
  • 哪些 guardrails 对哪类攻击最无效

7.2 分桶也更方便做门禁 ​

比如：

  • tenant_boundary 桶出现回退，直接阻断发布
  • unsafe_output 某些低风险场景回退，允许灰度观察

8. 一套更实用的红队测试流程 ​

text
Identify Risk Surfaces
 -> Design Adversarial Cases
 -> Run Tests
 -> Log Failures
 -> Add Guardrails / Fixes
 -> Re-test
 -> Add To Regression Set

8.1 风险面识别必须先于样例编写 ​

先回答：

  • 系统能看什么
  • 系统能调什么
  • 系统能做什么
  • 系统最怕哪类误放

8.2 失败记录必须结构化 ​

至少建议保留：

  • risk_bucket
  • query_or_payload
  • content_source
  • tool_name
  • tenant_scope
  • trace_id
  • policy_version
  • approval_path

8.3 修复后必须回流回归集 ​

否则红队测试就会一直停留在：

  • 每次都重新“手工找洞”

而不是形成系统学习能力。

8.4 最好给每轮红队活动一个明确 campaign charter ​

很多团队说自己在“做红队”，实际只是：

  • 临时拉几个人试几个提示词

更稳妥的做法通常是每轮都定义清楚：

  • 这轮测什么系统边界
  • 哪些风险桶是重点
  • 哪些对象在范围内，例如 retrieval、tooling、approval、memory、tenant boundary
  • 哪些指标会作为 blocking signal
  • 失败后由谁接整改

一个最小 campaign charter 通常至少包含：

yaml
campaign_id: redteam_q3_agent_ops
target_surface:
  - prompt_injection
  - approval_bypass
  - tenant_boundary
  - tool_misuse
in_scope_assets:
  - billing_agent
  - knowledge_rag
  - approval_router
success_signals:
  - false_allow_rate_by_bucket
  - reproducible_trace_count
  - blocker_count
owners:
  red_team_owner: ai-safety
  remediation_owner: agent-platform

这会让红队测试从“活动”更像：

  • 一次有边界、有产出的工程 campaign

9. 红队测试结果到底该怎么看 ​

不要只看：

  • 有没有被打穿

还应该看：

  • 命中率
  • 误放率
  • 误杀率
  • 是否留下可审计证据
  • 是否能够自动降级或转人工
  • 哪类风险复发最多

9.1 不同风险桶的结果不能只看总平均 ​

例如：

  • 总体 95% 都过了
  • 但 tenant_boundary 只过 70%

在企业系统里，这通常仍然是不可接受的。

9.2 失败结果要能映射到整改动作 ​

例如：

  • 该修 prompt
  • 该修 tool scope
  • 该修 retrieval filter
  • 该补审批
  • 该补回归

9.3 红队结果最好按 false allow / false block 分开看 ​

很多团队更容易盯住：

  • 系统有没有被打穿

但在生产里还要一起看：

  • 为了防住攻击，是否把正常请求误伤得太多

更实用的拆法通常是：

指标更关注什么更常见后果
false_allow_rate攻击样例不该通过却通过越权、泄露、误执行、审批漏放
false_block_rate正常或低风险样例不该被拦却被拦客诉、人工接管上升、审批积压、体验保守化

这对 guardrails、approval policy 和 risk routing 尤其重要，因为：

  • 只看 false allow，系统可能越来越保守
  • 只看 false block，系统又可能越来越冒险

9.4 红队失败最好有 reproducibility packet ​

如果失败样例只能靠口述复现，后面修复会非常慢。

更建议至少保留：

  • sample_id
  • trace_id
  • risk_bucket
  • tool_path
  • tenant_scope
  • retrieval_context
  • policy_version
  • prompt_version
  • expected_decision
  • actual_decision

这样一条失败样例才足够支持：

  • 修复
  • 复测
  • 回归
  • 审计

10. 红队测试和上线门禁怎么结合 ​

更稳的做法通常是：

  1. 把关键红队样例固化成安全回归集
  2. 高风险变更前固定重跑
  3. 明确哪些桶退化会阻断发布
  4. 对通过但高风险的变更仍要求灰度与人工观察

这样红队测试才会变成：

  • 工程控制

而不是：

  • 演示活动

10.1 最适合直接阻断发布的红队回退 ​

例如：

  • 租户边界突破
  • 审批绕过
  • 高敏数据泄露
  • 高风险工具自动误执行

10.2 最适合放入观察门禁的回退 ​

例如：

  • 某类 jailbreak 误杀率略上升
  • 某些边缘场景保守度提高

10.3 红队最好和 shadow / canary 一起看 ​

很多对抗样例在线下能打穿，但在线上真实流量组合下会暴露出更复杂的问题，例如：

  • 恶意文档只有在真实 retrieval 排序里才会被召回
  • 某类工具诱导只有在真实路由策略里才会触发
  • approval backlog 只有在小流量放量时才会暴露

因此更稳的发布路径通常是：

text
Offline red team
 -> Fix / tighten policy
 -> Re-test
 -> Shadow adversarial replay
 -> Canary with high-risk buckets watched

如果红队结果和灰度完全脱节，就很容易出现：

  • 线下“测过了”
  • 线上还是以新的方式出问题

11. 红队测试和风险分层路由应该一起设计 ​

红队测试不应该只测“能不能被打穿”，还应该帮助定义：

  • 哪些请求应该被提到高风险链路
  • 哪些工具应该默认收缩
  • 哪些租户场景要更保守

11.1 红队样例是风险分层的最好输入之一 ​

因为它们本身就告诉你：

  • 哪类输入最危险
  • 哪类上下文最容易出事

11.2 高风险桶的攻击样例更适合直接映射成路由规则 ​

例如：

  • 涉及导出、外发、改权限的提示词
  • 涉及跨租户或跨部门信息聚合的 query

11.3 红队样例也适合直接喂给 policy / route table ​

例如把样例中稳定出现的模式沉淀成：

  • 更高风险分
  • 强制人工审批
  • 缩小工具白名单
  • 改走只读链路
  • 改走高强度 guardrails profile

这样红队结果就不会只停在报告里，而会反过来塑造运行时控制面。

12. 常见反模式 ​

12.1 把红队测试当成“安全团队的一次演习” ​

结果是：

  • 演习结束
  • 工程体系没变

12.2 只测 prompt，不测工具与检索链路 ​

这会让很多真实风险长期隐身。

12.3 红队失败样例不回流 ​

同类问题就会重复出现。

12.4 只看总通过率 ​

这样最容易掩盖高风险桶的结构性失败。

12.5 红队样例和门禁完全脱节 ​

最后红队结果不会真正影响发布决策。

12.6 红队只测单轮文本，不测系统组合 ​

现实里很多高风险问题来自：

  • 检索内容污染 + prompt injection
  • approval pause 失效 + tool auto-exec
  • handoff 状态串漏 + tenant boundary

如果只测单轮对话，最危险的系统性风险会被漏掉。

12.7 红队报告没有 owner 和整改 SLA ​

结果通常是：

  • 问题都写出来了
  • 但没人追修复、没人追回归、没人追何时关闭

13. 更建议的建设顺序 ​

第一阶段：先围绕最高风险面建最小 campaign ​

优先抓：

  • prompt injection
  • tenant boundary
  • approval bypass
  • tool misuse

第二阶段：把失败样例结构化并接进回归 ​

让每次成功发现的问题都能留下来。

第三阶段：把红队 blocker 接进发布门禁 ​

至少让这些问题不能再静默进生产。

第四阶段：把灰度、告警和 near miss 回灌 ​

让红队不再只依赖人工拍脑袋造样例。

第五阶段：持续做 campaign review ​

周期性回答：

  • 这轮最危险的风险桶是什么
  • 哪些 guardrails 最无效
  • 哪些问题已经可以转成稳定回归

14. 推荐搭配阅读 ​

15. 重点官方资源 ​

以下资源已按 2026-07-09 复核可访问：

16. 落地检查清单 ​

  • 是否已识别核心风险面
  • 是否为每轮红队定义了 campaign charter
  • 是否对红队样例做了风险分桶
  • 是否覆盖检索、工具、审批、多轮和租户边界
  • 是否保留结构化失败证据和 reproducibility packet
  • 是否将关键失败样例回流回归集
  • 是否将关键风险桶接入上线门禁
  • 是否明确整改 owner、SLA 和关闭条件