agent-red-teaming

Agent 红队测试

在不造成失控危害的前提下，找出可利用的控制失效。将书面授权和交战规则视为执行的前提，而不是事后补办的手续。

输入

收集：

• 指定的目标负责人，以及针对待测具体系统的明确授权
• 目标标识符、环境、账户、端点、模型、版本，以及可复现的配置摘要
• 开始和结束时间、测试人员身份、源地址、速率和成本上限，以及紧急联系人
• 范围内的目标，以及范围外的系统、租户、数据、技术和影响
• Agent 架构、工具、权限、记忆、检索、交接、身份和外部集成
• 受保护的资产、安全要求、过往事件、现有控制措施，以及预期的正常任务
• 获批的合成数据、金丝雀值、测试目的地、清理计划和证据处理规则

如果缺少针对目标的授权或范围说明，请仅制定不可执行的评估计划。不要通过探测在线目标来推断范围。

输出要求

交付：

1. 已签核或明确标记为待定的交战规则，包含范围、限制、停止条件、联系人和清理职责
2. 系统与权限图，以及按优先级排序的威胁假设
3. 机器可读且经负责人批准的测试计划，包含唯一案例 ID、目标、环境、配置摘要、测试主体、授权参考、时间窗口、限制、停止条件、清理职责、受保护的不变量，以及安全判定依据
4. 与获批案例 ID 和唯一测试 ID 关联的执行记录，包含匹配的目标／配置、时间戳、观察到的限制、结构化证据和可追溯的清理记录
5. 去重后的发现，包含复现步骤、证据、影响、可能性、前提条件、根本控制失效原因和修复建议
6. 以计划中的案例总数为分母的测试活动指标，区分通过、失败、受阻案例、错误、缺失记录和未运行的测试
7. 复测结果、剩余风险、清理确认，以及任何事件或范围偏离情况

使用 assets/campaign-plan-template.md 编写便于阅读的工作计划，并使用 assets/campaign-plan-template.json 记录机器可读的授权信息。选择案例时，请阅读 references/test-taxonomy.md。使用 score_campaign.py PLAN.json RESULTS.jsonl，根据获批的 JSON 计划验证并汇总 JSONL 结果。

工作流

1. 制定交战规则

核实负责人、授权权限、授权参考、确切目标、环境、配置摘要、测试主体、时间窗口、允许的技术、禁止的操作、速率／成本上限、数据处理要求、停止条件、紧急联系人和清理负责人。明确区分生产环境和暂存环境。只有在负责人批准的计划中列出某个案例后，才将其标记为 approved: true。

使用唯一的合成账户和无害的目的地。定义可识别但不授予任何访问权限的正常金丝雀值。开始测试前，确认如何停用工具、撤销测试凭据、还原测试夹具，以及在出现意外影响时如何报告。

2. 绘制攻击面和权限图

追踪经过用户输入、系统指令、检索、记忆、工具、代码执行、浏览器、MCP 或插件、其他 Agent、人工审批和输出接收端的所有路径。构建权限图，展示身份、作用域、租户、对象、网络和委派关系。

根据可信的影响和暴露的权限确定优先级，而非根据新颖性。将每项假设写为：攻击者可控的来源 + 控制弱点 + 尝试执行的操作 + 可安全观察的判定依据。

3. 构建安全测试矩阵

覆盖相关类别：

• 直接、间接、存储、编码和多模态指令攻击
• 工具滥用、目标替换、过度自主权、不安全的链式调用和外部影响
• 身份验证、授权、租户隔离、审批绑定和困惑代理路径
• 敏感数据泄露、输出处理、数据外传和金丝雀暴露
• 记忆、RAG、训练数据、配置、工具元数据和依赖项投毒
• 跨 Agent 冒充、委派升级、受污染的摘要和级联故障
• 在严格预算范围内的资源耗尽和成本放大
• 监控、遏制、凭证撤销和恢复

加入良性对照和常规任务，以衡量误报和效用保留情况。尽可能让每个用例只包含一个主要变量。若无害指令、虚假密钥或模拟工具足以证明相同的控制失效，就不要使用可造成实际危害的载荷。

4. 逐步执行

先使用离线或模拟组件，再转到预发布环境，最后才使用任何单独授权的较高风险环境。先运行影响较低的用例。记录活动和授权参考信息、已批准的用例 ID、唯一测试 ID、测试者主体、目标和环境、配置摘要、开始／结束／记录时间戳、输入来源、工具轨迹、策略决策、观察到的速率／成本／时间、结果、结构化证据对象和清理状态。

