AI 红队不是传统渗透：安全人必须先重建的 6 个认知

最近学了一段时间的AI安全，我觉得传统红队经验能迁移到 AI 安全，但不能原样照搬。可以继续用侦察、攻击面枚举、权限提升、横向移动、证据链和报告表达这些思维方式，可是目标系统已经变了。

AI 红队不是「拿一堆越狱提示词去问模型」。那是测试里的一个片段，不是红队。真正的 AI 红队要回答的是：一个企业把模型、数据、工具、身份和业务流程接在一起之后，攻击者能不能让系统做出业务不希望它做的事？

这篇是新版 AI 红队路线的起点，我把 AI-RTA 课件里的基础概念重组成更适合国内安全从业者的版本。它不讲数学推导，也不给可直接复用的攻击命令，重点是把六个常见误解掰开：

1. AI 红队测的是系统，不只是模型；
2. 攻击面不在端口列表里，而在数据流和权限图里；
3. 基础设施、数据、模型、应用四类向量要串起来看；
4. 输出不确定，证据链必须重新定义；
5. 授权范围不只是“能不能访问某个 URL”；
6. MITRE ATLAS 和 OWASP 是沟通地图，不是照抄剧本。

一、认知一：AI 红队测的是系统，不只是模型

很多人把 AI 红队理解成“测试模型会不会被越狱”。这个理解太窄了。

模型当然重要，但在企业环境里，模型经常只是一个上下文处理器。它读取用户输入、检索结果、历史会话、系统规则，然后决定回答什么或调用什么。真正决定风险的是它周围的东西：

层	典型对象	安全问题
模型层	商用 API、私有模型、微调模型、多模态模型	是否被诱导偏离任务，是否泄露训练或上下文内容
应用层	Web 入口、API、系统提示词、会话、前端	输入如何拼接，输出如何被展示或执行
数据层	文档、知识库、向量库、工单、用户反馈	谁能写入，检索是否越权，来源是否可信
Agent 层	工具调用、记忆、MCP server、多 Agent 编排	模型能调用什么，参数谁决定，结果谁审计
协议/供应链层	模型网关、插件、依赖、模型文件、tokenizer	来源是否可信，版本是否可追溯，更新能否回滚
基础设施层	云账号、K8s、Pod、ServiceAccount、Secret、网络	应用身份能到哪里，出站是否可控

举个例子。一个「智能客服助手」看起来只有一个聊天框，但后面可能是：

客户输入
  → Web/API 入口
  → 输入过滤和会话管理
  → 模型网关
  → RAG 检索知识库
  → 模型生成回答
  → Agent 判断是否查工单
  → 工单 API
  → 内部数据库
  → 日志与审计

如果只测模型，你可能会问：「能不能让模型忽略规则？」但如果做系统级红队，要问的是：

1. 客户提交的工单评论会不会进入知识库？
2. 检索结果会不会带着路径、权限或敏感字段返回？
3. 模型能不能驱动工单查询、退款申请或内部通知？
4. 查询工具使用的是用户身份、服务身份，还是数据库管理员身份？
5. 一次异常调用能不能被还原成完整证据链？

所以呢：AI 红队的范围不是模型官网上的几个 prompt，而是模型接入业务后的所有权限和数据流。

二、认知二：攻击面不在端口列表里，而在数据流和权限图里

传统渗透测试仍然要做资产发现、端口探测、Web 指纹、身份认证和内网横移。这些方法没有失效，只是不够了。

AI 系统的一个入口可能暴露在 443 端口，流量看起来就是干净的 HTTPS JSON。但从红队视角看，入口后面有一张完全不同的图：

外部用户 / 内部员工 / 第三方文档
        │
        ▼
应用入口与会话管理
        │
        ▼
上下文组装：系统规则 + 用户输入 + RAG 结果 + 历史记忆
        │
        ▼
模型网关 / 模型服务
        │
        ▼
模型输出 / 工具调用建议
        │
        ▼
工具层：搜索、数据库、文件、邮件、审批、云 API
        │
        ▼
内部系统、数据存储、身份与日志

安全评估前至少要画清六类边界：

边界	关键问题
用户输入边界	哪些字段会进入模型？哪些会被持久化？
内容来源边界	知识库、网页、附件、工单评论、第三方返回值是否可信？
上下文边界	系统规则、用户输入、检索结果、记忆是否隔离标记？
模型输出边界	输出是否会进入前端、邮件、SQL、代码、审批或工具参数？
工具权限边界	模型能选择动作，还是只能选择预定义动作？
平台身份边界	应用 Pod、模型网关、工具服务各自使用什么身份？

