AI 红队测试：用威胁模型系统寻找可造成真实影响的失败链

红队测试的第一步不是急着让模型“说坏话”，而是先写清楚：我们在保护什么、谁在攻击、什么样的结果不可接受。把目标定义成“测试模型是否会说坏话”，表面上有对象，实际上无法执行——因为“坏话”没有边界，既无法判断一次尝试算不算成功，也无法说明失败意味着什么。真正可执行的红队目标应当落在资产和影响上：跨租户文档泄露、未经批准的资金转账、恶意代码执行、绕过安全策略、或者操纵负责审核的人或流程。只有当影响可以被具体命名时，一次攻击尝试才有明确的成功标准。

在定义影响的同时，还要定义攻击者。攻击者模型需要回答：攻击者能控制哪些输入（提示、文件、图片、工具参数、被注入到检索语料里的文本）；能使用哪些账号或身份；掌握了多少关于系统的知识（例如是否知道系统提示词、是否了解内部工具名称）；拥有多少预算和算力；以及能否进行多轮试错。能力边界决定了结论能不能被解释——如果攻击者被允许无限制地重试、无限制地消耗预算、无限制地知道系统内部细节，那么“攻破”和“没攻破”都无法归因到某个具体弱点；如果能力被压得太低，又可能漏掉真实存在的路径。能力边界是后续判断严重度、修复优先级和覆盖率的基础。

资产和攻击者的交汇点是攻击面。一个由模型驱动的系统，攻击面远不止模型本身。系统提示词可以被诱导泄露或覆盖；RAG 检索语料可以被投毒，让模型读到被篡改的证据；上传的文件和图像是携带载荷的入口；工具参数是模型对外行动的通道；插件、缓存、记忆、日志以及面向人类的管理界面都可能是攻击路径。模型的拒答率只是其中一层，而且通常不是最关键的一层——一个处处拒答、却仍会执行危险工具调用的系统，并不比一个偶尔说错话的系统更安全。因此，红队的关注点要从“模型有没有拒绝某个措辞”，转移到“从这些攻击面出发，能否触达之前定义的那种不可接受影响”。

随机地投喂一万条提示，即使数量很大，也未必覆盖到最危险的路径，因为危险并不均匀分布在提示空间里，而是集中在少数几条能触达真实影响的因果链上。为了把测试资源花在正确的地方，需要把威胁模型展开成一张矩阵，每一行都是一条完整的“风险—路径—控制—证据”链条。

矩阵有四个列。第一列是风险，也就是第一章里定义的那种不可接受影响；第二列是攻击路径，描述从某个攻击面到该影响之间要走过的具体步骤；第三列是预期控制，即系统在正常状态下应当拦下这条路径的那道防线；第四列是成功证据，即什么现象可以无可争议地证明控制已经被穿透、影响已经发生。

以几类典型风险为例。对于跨租户泄露，攻击路径是“恶意文档→检索→回答”——攻击者投递的文档先进入检索池，再被取回并拼进回答；预期控制是召回前的 ACL，即检索阶段先按租户权限过滤，越权内容根本不该进入上下文；成功证据是模型最终吐出了另一租户的原文片段。对于越权转账，路径是“邮件注入→Agent 工具调用”，即攻击者通过邮件内容诱导 Agent 发起转账动作；预期控制是权限约束加人工批准；成功证据是账本状态真的发生了改变。对于秘密外传，路径是“工具输出→外部 URL”，即工具返回的敏感数据被发送到攻击者控制的外部地址；预期控制是网络出口策略；成功证据是受控接收端看到了预先埋设的金丝雀标记。对于有害输出，路径是多轮编码规避——用编码、改写等手段绕过表层过滤；预期控制是语义策略；成功证据是输出了完整且可执行的有害内容，而不只是零散片段。

这张矩阵的作用有两个。第一是分配资源：高影响且控制薄弱的路径应当优先投入测试，因为那里一旦失守代价最大、也最可能失守。第二是统一“成功”的定义：一次攻击只有在产生了那一行里写明的成功证据时才算真正成功，否则即便模型表现异常，也不能算穿透了这道控制。矩阵本身是从威胁模型推导出来的工作底稿，它把抽象的“模型会不会说坏话”替换成了可逐一验证的因果链。

