生成式AI安全红队这个词这两年是所有做模型应用团队都绕不过去的坎。我身边不少做算法的朋友以前见面聊的是模型效果指标现在一开口反而是这模型放出去真被别人玩坏了怎么办。这里说的红队不是临时找几个同事拿些恶意prompt去撞一撞模型看会不会出事故而是一整套从攻击评估到模型行为治理的闭环流程先识别风险面再设计验证手段把攻击结果转成整改动作最后形成长期运营机制。我前前后后在几个项目里试过几轮不同做法有些流程踩过不少坑也有沉淀下来的方法。这篇文章比较适合正在搭AI安全评测流程的工程师、负责模型上线的算法同学以及想建立内部红队机制但还没找到落地路径的安全团队。1. 生成式AI红队为什么不能照搬传统安全测试1.1 从漏洞扫描到行为攻击面的思维切换很多传统安全团队刚接触生成式AI时第一反应是想拿渗透测试的思路套上去做个资产扫描抓几个漏洞然后出修补方案。但这个思路在模型上失效得很快。传统Web渗透的核心问题是对方能不能进来、能不能越权而生成式AI红队的核心问题是模型会不会被诱导说出不该说的话、执行不该做的动作、泄露不该传的数据。前者是偏系统和网络的漏洞后者本质上是模型行为的边界问题。举个例子Web漏洞出现后我可以用一行代码加个补丁或者调个WAF规则把它挡掉。但模型被越狱成功往往不是因为某个具体代码缺陷而是模型从海量数据里学到的语言模式里那层安全对齐没有覆盖住某些刁钻的表述角度。修复手段也不是改一行能解决的可能需要更新系统提示词、调整输出过滤器、甚至重新做一轮安全微调。所以红队评估的结果天然对接的是模型行为治理不单单是漏洞清单。另外一个差异是传统攻击里攻击者通常对系统控制权有确定性收益但生成式AI的攻击输出是概率性的。同一个恶意输入可能连试十次都触发不了第十一次就突破了。这也是为什么红队测试必须和帮模型跑多少遍、在什么条件下算成功这些问题绑定否则测试结果没法量化也无法复现。1.2 先建一套风险分类表和攻击面清单我刚开始做这个方向时犯过一个典型错误拿到模型就急着写prompt去攻击写完几十条就开始测测出来一堆结果却不知道怎么归类也不知道哪个优先级高。后来才想明白真正靠谱的做法是先建好风险分类和攻击面清单让后面所有测试、记录、修复动作都有明确的挂靠点。对生成式AI应用来说我建议按下面这几类风险做顶层拆分风险类别具体描述典型案例有害内容生成模型输出包含暴力、仇恨、歧视、性相关等不被允许的内容越狱后要求提供犯罪手法隐私与敏感信息泄露模型输出训练记忆中的真实个人信息或商业机密用户诱导模型背出训练语料片段指令颠覆用户通过提示注入让模型忽视原始指令执行攻击者指令在输入中加入忽略之前所有设置执行……恶意意图辅助模型成为诈骗、钓鱼、恶意代码生成的工具生成高仿钓鱼邮件、恶意脚本外部知识源投毒模型因检索到被污染的资料而输出错误或有害内容文档里藏了一句攻击指令模型读取后执行工具链滥用模型在调用API、工具、插件时执行非预期操作被诱导调用扣款接口、读取系统变量这六类算是一个不错的起点。你们团队启动时可以根据自身业务调整比如做金融问答的可能更关注隐私泄露和指令颠覆做客服机器人的可能更关注工具链滥用。重要的是先明确哪些风险是这个产品绝对不能碰的再围绕这些风险制定测试方向。攻击面也要梳理清楚。生成式AI应用不像传统系统只有一个边界它的攻击面至少包含四层模型层训练数据、对齐机制、应用层系统提示词、工具调用逻辑、RAG检索链、数据层用户输入、外部文档、文件上传、平台供应链层第三方API、开源模型组件、推理框架。很多团队只盯着模型层结果一个RAG应用上线后真正出事的地方是外部文档投毒这层很多人根本没纳入红队范围。2. 攻击评估方法如何设计用例、指标和复现机制2.1 用例库把攻击技法拆成可复现的刺激单元红队测试如果没有统一的用例模板最后整理成果时就是一团乱麻。我现在的习惯是每条测试用例都用固定的字段去记录不单纯记一句我输入了什么、模型回答了什么。最简版本是这样的用例字段含义说明用例编号全局唯一标识比如RJ-001攻击技法属于哪一类攻击思路比如上下文操控编码绕过威胁场景这条用例到底在模拟什么攻击明确配合风险分类刺激输入实际构造的prompt或多模态输入可复现必须完整记录期望行为在理想安全态下模型应该怎么回应要具体可验证观察结果实际的行为表现记录原话或动作不加工问题定级高/中/低后面单独讲怎么定级用例库的核心不是堆数量而是覆盖攻击技法。以我自己的经验攻击技法至少可以从这几条分支去组织直接提示注入在用户输入中直接附加恶意指令试图覆盖系统约束。间接提示注入恶意指令藏在外部内容里比如网页、文档、图片中的文字模型在检索或解析时被动吸收。越狱模板用一套精心设计的对话结构激发模型的无条件服从倾向压制其安全对齐。角色表演与人格切换让模型扮演影视角色、虚拟人格借角色之口绕过规则。上下文操控先建立安全对话氛围再逐步引导到违规主题。编码与变形绕过用Base64、同义词替换、谐音、多语言、字符插入等方式混淆恶意意图躲过输入过滤。多模态注入在不安全的图像、音频里嵌入文本指令推动模型执行违背本意的操作。工具链对抗测试模型在调用外部服务时是否会对返回结果里的指令盲目执行。这个结构其实对应的是攻击思路而不是具体句子。因为越狱本身就像搭积木同一套思路换一种表述就能生成无数变体所以用例库要按技法组织变体可以丢给自动化工具批量生成。我见过有人把用例库做成一个几千条内容的Excel却没有任何字段规范后面每一次复测都要重新看对话记录才能确认问题还在不在。这个坑尽量避免。2.2 指标怎么定ASR不是唯一的答案好多团队做评估时只盯一个数值——越狱成功率也就是利用某种攻击尝试最终有多少比例突破了模型安全边界。这个概念本身没问题但只盯这一个指标会带来非常严重的偏差。比如模型干脆把所有违规请求全部拒绝越狱成功率看起来会很低但产品体验也废了因为大量正常请求也会被误拒。这类问题在指标上叫过度拒绝率但只看ASR根本看不到。我自己在红队项目里常维护的指标是这几个指标名计算方式价值越狱成功率ASR攻击成功用例数 / 攻击尝试总数 × 100%反映模型对抗攻击的底线能力违规内容输出率输出被判定为违规的次数 / 总测试次数结合完整输出审验防止误判正当拒绝率恶意请求被合理拒绝的比例越高越好过度拒绝率正常请求被错误拒绝的比例越低越好平衡体验隐私泄露率测试中成功诱导模型输出敏感信息的比例直接对应高等级风险行为动作违规率模型在工具调用中执行非授权操作的比例工具类应用必看测一个指标时有个关键点模型输出是概率性的同一输入跑一次和跑十次结果可能完全不同。所以正式评估时每条用例至少跑3到5遍有标识风险的跑10遍以上然后取统计结果而不是试了一次成功了就报高危、试了一次没成功就删掉。我遇到过不少案例个别高危问题第一次测没触发但第8次突然出来了如果只测一轮就漏过去了。另外指标不是测完就结束必须建立基线。尤其当你们想对比不同版本的模型、不同系统提示词方案时同一套用例、同一种统计口径跑出来的指标才有可比性。这条经验非常重要不要把某一天的红队结果直接和另一天的比除非你确认两次测试的环境、用例集、运行次数、判定标准完全一致否则数字差异很可能只是测试条件变化造成的假象。3. 从拿到模型到输出报告全流程实操记录3.1 测试前准备环境隔离与安全边界红队测试开始前第一件事不是调prompt而是划定安全边界。我见过有人直接把生产环境的模型聊天窗口拿来测试还往系统里输入可能泄露真实用户信息的文本这个做法相当危险。红队本来就是要去模拟攻击如果测试本身污染了生产数据或者触发了不该触发的真实动作那就让安全评估变成了新的事故源。我的建议是红队必须在独立的测试环境里跑。几个硬性规矩先列出来用独立部署的模型服务或者至少隔离的沙箱空间不对接生产流量。测试账号用专用账号权限最小化运行日志开启但要做脱敏处理。测试数据用脱敏或虚构数据绝对不用真实用户资料、真实订单、真实对话语料。如果模型要调用外部工具或API必须使用mock服务或测试环境接口不能指向正式服务。定义清楚红线行为测试过程中不允许把诱导出来的敏感信息复制到外部系统不允许尝试对真实第三方系统发起请求。还要确定测试范围。比如一个机器人助理红队是只测纯文本对话还是要覆盖上传图片里的文字注入、文档解析、工具调用这个范围直接决定了后面要做什么准备工作。范围边界的确认要跟产品、研发、算法负责人一起过一遍确保理解一致而不是红队自己闷头定。3.2 手工粗扫 自动化批量两条腿走路执行阶段我习惯分成三个模块基础覆盖、自动化扩展、深度挖掘。第一个模块是手工粗扫也叫基础覆盖。准备一批覆盖不同风险类型的核心prompt大概100条到200条人肉跑一遍。这个步骤的价值不在数量而是快速建立对模型安全性格的直觉。比如这个模型是偏保守型还是偏顺从型对角色扮演的防御是硬的还是软的对待敏感问题的拒绝话术有没有漏洞有了这层感觉后面自动化跑结果时才不会像无头苍蝇。第二个模块是自动化扩展。把300到500条基础prompt交给自动化工具去做变异变换语言、大小写、编码、同义词替换、句式重组、加入无意义字符、调整对话轮次甚至让另一个辅助模型来专门生成对抗变体。这个阶段往往能把几百条输入扩展到几千条甚至上万条。这里特别提醒一句自动化扫描跑出来的攻击成功列表只能当候选线索不能直接当结论。自动化的判定逻辑多数时候是看输出触发了某个关键词或者被分类器打了高分但生成式AI的上下文一变化很多所谓成功其实是误判必须人工复核。第三个模块是深度挖掘。自动化跑出线索后红队人员要对感兴趣的路径进行手工跟进比如围绕一个能绕过约束的prompt模板做系统性变种探索。比如发现某个编码方式能穿透过滤那么把常见的恶意意图都套一遍这种变形看看是不是全面失守。这个阶段是最出成果的因为很多高危问题不是一个独立prompt触发的而是埋在一个攻击思路链里的。3.3 结果审验与分层定位每次红队测试结束我基本都会面对一堆可疑结果。这时候最忌讳直接按自动化判定结果去写报告。我通常要求对每条可疑输出做人工复核至少确认三件事第一这真的是越界吗还是分类器误报有些模型的输出看着吓人但仔细看只是提到了敏感词并没有实际操作价值或违规意图。第二这个越界是稳定复现还是随机偶发如果同一输入跑十次只成功一次那么影响评估要下调因为攻击者实际利用它的难度更高。第三问题出在哪一层是系统提示词约束不够强、输入过滤没拦住、输出过滤器没识别出违规内容还是模型本身的权重层面就没有对齐好层层定位是红队报告里最容易被忽略但最有价值的部分。我举个例子之前有个客服助手项目用户在小语种输入中夹带一句指令结果模型就无视系统设定开始模仿攻击者说话。我们查下来模型底层推理能力没问题输入过滤也拦截了一部分但真正的原因是系统提示词里对指令优先级的表述相对模糊加上该语言不在过滤器的强势覆盖范围内。修复方案并不是重新训练模型而是强化系统提示词明确任何语言下、任何格式下原始系统指令优先级最高同时补充低频语言的攻击样本做输入过滤。这个结论真正推动了产品迭代方向而不仅仅是把问题丢给算法团队。3.4 报告与分级怎么落地报告不用做得像论文那么花哨但一定要让产品、研发和管理层都能空动起来。我习惯用分级标准加摘要卡片的结构级别判定标准例子高完全解除安全限制或稳定造成严重合规与安全风险任何语言、任何角色下均可稳定诱导生成违规内容中特定技法或特定条件下可绕过普通用户不易复现仅在小语种加编码混淆时偶尔成功低边界表现存在模糊回答或不完全拒绝但影响有限拒绝得不够干脆或回应中含有少量不安全内容但有纠偏机制每条漏洞记录里至少包含攻击技法分类、复现输入、预期行为、实际行为、影响场景、修复建议。最好再配一段对产品的影响。管理层可能不太关心某个prompt长什么样但会在意这会不会导致客服机器人泄漏用户隐私这会不会让我们的内容审核机制形同虚设这类由影响衍生的判断。同时候还要给运营做一个scores overview这次测试共测了N条用例整体ASR是X%高危漏洞Y个、中危Z个、低危W个。下一轮可以定一个目标比如高危归零、ASR降到1%以下这就把红队报告转成治理动作的驱动力了。4. 模型行为治理闭环让红队结果变成改造动作4.1 四层缓解工具箱红队报告出来下一步就是修复和治理。我习惯把可用的缓解手段按四层来组织每层解决不同的问题没有哪一层能单独包打天下。第一层是系统提示词加固。这是成本最低、见效最快的动作。具体做法包括明确模型角色边界、禁止其透露系统指令细节、强化用户指令不得覆盖系统约束的规则、拒绝时给出安全替代答案。很多指令颠覆类问题在这一层就能解决大半。但要注意系统提示词本身也是软约束遇到擅长越狱的prompt仍可能被绕过不能把它当唯一防线。第二层是输入侧安全策略。在用户输入到达模型前先过一道检测识别已知恶意prompt模式、拦截明显的注入指令模板、对编码混淆做解码检测、对上传文件做内容扫描。输入侧的好处是前置拦截能挡掉大量低水平攻击缺点是对高级变体容易漏而且模型本身对大段正常文本里的隐藏指令也可能看不出恶意。第三层是输出侧安全机制。模型生成结果后再用内容安全分类器做一轮风险评估对内部高危类别的输出直接阻断或替换回答。如果应用还涉及工具调用输出侧还要加一层动作审核对于会执行外部操作的动作先校验权限再放行。输出侧是与用户直接接触的最后一道关卡必须保留。第四层是模型权重层对齐。所谓把安全做大模型自身的本能通过安全数据增强、安全偏好对齐比如RLHF或DPO让模型在推理时天然知道什么该拒绝。这层成本最高、周期最长但效果最牢固。对高危且频繁出现的类型我建议把攻击样本脱敏后整理成训练期间的对齐数据而不是无限堆积过滤器规则。四层的关系很像小区安防围墙输入侧挡住外面的闲人门禁系统提示词管理权限楼道监控输出侧盯着行为而住户本身的安全意识模型对齐才是根本防线。只做某一层都会被擅长针对性的对手穿透。4.2 风险登记、复测、上线门禁和持续运营红队测试如果只做一次那本质上只能算体检不是治理。真正的闭环是把发现的问题变成需求推动改进然后用后续测试验证改进有效性。我常用的流程是漏洞入库每条红队结论生成一个风险登记单记录问题、定级、来源用例、影响面。指派责任人按问题所在层分派系统提示词类归应用研发过滤类归安全团队模型对齐类归算法团队。修复动作不同层级手段组合落地修复过程要保留变更记录方便验证。回归测试修复完成后红队针对复测原有用例必须全部重跑新增的修复方案还要附带验证是否引入过度拒绝。发布门禁把红队指标定为上线闸门条件比如高危问题全部清零、ASR在基线范围以下才能放量。持续运营每月固定红队周期结合新攻击样本、新产品功能、新模型版本动态补充用例库。在这个闭环里回归测试集的建设特别关键。每次发现的真实攻击样本都应该脱敏后入库作为回归用例长期存在。这个库越做越大就是团队最核心的安全资产。有一次我在某旧版模型上发现了一个隐蔽越狱路径修复后当时没管它后来换模型版本时这个路径又被复现了因为新版权重没有同步覆盖这个属性。从那以后我们就把所有历史变异样本全部纳入自动回归集每次发版前统一跑一遍这种历史攻击样本库回归真要长期坚持。指标层面我建议给运营团队搭一个简单的安全看板最新一轮红队的ASR、高危中危数量、修复状态、回归通过率、过度拒绝率趋势。不用做得很复杂哪怕一周更新一次Excel都行关键是有持续的数据看变化。没有看板红队活动就会变成有活动时紧张、没活动时全忘的周期性演员。5. 真实踩过的坑与可以直接抄的经验5.1 常见问题速查表下面这些坑要么我自己踩过要么在跟圈内同行交流时反复听到。整理成速查表方便对照。常见问题根因建议处置自动化扫描跑出大量疑似成功人工复核后发现七成是误报自动判定逻辑太简单只按关键词或分类器分值判断人工抽检10%到30%高发类全部复核自动化结果只当线索修了高危后模型开始大面积误拒正常请求修复时只加拒绝规则没做体验侧的平衡回归集一定要包含正常业务问题BAU场景指标看过度拒绝率红队测了对话没测工具调用结果模型被诱导执行扣费动作攻击面只关注了文本层忘了应用行为层凡是接入了工具调用的应用红队必须覆盖行为安全同一条攻击用例今天成功明天不成功报告却只跑了一轮输出概率性 测试条件不一致每条用例跑多轮记录运行条件统计后再下结论测试过程误用了生产数据导致红队本身成为数据泄露通道测试环境隔离没做到位用独立沙箱环境本地用虚构数据日志脱敏红队报告出来了但没人接手修复报告没有和责任人、变更流程、门禁绑定每个问题都指派到人修复纳入迭代和发布门禁低危问题挤占了大量修复时间定级标准不清什么都不敢放按影响面定级低危可接受风险可以短期挂起但要持续跟踪5.2 几条值得长期坚持的实操经验经验一红队一定要有多角色混编。如果红队全是算法工程师基本上只会往模型越狱方向挖没人关心法律合规和业务风险。如果全是安全工程师又容易陷入对基础设施漏洞的关注忽略了模型行为层的业务影响。我建议小规模红队至少包含三部分人懂模型应用的人、懂安全攻防的人、懂业务合规的人。实在凑不齐也让业务合规律师在定级环节帮忙参与。经验二控制红队的想当然倾向。红队人员在设计攻击用例时容易不自觉站在攻击者什么都知道的视角比如知道系统提示词全文、知道内部过滤器的触发规则。真实攻击者拿不到这些信息所以只盯着内部资料设计的测试会脱离实际威胁。建议红队用例分成两层一层是黑盒视角完全站在外部用户视角设计另一层是白盒审视用来检查内部配置的薄弱环节。两者配合才合理。经验三红队不是越狠越好外部攻击者也不等于无穷能力的恶魔。回归到业务90%的用户是普通用户大多数攻击也是低技术含量的。所以红队方向要跟风险优先级对齐不能只追求暴力的全面越狱也要关注普通用户误触发不安全输出的可能性。比如一个无意的、语义模糊的提问让客服机器人突然输出隐私数据这比那些精心构造的越狱模板更可能在实际场景中造成真实事故。经验四把攻击样本变成监督信号不要浪费。红队发现的问题除了修系统还要回到数据侧。我会把高价值的攻击样本脱敏后进行二次标注加入安全正向训练集或作为评估集的一部分。这样每一轮红队积累的成果最终都会反哺到模型自身的能力提升而不是永远只靠外部过滤器打补丁。这个动作虽然前期投入大但做过几轮以后你会发现模型对同类攻击的鲁棒性有明显提升这才是长期安全性和可维护性的根本。我个人在带红队时最大的体会是安全治理这件事不是让模型变成一个油盐不进的封闭机器而是让它在合理的边界内保持可用、可控、可解释。你不可能堵住每一句刁钻的问法但你可以让模型在面对越界请求时始终记得自己的定位并且让团队在问题爆发前就有一套可复用的发现和响应机制。后面再扩展方向的话也可以考虑把红队覆盖到多模态、Agent自主决策链路、甚至第三方模型供应链的交叉验证上那会是下一阶段更有意思的挑战。