我常用的判断是：不要先问“这里能不能绕过”，先问“这段内容从哪来、能到哪去、以什么身份执行”。

例如，一份用户上传的 PDF 表面上是资料，但如果它会被解析、切片、写入向量库，再在未来某次提问中被检索进模型上下文，它就不是普通文件，而是一个延迟进入上下文的输入源。

同样，一个工具返回值表面上只是 JSON，但如果它会再次拼进模型上下文，下一轮模型可能根据它生成新的工具参数，那么这个返回值也不是普通数据。

所以呢：AI 安全评估要先把“不可信内容进入高权限上下文”的路径画出来，再决定测试优先级。

三、认知三：基础设施、数据、模型、应用要串起来看

AI-RTA 基础模块把 AI 攻击向量分成四类：基础设施、数据、模型、应用。这个分类很适合入门，但不要把它们当成四个独立桶。

向量	典型对象	安全要回答的问题	常见控制点
基础设施	云账号、API Key、模型服务、K8s、容器、Secret、CI/CD	谁能部署模型？谁能读取凭据？应用能访问哪里？	IAM、RBAC、网络策略、密钥管理、出站控制
数据	训练数据、微调数据、知识库、向量库、用户上传、工单评论	谁能写入？来源是否可信？敏感数据如何分级？	数据来源审批、解析隔离、权限感知检索、DLP
模型	商用模型、私有模型、LoRA adapter、tokenizer、评估集	是否被诱导、提取、投毒或后门化？版本能否回滚？	模型准入、行为回归、版本签名、推理审计
应用	Web/API、系统提示词、Agent、工具、MCP、多 Agent	不可信输入能否影响工具？输出能否驱动业务动作？	参数白名单、工具策略、人工确认、执行审计

这四类向量经常组合出现：

1. 基础设施 + 数据：知识库同步服务拿到过宽云凭据，攻击者影响它读取或写入的文档范围。
2. 数据 + 模型：恶意文档进入知识库，未来被检索后影响模型回答。
3. 模型 + 应用：模型输出被当成工具参数，导致模型建议变成系统动作。
4. 应用 + 基础设施：Agent 工具运行在过宽权限的 Pod 里，一次参数问题变成内网或云资源访问问题。

红队计划里不要只写「测试提示注入」「测试模型提取」，要写成一条条可验证的链路：

入口来源
  → 进入哪个上下文
  → 影响哪个模型决策
  → 驱动哪个工具
  → 使用哪个身份
  → 到达哪个资源
  → 留下哪些日志
  → 造成什么业务影响

所以呢：单点风险只有放进链路里，才能判断它到底是低危噪音，还是真实业务风险。

四、认知四：输出不确定，证据链必须重新定义

传统 Web 漏洞的证据往往比较直接：某个请求返回了某个状态码、某个响应体、某段错误信息，或者某个未授权对象可以被读取。AI 系统不同，它有随机性、上下文依赖、模型版本差异和检索结果差异。

同一个问题，在不同时间、不同会话、不同检索结果、不同模型版本下，可能得到不同回答。所以 AI 红队不能只截一张「模型说了不该说的话」的图就结束。

更可靠的证据至少要包含：

证据维度	需要记录的内容
环境	测试环境、模型名称、模型版本、网关版本、应用版本
会话	会话 ID、用户角色、租户、时间、上下文轮次
输入	原始输入、脱敏后的输入、使用的模板或测试用例 ID
检索	命中的知识库来源、文档 ID、路径、权限、相似度分数
工具	工具名、参数、调用身份、目标资源、策略决策、返回摘要
输出	模型回答摘要、引用内容、是否暴露敏感字段
策略	是否命中过滤器、是否放行、为什么放行
影响	信息暴露、越权操作、错误执行、成本损失、合规风险

这里要特别注意三个误报：

1. 模型复述了资料，不代表一定泄露训练数据。 要确认内容来自用户上传、公开网页、知识库还是模型参数。
2. 模型输出了危险文本，不代表系统会执行。 要看输出是否进入命令、SQL、代码解释器、审批或自动化流程。
3. 单次成功不代表稳定复现。 要在授权范围内确认触发条件、频率和版本依赖。

反过来说，也不能因为模型「大部分时候拒绝」就判定安全。如果一条工单评论今天写入，下周被别人提问时触发，它就不是单次请求问题，而是持久化内容进入上下文的问题。

所以呢：AI 红队报告要从“截图证明”升级为“条件、版本、来源、路径、影响和复现边界都清楚”。

