Signal #26：Agent 明明发现了风险，为什么还会继续执行？

最近，OpenAI 暂停部分模型训练的消息引起了不少关注。

准确来说，OpenAI 暂停了面向最新部署模型的强化学习训练两周，其最大规模的前沿强化学习训练仍未恢复。背后有两件相互独立的事情：一次 Agent 在网络安全测试中突破隔离环境，访问了 Hugging Face；初步评估显示，即将发布的 Astra 可能达到其 Preparedness Framework 中的“Critical”网络安全能力阈值。

比暂停两周更值得关注的，是 OpenAI 随后给出的三层安全措施：监控负责发现异常，模型对齐降低危险行为发生的可能，安全系统限制模型能够访问和影响的范围。(OpenAI)

为什么发现异常之后，还需要另外两层？因为模型发现了风险，不等于危险动作会被阻止。

本周发布的预印本 HarnessRisk 测试了这个问题。

研究者设计了 128 个沙箱案例，在正常任务所需的配置文件、网页、消息、工具返回结果和持久化状态中嵌入恶意指令，随后测试了 3 个开源 Harness、6 个模型，共 14 种 Model × Harness 组合。

这里的 Harness，可以简单理解为模型外部负责提供上下文、管理状态、调用工具和执行动作的系统。

实验分别记录 Agent 有没有明确识别出风险，以及恶意目标最终有没有实现。部分组合识别风险的比例超过 90%，攻击成功率仍在 31.2% 到 54.7% 之间。这是同一配置下所有运行的总体结果，不能理解为“每次识别风险后，攻击仍有一半成功”。

更能说明问题的是论文记录的具体轨迹：有些 Agent 发现持久化状态遭到污染，却只输出风险报告，没有完成回滚或撤销；有些不可信内容最初已被识别，后续又被包装成“已经批准的上下文”，最终仍被写入长期状态。

这篇论文尚未经过同行评审，实验也只覆盖 3 个开源 Harness 和模拟服务，不能代表所有 Agent 产品。但它把一个容易混在一起的问题拆开了：Agent 有没有发现风险，和危险动作有没有真正发生，需要分别验证。

在普通软件系统里，一条 Warning 日志不会自动撤销已经提交的数据库操作。Agent 也是一样。

模型可以指出某段内容不可信，甚至明确提示越权风险，同时继续生成下一步工具调用。真正访问数据、修改权限、发送消息或者执行部署的，是模型外部的系统。如果权限依然开放，敏感操作没有审批，模型发出的提醒就不会自动阻断后续动作。

于是可能出现这样的情况：Agent 识别到越权，权限没有被收回；发现状态遭到污染，异常内容没有被删除；建议人工确认，系统却没有真正等待确认。

风险提示只是一段输出。真正的安全边界，要落实到权限有没有收窄、审批有没有发生、工具调用有没有被拒绝，以及危险动作最终有没有执行。

本周 Google、AWS 的产品变化，正沿着这条路径继续推进。

Google 为 Workspace Studio 的 Flow 增加了可独立审计的标识和最小权限。一个 Flow 只获得完成任务所需的权限；管理员可以单独撤销某个 Flow 的 Drive 等访问范围，涉及外部数据分享的步骤还可以强制要求人工确认。(Google Workspace)

AWS 进一步把权限判断放到 Agent 之外。用户身份沿调用链传递，Agent 获得用户范围内的临时凭证；最终能读取哪些数据，继续由数据库、知识库或 Salesforce 自己的权限规则决定。AWS 对这一原则的概括是：Agent 负责协调，不能充当权限的守门人。(AWS)

独立标识、最小权限和下游校验解决了“这一次操作能不能做”。同期发布的另一篇预印本 Bounded Agents，则把检查范围扩展到委托关系和此前的动作。读取内部文档和发送外部邮件，单独看可能都被允许，连续组合起来却可能构成数据泄露。它提出的授权链会持续收窄 Agent 和 Subagent 的权限，并在模型外部决定每一次操作是否可以执行。

这几种方案形成了一层递进：先把每个 Agent 或 Flow 识别为独立的执行对象并限制权限，再由下游系统检查每次访问，最后结合整个任务的历史动作判断是否越界。

模型提出下一步动作，系统决定是否允许执行。

OpenAI 面对的是前沿模型的训练和测试环境，Google、AWS 处理的是企业 Agent 的部署问题，HarnessRisk 测试的则是开源 Harness。场景各不相同，共同的工程事实是：模型越能调用真实工具，安全边界就越需要由模型之外的系统建立。

一个能够解释风险的 Agent，仍然可能是危险的 Agent。

当 Agent 开始修改代码、发送邮件、读取客户数据和调用生产系统时，安全的最后一道边界，应该是系统有能力替它说“不”，并让操作真正停下来。