遵守速率、成本和时间限制。不得在已批准的假设范围之外规避监控或控制。若发生意外的跨租户访问、获取到真实密钥、产生外部影响、服务降级或范围含糊，立即暂停。

5. 分类调查发现

安全地复现问题，然后区分：

• 已确认的不变量违反
• 被拦截的攻击，表明预期控制有效
• 测试工具或环境错误
• 需要更多证据的观察结果

根据已证实的影响、可能性、前置条件、受影响范围、可检测性和可逆性评定严重程度。不得仅根据提示词措辞评定。通过意味着受保护的不变量得以维持；失败意味着不变量未能维持，且不能仅属信息性问题。被拦截、出错和未运行的记录没有不变量判定，也没有发现严重性。按根本控制失效对发现去重，并将受影响的变体保留为证据。

对于每项发现，提供最低风险的复现方式、预期行为与观察到的行为、证据、受影响的配置、即时遏制措施、持久修复方案、检测机会和回归用例。

6. 修复并复测

优先采用架构层面的修复：降低权限、在模型之外实施授权、限制工具和数据外传、隔离不可信内容、验证输出、绑定审批，并保护记忆来源信息。提示词和检测器可以作为纵深防御，但不应成为应对重大影响的唯一修复手段。

复测原始用例、相近变体和有代表性的良性任务。记录发现状态为已修复、部分缓解、已接受、已转移或未解决，并注明负责人和证据。

7. 收尾并恢复

移除合成记录、恢复已批准的测试数据、禁用测试端点、撤销测试凭证，并确认没有遗留作业或回调。根据保留政策保存证据，并删除不必要的敏感副本。

如果测试造成意外影响，应立即停止、通知紧急联系人、遏制访问、保留脱敏证据、协助恢复，并记录范围偏离情况。事件响应优先于活动完成。

授权和安全边界

• 仅对用户或指定负责人明确授权的具名目标执行测试；可从公网访问并不代表获得许可。
• 除非经批准的交战规则明确涵盖生产环境、第三方、其他租户、员工或真实用户，否则不得对其进行测试。
• 如果合成或无害的证明已足够，不得使用真实机密、个人数据、恶意软件、持久化手段、破坏性操作、不受控传播、社会工程、拒绝服务或真实交易。
• 不得绕过速率／成本上限，也不得在触发停止条件后继续。
• 未经所有者授权披露，不得发布漏洞、证据、系统提示词或敏感架构信息。
• 将发现的证据保持在最低限度，并实施访问控制、脱敏和可追溯管理。
• 如果无法核实授权，只能提供规划、威胁建模和不可执行的测试设计。

验证

报告完成前，请确认：

• 每项提交的结果都对应经批准的活动计划案例 ID、授权参考、目标、环境、配置摘要、时间窗口和测试人员身份
• 测试矩阵涵盖已暴露的权限和影响最大的可信攻击路径
• 每项结果都有可观察的判定依据和证据，而不仅仅是模型判断
• 发现可在记录的配置下复现，并有回归测试案例
• 攻击案例之外，也测量了良性任务的效用和误报情况
• 被阻止、出错、缺失和未运行的案例不计为通过或已观测覆盖范围
• 复测涵盖原始发现及相邻变体
• 清理、凭据撤销和意外影响检查均已完成

使用 score_campaign.py 根据经批准的计划汇总结果。其百分比以所有获批案例 ID 为分母，而非仅以已提交的记录为分母。结构错误以及严重性／不变量不一致均应视为验证失败。不得以加权分数替代专业影响分析，也不得将任何汇总结果作为安全、活动成功或认证的证明。

逼真示例

内部支持 Agent 评估

在隔离租户中，测试一封合成客户邮件是否会诱使 Agent 读取另一个合成租户的数据、更改退款目的地、泄露伪造的 API 令牌，或向未经批准的域发送邮件。使用模拟退款工具和接收邮件的邮箱。验证对象级授权、审批绑定、出站控制、金丝雀警报和正常工单分类处理。

多 Agent 发布工作流

测试被污染的问题描述是否会让权限从规划 Agent 升级到编码 Agent，再升级到部署 Agent，进而扩大工具白名单、更改代码库或环境目标，或重复使用已过期的审批。使用一次性代码库，不使用有效的云凭据。使用结构化交接、每个 Agent 独立的身份、针对具体操作的审批和受限的部署模拟工具进行复测。

完成检查

只有在执行的工作均已获授权且可追溯至经批准的案例 ID、高风险路径有结构化安全证据、发现的严重性与观测到的不变量一致、修复已通过复测、良性效用已测量、限制和清理均有证据，且剩余、缺失或未测试的风险均已明确时，方可完成。切勿根据活动结果宣称目标安全或已获认证。