红队测试如何覆盖提示注入风险？
简化版
提示注入红队不是无限尝试越狱话术，而是先盘点系统能访问的数据和工具，再沿直接输入、RAG 文档、网页、邮件、工具结果和长期记忆等信任边界构造攻击，验证是否能泄密、越权或污染状态。
红队应在隔离环境中使用合成秘密和假工具，记录完整 Trace、攻击预算和成功后果。发现问题后要做根因分析、修复、同机制变体复测，并把样本沉淀为回归测试，避免只屏蔽原始字符串。
红队的产物不是一份“神奇 Prompt 列表”，而是可复现的攻击路径、影响证据和防线改进闭环。
详细版
典型流程：
资产与权限盘点
-> 威胁建模和攻击假设
-> 构建隔离环境/Canary Secret
-> 手工探索 + 自动变异 + 自适应攻击
-> 验证工具状态、数据流和持久化影响
-> 严重度评估、根因分析
-> 修复、同类变体复测、回归入库例如红队在知识库文档中植入指令，要求 Agent 读取假客户表并调用沙箱外发工具。只有当系统真的读取并传输了合成数据才算完整攻击成功；模型复述注入文字属于较低级信号，需分别记录。
| 角色 | 关注点 | 产物 |
|---|---|---|
| 红队 | 发现可利用路径 | PoC、Trace、影响证据 |
| 蓝队 | 监测与阻断 | 日志、规则、防线修复 |
| 产品/安全 | 风险决策 | 严重度、发布与披露计划 |
| 评测团队 | 防复发 | 变体化回归样本 |
完整版教学
1. 先画系统与信任边界
列出 System Prompt、用户输入、RAG、网页、工具、记忆、模型供应商和输出通道。标出哪些内容可信、哪些由外部控制、哪些动作有副作用。
红队优先测试“不可信内容跨越边界变成指令”的路径，而不是平均轰炸所有组件。
2. 资产盘点决定攻击价值
目标资产可能是秘密、其他用户数据、工具权限、长期记忆或业务决策完整性。没有高价值资产的纯聊天 Demo 与可发邮件、可支付的 Agent 严重度不同。
使用合成资产代替真实密钥和客户数据，确保测试成功也不会造成生产损害。
3. 建立攻击假设
每个测试写清前置条件、载体、攻击者能力、预期防线和成功条件。例如“攻击者可控制被 Agent 摘要的网页，但不能直接访问工具凭证”。
假设明确后，失败结果才可解释：是模型抵抗了攻击，还是路径根本没有触达目标。
4. 手工红队有什么价值
专家能理解系统语境，逐步调整攻击并发现新机制，如工具结果注入、跨会话记忆污染和确认 UI 欺骗。
手工探索适合发现未知路径，但覆盖有限、难完全复现，因此每次成功都要保存最小 PoC 和环境版本。
红队人员还会观察系统给出的局部反馈，判断下一步应改变载体、权限还是时序，这种因果探索很难由静态模板替代。发现机制后，再交给自动化做规模化变体测试。
5. 自动化攻击如何扩覆盖
对已知机制做语言改写、编码、长上下文、分隔符和多轮变体；攻击 Agent 可根据目标响应继续尝试。
| 自动方式 | 优点 | 风险 |
|---|---|---|
| 模板变异 | 快、可控 | 容易同质化 |
| 模型生成攻击 | 表达多样 | 可能偏离目标 |
| 自适应 Agent | 能利用反馈 | 成本高、需固定预算 |
| 搜索/优化 | 可找边界输入 | 可能过拟合评分器 |
所有候选需按攻击机制去重与验证。
6. 为什么必须检查真实副作用
文本响应可能说“我不会执行”，但工具调用已发出；也可能口头声称成功却什么都没做。红队必须查看工具日志、网络请求、数据库和记忆状态。
对 Agent 来说，最终系统状态比最终一句自然语言更接近安全真相。
沙箱应能捕获和回滚所有副作用。
7. 间接注入要覆盖哪些来源
网页隐藏文本、PDF 批注、邮件签名、代码注释、工具错误消息、图片 OCR 和共享记忆都可能承载注入。测试内容应保留正常业务信息，验证系统能用数据而不执行其指令。
简单删除含“ignore”文档不是成功防御，因为会破坏正常检索并可被同义改写绕过。
8. 多轮与持久化攻击如何测试
攻击可先写入长期记忆，再在后续会话触发；或把目标拆成多个低风险请求。测试需要跨轮、跨会话观察状态。
每次运行前后导出记忆 Diff，确认未授权规则、偏好和秘密没有被持久化。
9. 严重度如何评估
结合影响、规模、可利用性、权限要求、是否持久化和是否可自动传播。一个只能让模型复述无害文本的注入，与无需确认即可外传数据不能同级。
提供可复现证据，但最小化展示可能被滥用的细节；高危漏洞按内部披露与修复 SLA 处理。
severity_score = impact × exploitability × reach × persistence实际组织可使用离散矩阵而非简单相乘，但所有等级必须绑定示例和响应时限。
10. 如何定位根因而不是封字符串
根因可能是指令与数据未隔离、工具权限过大、输出未校验、记忆写入无授权或监控缺失。只把 PoC 关键词加入黑名单，会被改写绕过。
做防线消融与最小化输入，确认攻击在哪个边界成功，再修架构或权限。
11. 修复后为什么要测同类变体
原 PoC 失败只能证明一条字符串被阻断。应保持攻击机制不变，换载体、语言、目标字段和多轮路径，验证防御泛化。
还要加入正常对照，确认修复没有让所有外部文档和工具任务失效。
12. 红蓝协作如何形成闭环
红队提交标准化报告：环境、前置条件、步骤、实际后果、严重度与证据；蓝队提交修复和监控；评测团队将最小样本和变体加入私有回归。
定期复盘检测是否提前告警、日志是否足够，以及真实响应流程是否达到 SLA。
13. 如何控制测试风险
禁止连接生产数据和真实外发通道，使用最小权限测试账户、网络隔离、速率限制和 Kill Switch。自适应攻击设置轮数、Token 和时间预算。
测试数据和漏洞报告本身也敏感，要限制访问、设置保留期限并审计下载。
14. 常见误区与追问
- 误区：红队就是收集越狱 Prompt。 真正目标是验证端到端资产和权限是否可被利用。
- 误区：模型回复拒绝就代表攻击失败。 工具或记忆可能已经发生副作用。
- 误区：封禁 PoC 关键词就是修复。 应修复信任边界、权限和验证缺口。
- 误区：只测直接用户输入。 间接载体和持久化路径往往风险更高。
- 误区：红队成功越多越好。 测试必须有明确授权、隔离和停止条件。
- 追问：如何衡量红队覆盖？ 按资产、入口、攻击机制、工具能力和严重度矩阵统计，而不是按 Prompt 数量。
- 追问：修复如何验收？ 原 PoC、同机制未见变体和正常对照三者都要通过。
15. 加强记忆
- 先画边界，再攻路径。
- 用合成资产和沙箱，绝不拿生产冒险。
- 手工找机制，自动化扩覆盖，自适应攻击固定预算。
- 看真实状态：工具、网络、数据库和记忆都要验。
- 闭环：根因修复、变体复测、正常对照、回归入库。