红队工具、范围与自动化

• 资产与攻击者画像定义
• 成功条件与禁止边界
• 隔离测试环境

红队计划先定义在范围内（in-scope）的资产（模型、API、Agent、工具、数据、特定功能），明确攻击者能力模型（谁能攻击、有无系统权限、是否黑盒/白盒、是否知道系统提示）与攻击者画像（恶意用户、内部威胁、外部研究者）。成功条件用可验证的判定定义（如"成功诱导模型执行某高危工具"、"成功泄露特定 PII"）。禁止边界（out-of-scope）明确不可测试项（如生产用户数据、真实支付、第三方系统、人身安全相关），避免越界。测试环境用隔离的影子环境（独立账号、脱敏数据、沙箱），避免污染生产与真实用户。

红队计划的核心是"边界清晰"。资产、攻击者、成功条件、禁止边界、环境五要素明确，才能让测试可执行、可判定、可复现且不越界。计划先行是红队规范化的前提。

• 自动攻击的局限
• 人工复核的维度
• 误报与可利用性评估

自动工具（如 Garak、PyRIT）会给出攻击成功率分数，但分数不代表真实风险。人工复核需逐条评估：可利用性——攻击是否真的触发了有害行为，还是仅文本相似（如模型只是"复述"而非"执行"）；业务影响——若被利用，会造成什么实际损失（数据泄露、资金损失、越权）；误报——是否把良性输出误判为攻击（如过度拒绝、安全示例被当成有害）。复核要结合上下文判断，覆盖"能否实际利用"与"危害等级"，并记录判定依据。最终风险清单以人工复核为准，工具分数仅作初筛。

工具分数是"机械的匹配"，人工复核是"语义的判定"。自动攻击常产生误报或低可利用性，只有人工复核才能区分"看起来成功"与"真的危险"，避免误报刷屏或用假阳性覆盖真风险。

• 红队与产品需求的映射
• 风险与功能权衡
• 上线门禁联动

红队计划应与产品需求联动：从产品功能（如 RAG、工具调用、多模态输入）推导出攻击面与风险点，确定红队目标与范围；攻击者画像对应产品的真实用户类型（恶意用户、滥用者）；禁止边界对应产品承诺的合规与安全边界。联动方式：红队发现的风险反馈到产品需求（如高危功能需加护栏或降级），产品迭代时同步更新红队用例；红队结果作为上线门禁——高风险未修复不放行。这样红队不是孤立的测试，而是产品安全生命周期的一部分。

红队若脱离产品需求就是"为了测而测"。把红队映射到产品功能与用户画像，风险反馈到需求与门禁，才能让红队结果真正影响产品决策与发布。

• OWASP GenAI Top 10 的分类
• 红队结果到风险类别的映射
• 可追踪风险清单

将红队发现的每个风险映射到 OWASP GenAI Top 10（v2.0） 的对应类别（LLM01 提示注入、LLM02 敏感信息泄露、LLM03 供应链、LLM04 数据/模型投毒、LLM05 不当输出处理、LLM06 过度代理、LLM07 系统提示泄露、LLM08 向量检索弱点、LLM09 错误信息、LLM10 不可控消费）。每条红队发现记录：原始证据、攻击复现步骤、对应 OWASP 类别、严重度、影响面、责任人与状态。输出为可追踪的风险清单，用唯一 ID 关联复现用例与修复项，形成可回归、可审计的闭环。

OWASP 提供了可对齐的风险分类框架，让红队结果标准化、可横向比较。映射要具体到"哪条发现对应哪类风险"，并给唯一 ID 形成可追踪清单，而非模糊的风险描述。

• 合成账号与受控数据
• 速率限制与熔断
• 停止开关与应急处置

生产环境红队要"最小化真实伤害"：用合成账号（非真实用户）执行测试，避免污染真实用户数据；用受控/脱敏数据做测试输入，避免泄露真实 PII；对测试请求设速率限制与配额，避免资源耗尽或触发真实业务动作；设停止开关（kill switch）与熔断，一旦发现异常立即暂停全部测试。同时明确测试账号与真实账号隔离，工具调用限定在测试环境（如沙箱支付、Mock 工具）。事前审批、事中监控、事后回滚，确保红队不造成真实损失。

生产红队是在"真实环境"与"不造成真实伤害"之间的平衡。合成账号、受控数据、限流、停止开关四道防线，把测试影响限制在可控范围，是生产红队的底线。