五、认知五：授权不只是“能不能访问某个 URL”

传统红队授权书通常会写目标域名、IP、测试时间、允许的测试方式和禁止行为。AI 红队也需要这些，但还要额外回答很多问题：

1. 能不能使用真实客户数据？
2. 能不能上传文件？
3. 能不能写入知识库、记忆或用户配置？
4. 能不能触发真实邮件、审批、支付、通知？
5. 能不能调用第三方模型 API？费用谁承担？
6. 能不能使用公开数据集或公开模型仓库里的样例？
7. 测试产生的会话、日志和文档如何保留、脱敏和销毁？
8. 如果模型输出了个人敏感信息，报告如何存储？

AI 红队的授权范围应该至少覆盖七个字段：

# AI 红队授权范围模板

## 1. 业务目标
- 被测系统：
- 业务负责人：
- 安全负责人：
- 主要风险关注点：

## 2. 环境与版本
- 允许环境：
- 禁止环境：
- 模型/网关/应用版本：
- 时间窗：

## 3. 数据边界
- 可使用数据：
- 脱敏要求：
- 禁止使用的数据：
- 发现敏感数据后的处理方式：

## 4. 技术边界
- 允许测试：
  - 提示注入与越狱行为测试；
  - RAG 来源与权限验证；
  - 工具参数边界验证；
  - 只读内部可达性验证。
- 需单独审批：
  - 写入知识库；
  - 写入记忆；
  - 触发通知、审批或支付；
  - 批量读取或导出；
  - 调用第三方付费 API。
- 禁止行为：
  - 破坏服务；
  - 修改生产数据；
  - 建立持久化后门；
  - 使用真实客户数据做大规模验证；
  - 对第三方服务发起测试。

## 5. 预算与频率
- 交互次数上限：
- 模型调用预算：
- 并发限制：
- 触发风控后的处理：

## 6. 证据与报告
- 证据保存位置：
- 脱敏规则：
- 保留期限：
- 可接触人员：

## 7. 止损与联系人
- 立即停止条件：
- 业务联系人：
- 安全联系人：
- 应急处置方式：

这个模板比「能不能打这个 IP」复杂，但很必要。AI 测试经常涉及数据、第三方服务、成本和声誉，如果范围不清，很容易把一次评估变成业务事故。

所以呢：AI 红队项目启动前，授权书要回答技术边界、数据边界、成本边界和证据边界。

六、认知六：MITRE ATLAS 和 OWASP 是地图，不是照抄剧本

很多团队会问：AI 红队是不是照着 MITRE ATLAS 或 OWASP LLM Top 10 跑一遍？

这两个框架很有价值，但用法不是机械对号入座。

框架	适合做什么	不适合做什么
MITRE ATLAS	描述 AI 相关对抗行为，帮助团队按阶段组织攻击思路和检测思考	不能当成“跑完即证明安全”的测试用例集
OWASP LLM Top 10	总结 LLM 应用常见风险，方便开发、安全和业务沟通	不能替代企业自己的架构分析、数据分级和权限模型
内部威胁模型	结合业务资产、数据流、身份和合规要求排优先级	不应该脱离真实架构抄通用模板

我建议的用法是三步：

1. 用 ATLAS 和 OWASP 打开讨论。 让开发、安全、数据和业务知道 AI 风险不止“模型乱说话”。
2. 把它们映射到自己的系统。 例如某条风险对应我们的知识库、工具、模型网关、Pod 身份或第三方插件。
3. 转成可验证的控制点和复测项。 每个风险都要回答放在哪里修、谁来修、怎么验证。

例如，不要只说「我们有提示注入风险」。可以拆成：

提示注入
  ├─ 用户直接输入 → 模型上下文
  │    控制点：输入规范化、策略层、会话隔离
  ├─ 外部文档 → 解析 → 向量库 → 检索结果
  │    控制点：来源审批、解析隔离、信任分级、权限感知检索
  ├─ 工单评论 → 持久化 → 未来检索
  │    控制点：写入审批、内容标记、定期审计、可回滚
  ├─ 工具返回值 → 下一轮上下文
  │    控制点：返回值白名单、schema 校验、二次注入检测
  └─ 模型输出 → 工具参数
       控制点：参数枚举、动作分级、人工确认、执行审计

这样框架才真正落到系统里。

七、国内企业常见场景的优先级

不同 AI 系统的红队重点差别很大。不要每个项目都从「越狱」开始，先看业务资产和权限。

