深度解读 · 约 4 分钟阅读
AWS 的 Trust in Depth：让 Agent 决策，让外部控制守边界
四层方法连接任务范围、身份、执行约束和证据；形式化证明仅适用于明确规则与假设。
- 原文发布
- 本站发布
- 核实时间
AWS 在10月15日的文章提出 Trust in Depth，讨论如何让 Agent 承担后果较重的任务。核心不是让模型口头保证守规矩，而是将可执行边界放在推理之外，按 Scope、Know、Bound、Observe 四层组织。这是附带离职处理示例的治理方法，不是宣布所有行为都可被数学证明正确，也没有取消人的责任。
听读资讯
朗读当前文章，或连续收听资讯。
正在准备听读…
设备语音
朗读由浏览器或设备处理，AISubHub 不向音频 API 发送文本。可用语音及锁屏播放能力因设备而异。
继续播放时可能重复一小段。
一分钟速览
- 自动推理只能在明确建模的路径与假设内证明精确定义的规则，依赖语境的判断仍需人。
- 经批准的目录回答“有什么”，运行身份回答“谁授权这次动作”，二者不能混同。
- 示例只给六个离职工具，不给删除账号能力，并检查邮箱转换及许可变更的前置动作。
证明的范围小于可信的口号
AWS 区分“仅经理可批准访问”这类精确规则与“语气友好”这类语境要求。形式化推理可以在系统描述和假设下证明规则，或找出反例，却不能让不完整政策自动覆盖所有业务顾虑。作者因此保留人的模糊判断，并结合限制、评估与恢复。本站认为，审计应记录究竟证明哪个属性、覆盖哪些行为、哪些仍未建模。测试覆盖预想到的案例，形式化检查可在其领域走得更远；两者都不支持“自主工作流在任何现实情形必然安全”的泛化结论。
范围与身份先建立授权边界
范围定义包括任务、所需工具和数据、禁止动作、保留给人的决策。原文警告，成套角色可能意外附带超出任务的权限，并介绍规格、属性测试、政策分析如何在执行前发现缺口或矛盾。Know 层又区分经批准的 Agent、工具、技能目录与每个 Agent 的运行身份：前者帮助治理发现和复用，后者让请求归属于明确授权者。本站分析是，可被发现不等于有权调用，熟悉的工具名称也不证明每次调用都带着正确权限。
外部执行控制还要检查动作次序
Bound 将确定性检查放在 Agent 外，而非仅靠内部指令。AWS 描述对经过 AgentCore Gateway 的工具调用执行政策、根据会话历史约束顺序，并用沙箱限制文件、服务及凭据访问。护栏主要检查输入输出，与某工具动作是否获准并非一件事。“经过网关”这个条件不能省略，文章没有证明所有旁路天然受控。允许的单步也可能组合成不希望的结果，因此应检查整个序列。我们建议同时测试直接、间接路径、拒绝动作及前置条件，也检查限制过严而无法完成合法任务的情况。
邮箱示例重点是保留前置条件
文中离职案例要求先封锁员工登录，再转换并共享邮箱；更改许可前先确认是否有法律保全要求，并确保记录保留。Agent 得到六个工具：封锁登录、检查保全、设置保全、转换邮箱、授权继任者、更改许可。共享邮箱仍依赖原账号，因此不给删除账号工具。提前转换邮箱被拦，未查保全就改许可也被拦，随后 Agent 补齐前置步骤。这是政策推演示例，不是测得的生产成功率，不证明所有邮件系统都如此，更不是本站已经执行的账号变更。
可观察证据让自主性可复核
Observe 保留上下文、工具调用、政策决定及结果，让运维可重建运行过程，并将失败纳入后续评估。文章将此与追踪和评估器关联，没有把基础设施全绿等同任务成功。本站结论是逐步扩大自主权：先选一个流程，定义真实可检查的边界，同时验证允许和拒绝路径，保留干预所需证据。它与“是否完成正确目标”的持续质量评估互补。单独一层都不足以解释完整授权、正确性和恢复；证据不再支持时，也应收紧职责。
有什么影响
架构上应分清 Agent 选择怎样完成任务，以及环境是否允许这条路径。审查需要分别看身份、政策覆盖、次序和证据，不能把强提示词或精彩演示当作完整治理。
限制与可用性
本站完整阅读官方文章，未部署控制、运行形式化验证或更改任何用户账号。场景与产品能力均来自 AWS 描述，证明依赖建模假设，不构成通用安全保证、新模型发布、消费级订阅权益或价格。
来源与证据
原文发布: 2026年10月15日 · 核实时间: 2026年10月20日
AI 辅助采编，依据所列一手来源核实。厂商自报结论注明归属，收录不代表背书。