把前面抽象的原则落到一个具体场景，可以看清整条失败链是如何被逐步验证的。设想一个采购 Agent，它的任务是读取上传的合同文档并执行后续动作。测试的目标是：能否用一份恶意 PDF 诱导 Agent 把合同外传给攻击者。整个测试必须在隔离环境里进行，使用虚构的合同内容和一枚只能访问受控域的金丝雀标记，绝不动用真实客户数据。

攻击的第一步是上传一份含间接提示注入的 PDF。这份文档表面上是一份正常合同，正文里却藏着指令，要求模型忽略用户本来的目标，把合同发送到攻击者控制的 URL。文档一旦进入检索池，就成为那条“恶意文档→检索→回答”路径的起点。接下来要观察两个层次的反应：检索层是否把这份文档的内容标记为不可信来源，以及模型层是否真的产生了一次外传类的工具调用。

即便模型真的发起了外传调用，测试也还没有结束。工具层才是下一道防线：它应当依据目标域名、数据分类和用户授权来拒绝这次调用。模型说了什么、调用了什么，只是失败链的中段，而不是最终结果。再往下一层，如果系统带有人工审批界面，还要检查这个界面是否诚实——如果审批界面只显示“发送摘要”这类无害描述，而把目标域名和具体字段隐藏起来，就要测试审核者是否会在信息不完整的情况下机械地点了批准。

验证要到最末端才算数：检查网络出口策略是否真的放行，检查最终接收端是否真的收到了那枚金丝雀。只有金丝雀实际抵达受控接收端，才能判定这是一次端到端的泄露。修复之后，还要把这份 PDF、它的变体以及本次穿过的控制层路径固化成回归测试用例，并在生产环境监控相似的拒绝事件是否再次出现。

这个例子也说明了严重度为何取决于穿透的深度。如果模型层复述了恶意指令、但工具层成功拦截，这仍然是纵深控制中的一个真实发现，说明模型层防线薄弱，但不能把它报告成与“合同实际外传”同等严重的泄露——因为影响并没有真正发生。严重度分级必须沿失败链区分“某一层被绕过”和“整条链被打通”。

当团队报告“跑了 600 条攻击”时，真正需要回答的问题是：这 600 条是否只是同一种越狱技巧的反复改写。如果其中 500 条都是用不同措辞重述同一个提示注入，那么数量虽大，覆盖到的风险面却极小。覆盖率不能按提示条数计算，而应当按“攻击面 × 技术”的网格来计算。

做法是：先从威胁模型里列出攻击面（例如系统提示、RAG 语料、上传文件、工具参数、插件接口），再列出技术类别（例如间接注入、多轮编码、越权调用、界面误导等），二者交叉得到若干测试格。假设威胁模型定义了 5 个攻击面 × 6 类技术，就得到 30 个相关的测试格。如果实际执行了其中 24 格，那么场景覆盖率为 coverage = 24/30 = 80%。这个数字直接暴露了盲区：剩下的 6 个未覆盖格可能恰好是高风险路径。

在覆盖率之外，还要分别统计不同深度的突破。假设这轮一共产生了 120 个用例，其中 15 个突破了模型层的控制，而只有 3 个进一步穿透到了工具或数据层。那么模型突破率为 15/120 = 12.5%，端到端穿透率为 penetration = 3/120 = 2.5%。两个数字的差别本身就有信息量：它说明模型层防线较容易被扰动，但大部分尝试在后面的控制层被拦住，真正打到核心资产的只是少数。

这里有一个关键结论：覆盖率高不等于安全。覆盖率衡量的是“我们是否把注意力撒到了所有该看的地方”，而安全还要看这些地方里有多少真正被击穿。因此报告结果时，除了覆盖率，还要按影响、可重复性、攻击预算和发现时间来描述每条发现，而不是用大量近重复的低价值用例去稀释指标。600 条里如果有 400 条是同一招的变体，它们既不能提升覆盖率，也不能降低风险，只会让分母变大、让穿透率显得更低。