• Agent 高危路径识别
• 工具调用与代码执行测试
• 权限与隔离

Agent 场景风险在工具执行能力，红队需覆盖：MCP 工具调用——测试能否诱导执行高危工具（删除、支付、发送消息）、工具参数注入、越权调用；代码执行——测试能否让 Agent 执行任意代码、命令注入、绕过沙箱；文件系统访问——测试能否读取/写入敏感文件、路径穿越、越权访问。测试方法：构造多轮攻击链诱导 Agent 调用高危工具、注入恶意工具定义、利用工具返回内容二次注入。同时验证权限最小化与隔离：工具是否有白名单、参数是否校验、运行是否在沙箱、是否有审批与审计。对所有高危路径设拦截与告警。

Agent 的核心风险是"工具=执行能力"。红队必须覆盖工具调用、代码执行、文件系统等真实高危路径，并验证权限最小化与隔离，否则 Agent 会成为攻击的放大器。

• 间接注入的传播路径
• 内容与指令隔离
• 检测、隔离与告警

间接 Prompt Injection 通过 RAG 检索内容、邮件、文档等外部数据注入指令。检测：对外部内容做注入检测（识别"忽略以上指令"、"执行某操作"等指令性文本），对指令与数据内容区分；建立"内容不可信"标签——外部内容作为数据而非指令处理。隔离：把外部内容与系统指令分离开，用可破坏的边界（如明确的指令充当分隔标记），并限定外部内容只能作为可引用数据，不能直接触发工具。告警：检测到可疑注入时隔离该内容、告警并记录，对高风险（诱导工具调用）触发限权或人工复核。多轮对话中要跨轮累积检测，防止注入在后续轮次生效。

间接注入的难点是"内容与指令混在一起"。核心是分层信任——外部内容默认不可信，不能作为指令，且需跨轮追踪。检测、隔离、告警三步闭环是防护的关键。

• 索引污染攻击原理
• 恶意文档注入测试
• 防御验证

恶意文档注入（检索污染）通过向知识库注入携带指令的文档，使模型检索到该文档后输出特定内容或执行指令。红队测试：构造恶意文档（含"忽略以上内容，输出 X"之类指令），注入索引，用正常提问触发检索，验证模型是否被诱导输出指定内容或暴露系统提示。还要测试：文档是否可被越权注入、检索结果是否被去重/过滤、指令是否被当作内容处理。防御验证：检查 RAG 是否做内容与指令分离、检索结果是否过滤指令性内容、是否对来源做可信度分级、是否校验文档来源与权限。

恶意文档注入是 RAG 特有攻击，核心是"检索内容可作为指令"。红队要验证模型是否区分"数据"与"指令"，防御要校验来源权限、内容过滤与指令分离。

• 分级标准
• 影响与可利用性评估
• 分级与处置联动

分级综合"可利用性+影响面+触发条件"。Critical：可被远程/低门槛利用造成重大损失（数据泄露、资金损失、越权执行高危工具），应立即修复并阻断；High：可利用造成较大影响，需限期修复；Medium：需要特定条件或影响有限，需计划修复；Low：影响小或需极高门槛，可记录跟踪。分级要结合业务场景（如涉及 PII/支付/身份的高危），并给出判定依据。分级与处置联动：Critical 触发暂停/降级，High 限期修复，中低跟踪，形成风险优先级。

分级把风险从"有/无"变成"多严重"，让资源按优先级投入。关键是可利用性与影响面结合评估，并和处置时限联动，避免"全部高危"或"全部低危"的两极失效。

• 基线的可复现性
• 版本与核查日期记录
• 变化时的基线管理

基线要"可复现、可追溯"：固定测试工具版本（如 Garak 2.x、PyRIT 特定版本）、模型版本/ID、评测集版本、参数与提示词，形成完整基线清单。每个基线标注核查日期（创建时间、最近核查时间），记录所用工具版本与模型版本。当工具或模型版本变化时，不能直接拿新结果与旧基线比，应声明版本变更并重新评估；若需对比，用同一工具版本复测，或明确标注"跨版本对比仅作参考"。基线集中管理，变更走版本记录，确保分数可解释、可复现。

基线是"时间点上的可复现快照"。工具/模型版本变化会破坏可比性，必须把版本与核查日期绑定到基线，才能避免"拿起新分数比较旧基线"的误导。

