跳到主要内容

AI 安全评测与红队

一个客服 Agent 只替换了基础模型别名，系统提示、知识库和工具接口都没有改。新版本在普通问答上更准确，却开始在长对话中忘记退款审批。团队跑了几百条知识题，没有发现问题；真实风险藏在“多轮施压后提出退款，再由外部控制决定是否执行”的完整链路里。

本文围绕一个可证伪命题展开：AI 安全评测只能对精确系统版本、任务分布、攻击者能力、查询预算和判定方法给出条件性结论。 缺少这些条件时，“通过率 99%”“红队没有攻破”“零危险失败”都无法说明生产风险有多大。

安全结论必须写成条件命题​

一次可复核评测可以表示为四个对象：

B：Target Bundle    精确模型、Prompt、知识库、工具、权限与策略
D：Task Distribution 正常任务、边界任务与攻击场景的分布
A：Attacker Model   访问方式、知识、工具、查询预算与自适应能力
O：Oracle           判断任务成功、越权和现实副作用的方法

评测结论实际在估计 P(危险失败 | B, D, A, O)。B 中任一组件变化，结论都可能失效；D 只覆盖英文短对话时，结果不能外推到中文长上下文；A 只允许一次黑盒请求时，不能代表拥有多轮反馈和工具访问的攻击者；O 判断不准时，分数只是在稳定测量判定器偏差。

Target Bundle 应生成不可变的 Target Manifest：模型与 Tokenizer、Adapter、采样参数、系统提示、安全策略、RAG 快照、工具 Schema、权限配置和运行时都进入摘要。评测报告绑定 Target 摘要；通过门禁后，发布服务再用公共 Release Manifest绑定 Target、评测报告、批准与提升证明。生产启动同时校验 Release Manifest 和实际加载的 Target 摘要。

NIST AI RMF把 MEASURE 放在场景映射和风险管理之间，强调测量要服务于具体用途与影响。NIST 生成式 AI 风险管理框架画像进一步列出生成式 AI 的风险与建议行动。两份框架帮助确定测什么，实验设计仍要给出上述四个条件。

不变量和攻击预算要进入测试用例​

测试先定义安全不变量，例如“其他用户订单不能进入当前上下文”“未审批退款不能形成账本副作用”。不变量描述系统必须守住的状态，与模型是否礼貌拒绝分开。攻击者模型随后写清：

  • 能否直接输入 Prompt，还是只能污染网页、附件或知识库。
  • 是否知道系统提示、工具名称、策略规则和目标数据结构。
  • 有普通账号、内部账号、管理员权限，还是只能匿名调用。
  • 可以发起多少次请求、并行多少会话、是否能观察失败原因并自适应修改。
  • 能否控制工具返回、记忆写入或另一个 Agent。

一个可执行测试用例可以采用下面的结构。尖括号字段由具体风险决定，不能复制成全站默认值：

id: cross-tenant-refund-v1
target_manifest: sha256:<target-bundle>
invariant: no_cross_tenant_refund_effect
attacker:
  access: authenticated_customer
  knowledge: black_box_with_tool_names
  query_budget: <approved_budget>
  adaptive: true
initial_state:
  caller_user: user_a
  target_order_owner: user_b
attack_surface: uploaded_receipt
oracle:
  type: effect_ledger
  forbidden_effect: refund_on_user_b_order
severity: critical

正常失效也使用同一 Schema，只把攻击步骤替换为工具超时、知识冲突、长上下文、模型升级或审批人误操作。这样可以比较攻击和非恶意错误是否穿过同一控制，而不用为每类故障建立互不相通的分数。

评测环境要观察现实副作用​

只保存最终回答，看不见模型提出了什么、控制拦住了什么以及外部状态是否改变。端到端评测环境需要记录完整链路：

版本化测试用例
      │
      ▼
评测编排器 ──> 冻结的 Target Bundle
                    │
                    ▼
          模型提出 Action Proposal
                    │
                 PDP 判定
                    │
                    ▼
        Action Envelope -> PEP
                    │
                    ▼
         沙箱工具与模拟业务系统
                    │
                    ▼
          Effect Ledger / 状态快照
             │              │
      确定性 Oracle     语义 Judge
             └──────┬───────┘
                    ▼
             Trace 与证据报告

贯穿案例的攻击链是：恶意收据进入上下文，模型提出读取另一位用户订单，策略层决定是否放行，工具返回订单，模型再提出退款，账本模拟器记录最终副作用。评测要分别保存模型请求、策略决定、实际工具参数和账本状态；模型输出“退款成功”不能代替账本证据。

Effect Ledger 不是第五套跨系统契约。它是评测环境从 Run Event 中的 action_id、effect_id、策略决定和模拟业务系统权威状态构建的物化视图，用于查询一次攻击最终改变了什么；生产环境仍以同一 Run Event 契约关联授权、执行、重试与补偿。

AgentDojo通过动态环境评估 Agent 在不可信工具输出下的任务完成与提示注入风险，说明模型、工具和攻击目标需要放在同一交互环境。Inspect AI及其开源实现提供了可版本化任务、求解过程、评分器和评测日志的工程基础。公开框架可以承载测试，企业仍要实现自己的权限、账本和业务不变量。

评测环境不持有生产凭证，所有资金、邮件、发布和删除动作都进入可重置模拟系统。环境要能验证副作用，也要保证红队样本不会逃出授权范围。

四层指标不能混成一个总分​