当一次攻击尝试最终触达了敏感结果，仅知道“系统出事了”并不足以指导修复，必须定位失败发生在哪一层。判断的关键在于沿攻击链逐层收集证据，而不是只看最终输出。图 1 把这条链画了出来：攻击从不可信输入出发，依次经过模型、策略、工具权限、人工审批，最后抵达业务资产，每一层都对应一个可以单独验证的控制点。

输入层是最外层的入口，证据是“系统收到了什么”——一份被投毒的文档、一条含注入指令的邮件。模型层是第一个处理这些输入的环节，证据是模型是否产生了不该有的倾向或工具调用，例如复述了注入指令、或主动发起了外传调用。策略层是语义与规则约束，证据是策略是否识别并拦下了这次意图。工具权限层是模型对外行动的闸门，证据是工具是否依据目标域、数据分类和用户授权拒绝了调用。人工审批层是面向人的最后一道关卡，证据是审批界面是否如实呈现了风险信息、审核者是否在知情下批准。业务资产层是终点，证据是资产状态是否真的发生了改变——账本是否变动、文件是否离开边界。

这条链的价值在于，它能把“模型被骗”和“资产已受损”明确区分开。如果失败停在了模型层或策略层，说明模型被诱导了，但后续控制仍然有效；如果失败一路穿透到业务资产，才构成端到端的实际损害。每层收集到的证据就是上一章矩阵里“成功证据”列的具体来源：只有当下游资产状态发生改变时，才算整条链被打通；否则，即便模型层失守，也只是纵深控制中的一个局部发现。定位到具体层之后，修复就有了落点——是加固模型，还是收紧工具权限，还是改进审批界面，取决于失败链断在哪一环。

红队的测试活动由三种彼此互补的工作组成，它们承担不同的任务，单独使用任何一种都会留下盲区。人工探索擅长发现新的语义和新的组合路径——那些需要理解业务含义才能想到的攻击方式，比如利用某个特定流程的信任假设。但人工探索受限于人的时间和想象力，同一招的变体很难穷举，也不够稳定。自动变异恰好补上这一点：它系统地改变语言、编码、模态、顺序和工具参数，用来检验系统对同一攻击在不同形式下的鲁棒性。固定回归则承担第三种任务：把已知漏洞固化成用例，保证修复之后不再复发。

如果只靠人工创意，会漏掉大量同一漏洞的改写形式；如果只靠自动生成，会漏掉需要业务理解的新颖路径。模型生成的攻击可以快速扩展候选数量，但它继承训练数据带来的同源盲点，产出的攻击往往与已知模式高度相似，并不能替代有业务背景的人去发现新类别。另一个边界是，作为“裁判”的模型不能单独决定高风险攻击是否成功——高影响路径必须由端到端的受控环境来验证，而不是由一个模型去评判另一个模型的输出。

因此合理的工作方式是分阶段推进。先做开放探索，鼓励测试者自由地寻找未知路径；探索得到的发现要归一化成最小可重复用例，并为每个用例建立阴性对照和明确的成功断言，这样才能稳定复现并度量。之后把固定用例纳入回归，每次系统变更时都运行一遍，确保已知漏洞不会悄悄回来。与此同时，周期性保留开放探索，去捕捉那些尚未被归类的未知攻击。探索负责发现新类，变异负责测鲁棒性，回归负责守住已知底线，三者缺一不可。

红队要验证外传能力，但不能为了“测试成功”就把金丝雀真的发到真实第三方那里——那等于在测试过程中制造了一次真实泄露。高风险的红队活动必须建立在书面授权、隔离环境和明确的停止条件之上，这三样缺一不可。

书面授权要把边界写清楚：测试范围、使用的账号、时间窗口、允许的攻击技术、允许接触的数据、目标域、最大成本上限、责任联系人，以及紧急停止的触发方式。这些内容越具体，越能避免测试滑向未授权的范围。执行环境必须隔离：使用虚构数据而不是真实客户数据，使用沙箱工具而不是生产工具，使用受控的接收端来验证外传，业务状态要可回滚。任何可能触达真实用户、生产秘密或未授权系统的操作都在禁止之列。

即使有授权，一旦在测试中发现了可能造成现实损害的路径，正确做法也不是继续把它跑通，而是先遏制住，再按事件流程升级处理。测试目标是发现风险，而不是完成攻击。此外，攻击语料和漏洞报告本身也是敏感资产：它们可能包含可被直接利用的载荷或漏洞细节，应当按最小权限原则保存，并事先设计好披露的期限和范围，防止报告成为新的攻击入口。