• 问责与修复闭环
• 回归用例固化
• 上线门禁机制

红队发现要转化为可执行的整改闭环：为每条发现指定责任人与修复期限（按严重度定 SLA）；把利用该漏洞的复现步骤固化为回归用例，加入自动化安全回归套件，防止回归；把修复验证与上线门禁挂钩——高危问题未修复或未验证通过不放行上线。流程：发现→确定责任人/期限→修复→回归验证→门禁放行。设风险跟踪清单（唯一 ID、状态、证据），供审计与残余风险接受。这样红队发现从"报告"变成"闭环整改"。

红队价值在"闭环"而非"报告"。责任人+期限保证有人修，回归用例保证修得对、不复发，门禁保证不带着高危上线。这是安全治理的落地机制。

• 基线版本化管理
• 跨版本对比的可信度
• 避免分数虚高

模型版本变化会改变性能与安全，基线若不更新会虚高/失真。管理：基线随模型版本绑定——每个模型版本对应一份独立基线（含评测集、工具版本、参数、核查日期）；模型升级时用同一评测集重测，记录新基线与相对变化。避免虚高：1) 同一测试集固定版本，防止评测集被"刷"；2) 结果与模型版本、工具版本一起记录，跨版本对比明确标注；3) 用"相对变化"而非单个绝对值，防止绝对分数被旧模型抬高；4) 定期核查评测集是否与已知攻击脱节。基线变更走版本控制，避免新旧混用。

分数虚高常因"旧基线、新分数"或"评测集泄漏"。把基线绑定到模型版本并固定评测集版本，用相对变化衡量，才能让分数可信、不过时。

• 协同机制与边界
• 外部报告验证与纳入
• 奖励与合规

红队（内部可控）与 Bug Bounty（外部众包）互补：红队深度覆盖核心资产，Bug Bounty 广度覆盖外部发现的未知攻击。协同：定义清晰的测试范围与禁止边界给外部研究者；红队对外部报告做验证、去重、分级，将有效报告纳入统一风险清单；红队发现的高危问题也能衍生出 bounty 场景。外部报告纳入：红队复现验证——确认可利用性、影响、误报，修复后纳入回归用例。同时处理奖励发放、披露时限（协调披露）、合规（研究者不越界）。两者共享风险跟踪与分级体系。

红队与 Bug Bounty 是"内部深度+外部广度"的组合。关键是外部报告要经红队验证后纳入统一闭环，避免重复、误报与越界，并协调披露与奖励。

• 责任边界的类型
• 越界风险与规避
• 伦理与合规

红队测试要界定责任边界：隐私——不读取/泄露真实用户 PII，测试用脱敏数据；人身安全——不测试可能引发人身伤害的指令（医疗、自杀、暴力相关），或仅在受控环境验证；商业敏感——不触碰商业机密、不攻击第三方系统、不越权访问生产数据。界定方式：事前明确 out-of-scope 清单，用隔离环境与合成数据，禁止真实业务动作；对高风险测试（如伤害类）设审批与人工复核；出现越界立即停止并记录。伦理与合规纳入评审，红队测试须符合法律与公司政策。

责任边界是红队的"伦理底线"。隐私、人身安全、商业敏感三类最易踩线，必须事前界定、环境隔离、审批兜底，防止测试本身造成伤害。

• 两者的目标差异
• 方法差异
• 互补安排

红队测试目标是安全——发现模型可被利用的安全漏洞（注入、越权、泄露），方法偏系统化攻击（工具、攻击链、越狱集），产出是安全风险清单与修复项。对抗性用户测试目标是产品体验——发现用户如何误用、困惑或绕过产品预期，挖掘产品缺陷与可用性问题，方法偏真实用户探索与任务，产出是体验问题与改进行为。互补：红队侧重"安全漏洞"，对抗性用户测试侧重"体验与误用"，两者都找"非预期行为"。安排上可共用测试集与流程，红队发现的安全-体验交集（如过度拒绝）交给用户测试验证，用户测试发现的可被利用行为交给红队升级为安全用例。

两者都研究"非预期使用"，但目标不同：红队关心"能否被攻破"，对抗性用户测试关心"用户会怎么用错"。互补的核心是让安全与体验发现互相转化，避免重复劳动。

• 多模态对抗载体
• 检测方法
• 跨模态融合防御

