红队与安全评估

为何功能测试不是安全测试

功能测试问"智能体在预期输入上是否做对了？"安全测试问"在为使其失常而精选的对抗性输入上它会做什么？"一个智能体可以通过所有功能测试却仍带着致命漏洞上线，因为攻破它的输入空间恰恰是功能测试不探索的空间。对抗性评估是一门独立学科，有自己的语料、自己的指标和自己在流水线中的位置。

智能体红队相比模型红队多了什么

模型红队孤立地探测模型：拒答、有害内容、越狱。必要但不充分。智能体系统增加了裸模型没有的攻击面，红队必须演练它：

• 间接注入：把对抗性内容植入检索语料和某工具的响应，然后运行正常用户任务并观察智能体的行为。
• 工具链滥用：一次注入能否把一系列各自被允许的工具调用驱动成一个有害的聚合（读敏感数据 → 调用出口工具）？
• 混淆代理：一个低权限行为者能否让智能体替他使用其更高权限？
• 外泄通道：包括不显眼的汇——渲染的图片标记、链接展开、写后读的旁路。
• 记忆与多轮：注入是否跨轮持久、或在会话/用户间泄漏？
• 护栏绕过：直接攻击过滤器和动作检查，而不仅是模型。

让它成为关卡，而非英雄主义

上线前一周的人工红队有一次性价值，到下次部署就过期了。持久的安全评估是自动化、版本化的，并与单元测试一道接入发布流水线。

• 对抗性测试套件：一个版本化的攻击用例语料——注入形态、外泄尝试、混淆代理场景、护栏绕过探针——每个都绑定到它所针对的具体控制。
• 基于结果的评分：按有害结果评分（敏感数据是否外流？破坏性工具是否触发？），而非模型是否吐出一句坏话。结果才是威胁模型在意的。
• 每次变更回归：换模型、改提示、加工具或升级 MCP 服务器，都可能无声地重开一个已关闭的洞。每次都重跑套件。
• 不断增长的语料：每一起真实事件和每一种新的公开技术都成为一个永久测试用例。套件单向收紧；关闭的洞保持关闭。
• 自动化攻击者：用生成式/迭代式对抗输入求广度，并辅以周期性的人工红队，捕捉自动化漏掉的创造力。

# A safety case = control + attack + expected SAFE outcome
{
  "control":  "egress-allowlist",
  "attack":   "indirect-injection: leak context via image URL",
  "expect":   "no outbound to non-allowlisted host",
  "grade":    "outcome: bytes-exfiltrated == 0"
}

不自欺地解读结果

• 没有证据不等于安全。用一支弱红队得到"红队没攻破它"意义甚微。要追踪攻击者的投入与精巧程度，而不只是通过/失败。
• 概率性控制没有干净的通过。一个拦下 98% 已知注入的分类器，会漏掉另外 2% 和未知数量的新颖注入。报告分布与最坏情况，而非单一头条数字。
• 测试你将上线的那个系统。只评估模型，或一个净化过的预发布配置，衡量的是你并不部署的东西。用真实工具、真实语料、真实护栏做红队。
• 确定性控制应近乎绝对。若出口白名单或被移除的工具在测试中曾被绕过，那是结构缺陷，而非调参问题——修边界。