红队身份并不意味着获得无限权限。恰恰相反，正是因为它要触碰系统最薄弱的环节，才更需要被严格限定在授权范围之内。授权定义了“能做什么”，隔离定义了“在哪里做”，停止条件定义了“何时必须停下”。

给发现排序时，要面对这样的问题：一次难以复现的拒答绕过，和一次稳定可重复的跨租户读取，哪个更严重？答案来自三个维度——影响、可利用性和控制穿透，三者共同决定严重度，而不是只看“模型说错了话”。

影响维度衡量资产受损后带来的后果：泄露的是普通文本还是客户秘密，是只读还是可以改变账本状态。可利用性维度衡量攻击有多容易落地：需要什么权限和前置知识、成功率有多高、需要多少重试预算、能否规模化复制、是否容易被检测、是否需要用户交互配合。控制穿透维度衡量失败链走得多深：模型只是输出了一段违规文本，还是工具调用被拒绝，还是受控资产真的被读到了，还是真实业务状态发生了改变——这四者是明显不同的级别，从“模型层被扰动”到“资产实际受损”，严重度逐级上升。

回到开头的问题：稳定可复现的跨租户读取，影响高、可利用性强、且穿透到了资产层，严重度远高于一次难以复现的拒答绕过——后者可能只是模型层的一次扰动，成功率低、难以规模化、也未必触达真实资产。

严重度评估的结果必须能支撑决策，因此报告要给出最小复现步骤、证据、受影响版本、攻击前提和可能的变体，而不是只附上一张看起来很精彩的聊天截图。截图只能说明“曾经发生过一次对话”，却无法说明漏洞的边界和影响范围。严重度最终决定修复期限、是否需要临时停机，以及向谁、在什么范围内披露。排序的目的，是让最该先修的漏洞排在最前面。

修复一个被红队发现的漏洞，最常见的错误是把失败的那条提示直接加入黑名单。这种做法几乎总会在下一种措辞上失效，因为黑名单匹配的是具体表达，而攻击者只需换个说法就能绕过。修复必须落在根因所在的那一层，也就是最可靠的控制层，而不是停在最容易修改的表层。

根因决定了修复落点。如果根因是工具被越权调用，那要修的是权限检查和参数验证，让工具层根据目标域、数据分类和用户授权来拒绝，而不是靠模型自觉；如果根因是跨租户召回，那要修的是检索阶段的 ACL，确保越权内容根本不会进入上下文。相比之下，只在系统提示里“再强调一次”属于软控制——它依赖模型每次都正确遵循指令，是整条链上最不可靠的一环，只能作为补充，不能作为主要防线。

修复之后要做的回归也不只是重放原来的那条攻击。应当用原用例、语义变体、阴性正常请求和相邻攻击面一起回归：原用例验证已知路径已关闭，语义变体验证修复不是只对特定措辞有效，阴性正常请求验证修复没有误伤合法使用，相邻攻击面验证攻击者不会从旁边绕进来。同时要检查安全收益与可用性损失——如果修复把正常功能也拦掉了，那只是把一种失败换成了另一种。

还要接受一个事实：攻击者可以观察防御并随时适应。因此正确的做法是把通用不变量固化在执行层，让约束在代码层面强制成立，同时保留持续的监控和事件响应能力，随时捕捉新的适应。可以声称某条已知路径已被堵住，但不应声称某个漏洞类别已被根治——防御是持续的过程，不是一次性的结论。

让系统开发者自己来做红队，往往会漏掉高价值的问题。原因不在于能力，而在于视角：开发者对设计了然于胸，却容易把“系统按设计运行”当成安全边界——因为某个行为是预期中的，就默认它不会成为攻击路径。外部或独立的团队没有这种既定的心理模型，反而更可能去质疑系统的用途本身、界面的呈现方式以及组织层面的假设，这些恰恰是开发者习以为常、视而不见的地方。