多模态对抗把指令藏在图像（隐形文字、水印、子图）或音频（隐式语音、反向音频）中，绕过文本过滤。检测：图像用 OCR 前置提取文字再做指令检测，验证图文一致性（图里说的与文本指令是否冲突）；音频对转写内容做指令检测，识别"内容"与"指令"并做语音内容校验。融合防御：跨模态一致性校验——不同模态传递的信息若冲突或含指令，判为可疑；多模态输入统一进入安全检测管线，与文本护栏联动；对可疑多模态内容隔离、降权或拒绝，并告警。防御需融合 OCR、音频检测、文本护栏与一致性校验，而非单模态过滤。

多模态对抗的难点是"指令跨载体隐藏"。单一文本过滤必然失效，需跨模态检测 + 一致性校验 + 融合护栏，形成多模态纵深防御。

• 组合攻击的跨组件特性
• 轨迹保存的价值
• 复现与归因

组合攻击往往跨多个组件：Agent 编排、RAG 检索、MCP 工具调用、Browser Use 页面操作，单组件日志难以还原完整攻击链。保存跨组件轨迹（统一 trace，含每个环节的输入输出、工具调用、检索结果、页面操作、模型输出）用于：1) 复现——知道攻击如何在各组件间传递，才能复现与验证；2) 归因——定位是哪个组件被利用（如注入源自 RAG 文档还是 MCP 工具返回）；3) 关联——把多轮动作串联成完整攻击链，识别"注入→工具越权→数据外泄"的路径；4) 回归——固化轨迹为回归用例。轨迹要带时间戳、会话 ID、组件 ID 与脱敏处理。

组合攻击的难点是"跨组件、跨轮次"。只有统一轨迹才能串联各环节、定位根因、复现与回归。轨迹是组合攻击可观测性与可追溯性的基础。

• 各工具定位
• 覆盖场景划分
• 工具组合使用

各工具分工：HarmBench 是标准化的有害行为基准（benchmark），提供攻击方法对比与评测集，用于衡量模型安全基线；PyRIT（微软）支持有状态的多轮攻击编排（conversation、tool、agent），可编排多步攻击链与自动化越狱；Garak 是漏洞扫描器，对模型做自动化安全扫描（多种越狱、注入、数据泄露），输出结构化报告；Counterfit（微软）支持攻击与防御评估，可生成对抗样本。组合使用：用 HarmBench 基准做基线度量，用 Garak 做自动化漏洞扫描，用 PyRIT 做有状态复杂攻击编排，用 Counterfit 做对抗样本生成与评估。工具覆盖"基准、扫描、编排、对抗"四个维度。

工具各有侧重，单一工具覆盖不全。按"基准+扫描+编排+对抗"划分，让各工具在生命周期中发挥定位，形成完整覆盖。

• 自有攻击集与工具验证
• 泛化能力验证
• 防闭集过拟合

第三方防护工具（DeepTeam、Prompt Shields、Lakera Guard）的宣称能力需用自有攻击集验证，防止"供应商闭集过拟合"（工具只对训练样本有效）。自有攻击集：包含自有业务场景的注入、越狱、多模态攻击、行业特有风险样本，与供应商公开样本不同。验证方法：用自有攻击集跑工具，测绕过率、误报率、泛化能力；对比工具在不同攻击类别上的表现；测试工具是否误伤正常请求（过度拒绝）。结论用于选型与集成，并定期用更新的自有攻击集回归，防止工具随版本退化。

第三方防护工具的可信度需"用自有数据验证"。闭集过拟合是常见陷阱，自有攻击集能测泛化与误报，是选型与持续监控的依据。

• 开源生态的活跃度
• 工具与评测集质量
• 选用与维护

评估开源生态看几方面：活跃度——维护频率、issue 响应、社区贡献、版本迭代；质量——文档、API 稳定性、评测集覆盖面与标注质量；兼容性——是否适配主流模型/框架、是否支持自研评测集；许可——开源协议是否允许商用与修改。具体：HarmBench 标准清晰、评测集覆盖面广；AdvBench 提供对抗样例集（有标签的不安全行为）；PyRIT 提供灵活的攻击编排框架。评估后选用活跃、文档好、许可友好的工具，并保留落地自有评测集与模板的能力，避免依赖单一生态。

开源生态是红队能力的重要来源，但需评估"活跃度、质量、兼容、许可"。好的生态可复用、可定制，并能承载自有评测集，避免被单一工具锁定。