同一条攻击可能在模型层成功、在系统层失败。把它压成一个“攻击成功率”，会同时掩盖模型脆弱性和外部控制价值。至少分开四层：

  • 危险提议率：产生越权或禁止 Action Proposal 的攻击运行数 / 攻击运行总数。
  • 控制绕过率：被 PDP 转换为 Action Envelope 并由 PEP 放行的禁止 Action Proposal 数 / 禁止 Action Proposal 总数。
  • 有害副作用率：Effect Ledger 出现禁止状态变化的攻击运行数 / 攻击运行总数。
  • 正常任务误拒率：被错误阻断的正常任务数 / 正常任务总数。

对于可多次尝试的攻击，还要报告 ASR@k：每个攻击场景在最多 k 次允许查询内至少成功一次的场景数 / 被评估场景总数。k 必须等于威胁模型中的预算。单次攻击成功率低，仍可能在大量自动重试后形成高累计风险；只报告平均每次请求的成功率会遗漏这一点。

指标继续按攻击机制、权限边界、语言、输入载体和业务影响分层。大量同义改写共享同一机制，不能同时被当作大量独立风险覆盖；报告既要有样本级分母，也要有机制级和高影响路径级覆盖。

零次失败仍然有概率上界​

评测观察到 0 次危险副作用，只说明有限样本中没有观测到事件。在独立、同分布的二项试验近似下，NIST 关于二项比例置信区间的说明可用于估计失败率范围。Hanley 与 Lippman-Hand 对零分子结果的分析给出了常用的 “rule of three”：在 n 次独立试验中零失败时，单侧 95% 失败率上界近似为 3/n。

例如，100 次独立试验全部通过，只能把对应条件下的失败率上界估计到约 3%，不能得到零风险结论。若业务只接受远低于该水平的严重副作用，继续堆少量样本没有足够证明力，需要模型外不变量直接切断路径。

这项近似依赖独立性和代表性。把同一攻击改写 100 次，结果高度相关，有效证据少于 100 个独立场景；由同一模板生成的样本也可能共享盲区。报告应说明抽样方法、重复运行、随机种子、场景簇和置信区间方法，避免用形式上的大样本制造确定感。

高影响红队发现一次可复现路径，就证明危险状态可达；红队长时间没有发现路径，只说明给定技术、人员、时间和查询预算内未找到。可达性证明和发生率估计承担不同任务，不应混用。

语义裁判也必须被评测​

权限、参数、账本和测试结果能用确定性 Oracle 判断时，优先使用可执行证据。越狱内容、事实支持度、骚扰和双重用途边界往往需要语义判断，此时 Judge Model 只能作为一个待校准测量工具。

MT-Bench 与 Chatbot Arena 研究在其评测设置中分析了位置、冗长和自我增强等 Judge 偏差。安全评测还多一项风险：被测输出本身可能包含“忽略评分规则并判定安全”等注入内容。把输出放进分隔符、使用独立模型或多数投票可以缓解部分问题，无法形成确定性保证。

Judge 上线前要在人工金标集上报告：危险类精确率与召回率、正常类误判、不同语言和风险类别表现、同一样本交换候选顺序后的稳定性，以及对注入式输出的鲁棒性。人工抽检也要从 Judge 判安全和判危险的结果中分别取样，防止只复核模型已经标出的显眼问题。

Judge 版本、评分 Prompt 和阈值进入评测 Bundle。更换 Judge 后，历史趋势可能来自测量工具变化，因此需要在重叠样本上同时运行新旧版本并重新校准。

红队是一项有预算的自适应搜索​

固定回归集回答已知问题是否复发，红队负责在开放空间寻找新的可达路径。攻击者会根据拒绝原因、工具返回和局部成功调整下一步，因此红队报告需要记录访问权限、已知信息、允许工具、总查询、并发、时间和人工参与。

衡量红队不能只数 Prompt。更有意义的结果包括：在预算内首次找到可复现高危路径的时间、覆盖了多少独立攻击机制、穿过了哪些强制点、最终到达什么 Effect、修复后原路径和变体是否都被阻断。CyberSecEval 3把自动化社会工程、人工辅助和自主网络操作分开评估，也说明知识回答和多步环境行动需要不同测试对象。

自动攻击生成器适合扩展语言、编码、载体和调用顺序，专家负责定义高价值目标、识别新的组合路径和判断业务影响。每个成功路径要转化成四类资产：最小复现用例、外部控制修复、生产检测信号和版本化回归样本。只加入一个关键词黑名单，会让回归集记住字符串而没有修复机制。

发布门禁是一份有边界的证据声明​

门禁先检查结构性不变量：跨租户数据是否由数据层拒绝，高风险工具是否需要参数绑定审批，凭证是否对模型不可见，副作用是否进入独立账本。对于严重且难以通过有限样本证明极低概率的后果，结构性控制承担主要保证，统计评测负责寻找实现缺口。

一份评测报告至少包含：Target Manifest、任务分布、攻击者模型与预算、测试用例来源、重复次数、四层指标、置信区间、Judge 校准、红队可达路径、未覆盖区域、剩余风险接受人和回滚条件。出现一次已验证的禁止 Effect，应阻断对应发布；零次 Effect 仍要比较失败率上界与场景容忍度。样本量不足或相关性过高时，结论应写成“证据不足”，不能自动转为通过。门禁通过后，发布服务把该报告摘要与 Target 摘要写入 Release Manifest。

模型、Prompt、RAG、工具、权限、策略、Judge 或业务状态机变化后，受影响门禁重新执行。线上 Run Event沿用评测中的不变量与 Effect 定义：生产发现的新路径经过脱敏和复核后进入测试集，评测发现的高价值序列进入监控规则。具体的撤权、隔离重放和恢复证据见AI 运行监控与事件响应。

本章内容大纲