场景	典型能力	红队优先问题
智能客服	工单查询、知识库回答、订单解释、转人工	客户数据是否越权检索？工单内容能否进入上下文？回答能否触发内部动作？
企业知识库助手	文档问答、摘要、权限过滤	谁能上传文档？检索是否遵守部门/租户权限？sources 是否暴露内部路径？
代码助手	代码补全、仓库问答、生成代码、执行任务	仓库权限如何隔离？生成代码是否会被执行？依赖和插件是否可信？
办公自动化	邮件、日历、文档、审批、跨系统操作	外部邮件能否影响任务？工具能否越权访问他人日程或文档？审批是否有人工确认？
模型平台	多租户、模型路由、配额、插件、微调	租户是否隔离？模型资产能否被替换？API Key 是否可被滥用？
数据分析 Agent	查数据库、生成 SQL、制作报表	模型能否自由生成 SQL？查询账号是否最小权限？结果是否会被外发？

如果你不知道先测哪个，我会按下面顺序排：

1. 先测有外部输入的 Agent：它连接了用户输入和内部动作。
2. 再测有写入能力的 RAG：写入可以造成未来触发。
3. 再测跨系统工具链：邮件、审批、数据库、云 API 的影响通常比单次回答更严重。
4. 最后测纯模型对话：如果没有业务权限，很多越狱只是安全策略问题，不一定是高危业务漏洞。

所以呢：红队优先级来自业务影响，不来自技术话题的热度。

八、AI 红队启动清单

开工前，我会检查下面这些项。任何一项答不出来，都先补范围和架构，再谈测试。

A. 系统与资产

#	检查项	负责人	需要的证据
1	明确被测业务和目标	业务负责人	目标卡、业务流程
2	列出对外入口	开发	域名、API、客户端、鉴权方式
3	列出模型来源和版本	平台	模型名、版本、供应商、部署方式
4	列出模型网关和策略层	平台/安全	路由、配额、过滤、审计能力
5	列出 RAG 来源	数据/开发	知识库、网页、工单、附件、第三方文档
6	列出向量库和嵌入模型	开发	集合、权限、索引、来源字段
7	列出 Agent 工具	开发	工具名、schema、权限、目标系统
8	列出记忆和会话存储	开发	存储、隔离、保留期、删除方式
9	列出应用身份	SRE	Pod、ServiceAccount、云身份、Secret
10	列出日志链路	安全/SRE	应用日志、模型日志、工具日志、云审计

B. 边界与规则

#	检查项	负责人	需要的证据
11	明确可测试环境	安全+业务	授权书、环境列表
12	明确可用数据分级	数据/法务	数据类型、脱敏要求、禁止项
13	明确允许的测试技术	安全	允许/需审批/禁止清单
14	明确写入和持久化限制	开发/业务	知识库、记忆、配置、账号变更规则
15	明确外部请求和成本限制	业务/平台	预算、频率、第三方 API 限制
16	明确证据保存与脱敏	安全	存储位置、保留期、访问人员
17	明确止损条件	业务/安全	触发风控、影响客户、数据外发时怎么办
18	明确联系人和响应流程	业务/安全	紧急联系人、响应时间
19	明确修复责任	开发/安全	每类风险的责任角色
20	明确复测标准	安全	修复后如何验证，回归范围是什么

这份清单不需要一开始就做到完美，但必须能回答：测什么、谁能同意、数据怎么处理、动作到哪里停、证据怎么保存、出事找谁。

九、最小交付物不是漏洞截图，而是四张图

如果是一个两周期以内的 AI 红队评估，我建议至少交付：

1. 组件与数据流图

   • 谁是入口；
   • 哪些内容进入上下文；
   • 哪些结果返回给用户；
   • 哪些动作触达内部系统。

2. 信任边界图

   • 完全不可信：用户输入、公开网页、上传文件、第三方内容；
   • 半可信：RAG chunk、历史会话、工具缓存、第三方 API 返回；
   • 应用控制：系统提示词模板、Agent 编排规则、工具 schema；
   • 内部能力：数据库、文件、邮件、审批、云 API；
   • 平台权限：Pod、ServiceAccount、云身份、CI/CD。

3. 风险链表

   • 每条风险都要写入口、路径、身份、目标、影响、证据和限制条件。

4. 控制点与复测清单

   • 修复建议不能只写“加强提示词”或“增加过滤”；
   • 要写清楚校验发生在输入层、上下文层、工具层、身份层还是输出层；
   • 还要写清谁来改、什么时候改、怎么复测。

一句话总结：传统红队找的是“系统哪里可以被打破”，AI 红队找的是“模型、数据、工具、身份和业务流程组合后，哪里会变成新的权限边界”。