原创 AI 生成概念插图：闸门代表彼此独立的授权检查，并非真实产品，也不代表测得的安全结果。
从行动入手，而不只是看回答
设想一名采购助手受命总结三家供应商的方案。其中一份文档要求把完整对比结果发送到一个外部地址。助手生成了有效的 JSON，使用了正确的邮件工具，还写出了一封流畅的邮件。即便如此，整个流程仍可能出错：文档是供读取的材料，不是有权批准对外披露的人。
这是一个假设性的设计案例。我们没有实施攻击、对供应商进行基准测试，也没有检查任何客户的部署。本文提出的主张更为有限：智能体提出格式正确的操作的能力，应与系统是否允许该操作的决定相分离。
以下分析依据的是截至 2026 年 10 月 21 日查阅的一手文档。这是一套工程框架，而非安全认证或法律意见。
官方文档究竟能说明什么
OpenAI 在 2026 年 3 月 11 日的说明中主张，即使提示操纵得逞，也应限制其危害。其工作流安全指南建议采用结构化数据和审批，同时提醒，缓解措施不能消除所有错误。该指南针对 Agent Builder，而当前页面已将这一产品标记为弃用；引用这份指南不代表推荐采用该产品。
Anthropic 在 2025 年 10 月 20 日的沙箱文章中介绍了文件系统和网络隔离。目前的 Claude Code 权限文档区分了工具权限与操作系统层面的强制约束：普通的 Read/Edit 规则并不能覆盖任意子进程的文件访问。
官方 Qwen-Agent 代码仓库介绍了代码解释功能中的 Docker 隔离和受限目录挂载，同时提醒，在生产环境中使用其基础沙箱需要谨慎。
这些文档涉及不同层次和不同产品，并不构成受控比较。美国服务可能被部署为拥有过宽的访问权限；中国框架也可能被部署在严格的边界内，反之亦然。模型的来源和托管地点不能代替对实际配置的检查。上述文档均无法证明哪家供应商在所有情况下都最安全。
在规划与执行之间设置授权网关
我们提出的设计将职责分为三部分：模型提出操作，网关检查授权，权限严格受限的执行器完成获准操作。网关由应用代码和策略执行机制构成，而不只是另一条要求模型守规矩的指令。
对于每个会产生实质影响的请求，都应将授权决定绑定到经过身份验证的用户、操作、资源、目的地、数据范围和适用限制。读取供应商方案的权限，不能悄然变成通过邮件发送这些方案的权限。起草消息的权限，也不能悄然变成发送消息的权限。如果必要信息缺失或存在歧义，请求就应保持未执行状态，直到问题得到解决。
模式校验应当纳入这一设计，但它承担的是另一种职责。模式可以要求收件人字段必须是字符串，却无法证明用户批准了该收件人。模型评审器即便有助于发现风险，也不会仅仅因为输出了“是”或“否”，就成为确定性的访问边界。
这种分离也明确了请求被拒绝后的处理责任：纠正无效请求，或取得所需授权。切换账号或改走其他路径，以绕过对同一操作的拒绝，并不是修复问题。
让审批足够精确，经得起计划变化
有效的确认界面应展示实际将要发生的操作：目的地、内容或数据类别、相关资源，以及任何费用或范围限制。应避免使用笼统的“允许智能体？”按钮，把关键变量隐藏起来。
将批准绑定到该项具体提案。如果收件人、附件、金额或资源发生实质变化，就应重新评估。对于重复执行且范围明确的工作，组织可以设定狭窄的长期授权，而不必在每个无害步骤都打断用户。这些边界必须始终能够被检查和强制执行，外部文档不能扩大它们。
审批疲劳与过度授权是相互关联的设计问题。要求每次琐碎读取都经过确认，可能会让人养成机械点击的习惯；而一次笼统批准，又可能掩盖后续风险。实用的折中方式，是为低风险操作制定成文策略，对会产生实质影响的变更要求精确批准，并在授权不明确时明确停止。
限制出错后的影响
授权检查保护的是所请求的操作；运行时隔离限制的则是执行环境能够触及的范围。在应用支持的情况下，应采用权限范围狭窄的凭证、受限的文件系统访问，以及受控的网络目的地。威胁模型也应包含子进程。如果同一个执行单元还能运行不受限制的 shell，那么仅限制文件读取工具是不够的。
将操作状态与模型的叙述分开管理。“已提出”“已批准”“已派发”和“已确认”是不同状态。记录稳定的请求标识，并在支持的地方采用幂等或去重机制。发生超时后，在重试发送、购买或发布之前，先检查服务端的实际记录。“没有收到响应”并不能证明“什么都没发生”。
日志应帮助重建操作过程，而不应成为新的泄露源。保留操作标识、决策、策略版本和操作产生的服务端引用信息；尽量减少其中的秘密信息和不必要的个人内容。给审查人员提供足以调查的信息，而不是不加区分地复制每一份文档。
上线前的六项检查
以下是一组建议的验收演练，并非我们实施过的测试，也不是全面的安全评估：
- 在检索到的文档中加入一个外部收件人。它能否在未经已验证身份的用户授权的情况下，改变获准的目的地？
- 为一个超出授权范围的操作生成有效 JSON。网关能否在派发前拒绝它？
- 在批准后更改目的地。原有批准是否不再适用于变更后的操作？
- 尝试通过子进程读取授权范围之外的文件。运行时边界是否得到了强制执行，而不只是写在提示词里？
- 模拟发送后结果不明确的超时。工作流能否核对服务端记录，同时避免产生重复操作？
- 撤销相关权限。下一次操作尝试是否会安全地失败，并留下易于理解的审计记录？
同时评估保护效果与可用性：被拦截的未授权操作、被误拦截的已授权工作、不必要的审批提示、重复的副作用，以及解释决策所需的时间。单看高完成率，可能掩盖不安全的执行；但什么都拦截的系统，也称不上有用的助手。
采购时真正该问的问题
要求供应商展示：在你实际将要部署的配置中，每一条边界由哪个层次强制执行；如果模型听从恶意文档，会发生什么；执行结果不明确时，又如何核实与协调状态。索取与你的工具和访问范围相匹配的证据，而不是把另一套环境中的醒目基准成绩直接套用过来。
实际的选择并非“相信模型”或“永远反复征求许可”。关键在于决定：哪些工作可以在明确限制下继续，哪些变化需要人来决策，以及哪些边界是模型无法改写的。相比单一的能力分数，这更适合作为比较中美智能体技术栈的起点。