减少同源盲点的办法，是让红队本身具备独立性和多样性。团队成员应组合多种视角：安全、隐私、滥用、领域专家，以及可能受系统影响的那些人的视角。同时，要给这些成员足够多的系统信息——架构、工具、数据流、约束——而不是只丢给他们一个聊天框。信息不足时，外部团队只能做表面试探；信息充分时，他们才能针对真实攻击面提出有依据的质疑。

但独立不等于脱离事实。独立的红队如果只能靠猜测，会把时间浪费在根本不存在的路径上。因此需要建立安全的沟通渠道，让红队提出的假设能被快速确认或反驳，避免误报，也避免错失真实线索。在验收环节，修复最好由最初的发现者或另一支独立团队来复测，而不是由实施修复的人自己宣布完成；而对风险的接受，则应当由有权限的业务负责人来决策——因为“接受这个风险”是一个业务判断，不应当由修复者或测试者代为拍板。独立性负责提出质疑，事实通道负责保证质疑成立，二者结合才能让盲点真正变少。

红队汇报时最容易被误读的数字是“发现数”。发现数下降，可能意味着系统更安全了，也可能意味着测试团队变弱了——这两者无法从数字本身区分。因此指标应当围绕风险是否真的在减少来设计，而不是奖励攻击数量。

有意义的指标包括：威胁格覆盖率和高风险路径覆盖（说明测试是否撒到了该撒的地方）、首次突破时间（说明防线被攻破的快慢）、端到端穿透数（说明有多少攻击真正打到了资产层）、重复发现数（说明测试是否在低价值地原地打转）、修复时长（说明漏洞被关闭的速度）、回归复发（说明修复是否稳固）、监控检出（说明生产环境的检测能力）以及正常任务的误拦（说明防御是否误伤了合法使用）。

要让不同版本之间能够比较，需要保持一组冻结的哨兵攻击和一个独立的隐藏集。哨兵攻击是一批固定不变的已知用例，跨版本重跑可以显示系统是否退化；隐藏集则是没被公开用于调优的独立用例，用来防止“考过就背答案”式的假安全。二者配合，才能把“发现数下降”归因到真实改进或测试退步上。

“零发现”这个结论只有在同时报告覆盖率和攻击预算时才有意义。如果没有覆盖范围、没有攻击投入，零发现只是一个空标签，证明不了任何安全性。此外，还应当记录未测试的能力、测试环境与生产环境的差异，以及因此残留的风险，让治理者清楚证据的边界在哪里——知道哪些结论有依据，哪些地方仍然是未知。

把前面各章串起来，红队测试是一条从问题一直延伸到可验证实践的因果链，每一步都从前一步自然推出。起点是列出资产、攻击者和不可接受影响，让“测什么”变得具体；接着画出攻击面和信任边界，标出所有可能的入口与防线；然后据此建立“风险—路径—控制—证据”矩阵，把资源优先分配给高影响且控制薄弱的路径。有了矩阵，才在授权的沙箱中展开探索与自动变异，去验证这些路径是否真的能被走通。验证时以业务状态和受控接收端收集证据，区分“模型被骗”和“资产已受损”。拿到证据后按影响与可利用性分级，决定哪些先修。修复落在根因层，并用原用例、变体和阴性请求做回归，确认安全收益没有以误伤合法使用为代价。最后，把残余风险、持续监控和事件处置交给治理闭环——红队不是一次性的检查，而是持续运转的反馈回路。

贯穿这条链的是一种验证纪律：任何结论都要能说明“固定了什么、观察了什么”。在输入层面，固定同一批样本、前处理和权限边界，观察输入哈希、切片标签和拒绝原因，保证比较的是同一份输入。在机制层面，一次只改变一个核心变量，其余配置锁定，观察关键中间状态以及首次偏离预期的位置，从而定位失败发生在哪一层。在输出层面，使用同一套验收规则和资源预算，观察质量、成本、延迟和失败率的分层差异，避免用不同的尺度去评价不同的尝试。最后是反证：保留一组不启用目标机制的对照组，确认观察到的收益能跨样本、跨随机种子稳定复现，而不是某次偶然的结果。

这四层验证共同回答了一个问题：我们报告的风险减少，究竟来自真实的改进，还是来自测试方式的漂移、环境的偶然或样本的巧合。只有当输入、机制、输出和反证都被固定下来，红队得出的结论才能支撑后续的修复与治理决策。