AWS Trust in Depth 赋予 AI Agents 更大自主权，同时不交出控制权

AWS 于 2026 年 10 月 15 日推出 Trust in Depth，认为企业在扩大 AI Agents 的自主权之前，需要建立五层相互强化的控制机制。冲突显而易见：企业希望 Agent 能够独立完成有价值的工作，但一次错误操作就可能泄露数据、更改访问权限，或扰乱财务流程。AWS Trust in Depth 的目标，是以组织可验证的自主权取代持续不断的人工审批。

这一观点挑战了企业部署 Agent 时的默认妥协方案。让人工参与每一个环节看似安全，但随着工作负载增加，审批会不断累积。审核人员会成为瓶颈，而重复的低风险决策也会造成疲劳。彻底移除人工则带来相反的问题，因为模型可能选择意料之外的工具、步骤和中间操作。

AWS 提出了第三条路径。Agent 可以自行决定如何完成已获批准的工作，但其实际可执行的操作会受到身份、权限、策略、追踪记录、评估和形式化检查的约束。这并不是声称 AI Agents 已变得始终可信，而是一项让自主权以证据为前提的方案，并将人保留在处理模糊情况和重大判断的环节。

AWS Trust in Depth 将自主权转化为证据问题

AWS 正将 Agent 信任重新定义为一项必须在 Agent 生命周期多个节点获得支持的工程主张。

在其 Trust in Depth 公告中，AWS 围绕五个概念组织这一生命周期：scope、know、bound、observe 和 prove。每一个概念都回答了关于自主系统的不同问题。

Scope 在 Agent 运行前定义其职责。团队需要确定完成该职责所需的工具、服务和数据，同时决定哪些操作仍被禁止，以及哪些决策必须由人工完成。

Know 涉及部署时的身份和权限。每个 Agent 都应拥有独立身份，每项操作都应能够追溯至该身份。组织还必须知道是谁授权 Agent 采取行动。

Bound 涉及执行期间的强制控制。Agent 可以选择达成目标的路径，但模型之外的基础设施会评估其尝试执行的操作。这些控制措施决定每项工具请求是否符合既定策略。

Observe 关注运行期间及运行后发生的情况。运营人员需要的不只是运行时间、延迟和错误率。他们必须能够重建模型上下文、工具选择、策略决策、输出以及最终结果。

Prove 适用于能够被精确定义的要求。自动推理利用数学逻辑测试某项规则是否在系统模型描述的每条路径上都成立，也可以生成反例，显示规则在哪些地方失效。

这些层级针对不同的失效模式。注册表无法阻止已获授权的 Agent 滥用工具。内容过滤器无法判断账户是否在邮箱被转移前已被禁用。追踪记录可以解释不良结果，却无法单独阻止该结果发生。

因此，AWS 将信任视为多项控制措施的组合，而非单次模型评估得出的分数。这一方法借鉴了纵深防御的逻辑：当某一项控制失效时，多重保障能够限制损害。Trust in Depth 将目标从遏制攻击转变为允许更多经过验证的活动。

这一差异十分重要，因为 Agent 的行为比传统工作流自动化更难预测。传统软件通常遵循开发人员明确编码的路径。Agent 则会根据不断变化的上下文解释目标、选择工具并排列操作顺序。

两次运行可能通过不同路径达到相同结果。一次成功测试仅覆盖实际发生的路径，而非 Agent 日后可能选择的所有路径。这限制了常规测试对未来行为能够证明的内容。

AWS 并未声称形式化证明适用于所有业务要求。例如，只有经理可以批准访问权限这一规则可以被精确定义；而妥善处理敏感员工情况的要求则难以如此简化。

该框架将这些类别区分开来，而非假装单项控制就能同时覆盖两者。机器可以执行精确规则。评估可以衡量允许一定变化的行为。人可以决定真正模糊的情况。

这是 AWS Agent 安全论述中的第一个重要变化。人工参与将基于风险，而非普遍适用。只有在边界、执行机制和证据足以支持时，自主权才会扩大。

人工审批队列正成为企业自身的风险

核心竞争已不再是自主 Agent 与人工控制之间的较量，而是全面审批与可验证自主权之间的选择。

在试点阶段，由人工批准每一项操作可以缓解即时焦虑。但当 Agent 需要处理数百个常规步骤时，这种安排便越来越难以辩护。即使大多数决策风险很低，审核量也会随着使用量增加而上升。

AWS 认为，这会导致审核疲劳。被要求批准重复操作的人，最终会对每项请求投入更少注意力。控制措施在纸面上依然存在，但其发现重大问题的能力会下降。

同样的模式已出现在其他安全系统中。过量警报会训练用户清空队列，而非调查异常。若每次工具调用都获得同等处理，Agent 审批工作流也可能重现这一弱点。

全面审批还会将不同风险压缩为一个二元问题。读取公开文档与更改员工访问权限并不等同。起草回复与发送回复并不等同。查询发票与发放退款也并不等同。

更站得住脚的设计会根据后果分配控制措施。Agent 可以不受打断地检索已批准的信息。更改记录前，它可能需要经过确定性的策略检查。超出既定边界的付款仍可要求获得明确的人工授权。

这一设计给企业内部多个群体带来压力。安全团队必须将宽泛原则转化为可执行规则。平台团队必须在多个 Agent 框架中提供身份、策略和追踪能力。业务负责人则必须决定哪些结果仍然过于模糊或影响重大，因而不能委派。

开发人员也无法再把系统提示词当作安全边界。指令可以引导模型行为，但 Agent 仍会对其作出解释。提示注入、模型错误或意料之外的上下文组合，都可能改变这种解释。

AWS 转而将执行机制置于 Agent 周围。AgentCore policy controls 会在工具访问获准前，评估通过 AgentCore Gateway 传递的请求。策略引擎与选择操作的模型相互独立。

这种分离创造了一项有用的安全属性。被操纵的 Agent 无法自行决定某项控制不再适用，因为它并不拥有允许或拒绝工具调用的机制。

模型仍有规划空间。它可以在允许的工具之间进行选择，从被拒绝的请求中恢复，并寻求另一套有效的操作顺序。周边环境则保留对进入真实系统操作的权威。

这一平衡对于在多个部门构建 Agent 的企业尤其相关。一个团队可能创建客户支持 Agent，另一个团队可能构建采购助手。第三个团队则可能部署拥有生产环境访问权限的编程 Agent。

如果缺乏共享治理，每个团队都会自行制定身份规则、审批逻辑和审计格式。这种碎片化使得组织难以了解存在哪些 Agent，或是谁授权它们。它也使一致的事件调查几乎不可能实现。

AWS Agent Registry 旨在通过编录 Agent、工具、技能和 Model Context Protocol 服务器来解决资产清单问题。Model Context Protocol，即 MCP，是一种让 Agent 连接外部能力的标准接口。管理员可以治理哪些组件可被发现。

仅靠注册表仍无法建立可信执行。它能够显示哪些内容已获批准，但运行时身份必须将每项操作关联到特定 Agent。随后，策略执行机制必须决定该 Agent 是否有权执行所请求的操作。

正是在这里，AWS Trust in Depth 不再只是安全产品名称的集合。这些层级构成了一条问责链。Scope 确立预期权限，身份赋予权限，策略限制权限，追踪记录则保存其使用证据。

该框架也改变了企业买方应向 Agent 供应商提出的问题。准确率基准仍然有用，但无法回答运营层面的问题。买方需要了解 Agent 是否拥有独立身份、策略是否位于模型推理之外，以及工具调用序列是否能够被重建。

他们还应询问控制措施是否能跨越集成渠道传递。一个 Agent 在某个环境中看似受到约束，却可能通过治理较弱的路径访问外部工具。最薄弱的连接可能破坏更大的策略设计。

因此，可验证的自主权需要演示通常不会呈现的架构工作。模型可见的回复只是最后一步。身份、授权、工具中介和证据决定了系统是否配得上更大的运营自由度。

外部策略让 Agent 选择路径，但不能自行决定边界

这一核心机制让 Agent 在规划上拥有自由，同时不赋予其决定执行规则的权力。

AWS 以员工离职场景说明这一机制。经理要求服务台 Agent 移除员工访问权限、转移邮箱，并释放不再需要的软件许可证。表面看似简单的任务，实际上包含安全、法律、运营和财务方面的依赖关系。

操作顺序至关重要。员工的登录权限必须在邮箱被转换和共享前被阻止，否则现有凭据仍可能打开转换后的邮箱。

Agent 还必须检查该邮箱是否受到法律保全。法律保全要求组织为诉讼或其他正式争议保留相关记录。若在未保护这些记录的情况下更改许可证，可能会销毁证据或违反保留义务。

AWS 为示例 Agent 精确提供了六种工具：阻止登录、检查法律保全、设置保全、转换邮箱、授予继任者访问权限，以及更改许可证。它没有获得账户删除工具，因为删除与保全要求相冲突。

这是 Scope 的具体体现。该设计在执行开始前便移除了不必要的高风险能力，而不是依赖提示词要求 Agent 避免删除操作。

运行时策略随后会强制执行所需顺序。若 Agent 在阻止登录前尝试转换邮箱，Gateway 会拒绝该调用。Agent 可以修正操作顺序并继续执行，而无需请求人工批准。

同样的情况也会发生在代理尝试在检查法律保全之前更改许可证时。网关会阻止该操作，直到前置条件已满足。如果存在保全，代理必须先执行并验证保全，然后才能继续。

这一示例说明，单次请求权限不足以覆盖某些代理工作流。每项操作单独看或许都被允许，但风险会在其执行顺序、累积上下文或组合效应中显现。

AWS 通过时序策略应对这一问题。这些规则会在评估当前请求时，考虑同一会话中的早先事件。它们可以要求先获得批准、施加会话总量限制，或在访问敏感数据后阻止某项操作。

这些策略使用 Dogwood，一种兼容 Cedar、具备会话感知能力的语言。Cedar 表达涉及主体、操作、资源及相关条件的授权决策。Dogwood 在这一模型基础上扩展了基于会话历史的条件。

文档描述了默认拒绝的行为。只有适用许可时请求才会继续，而匹配的禁止规则会覆盖许可。这种结构减少了对代理能否正确理解“缺少规则”这一情况的依赖。

时序执行也带来了实际的运营约束。策略历史限定在单个会话中，且由调用方提供会话标识符。启动新会话会重置会话专属历史，因此按会话设置的限制并不是覆盖整个组织的支出控制措施。

AWS 还表示，时序传播不会跨越 AWS 账户或区域。AgentCore 之外的组件必须正确转发相关工作负载令牌。这些限制很重要，因为现实中的企业工作流往往跨越账户、供应商和部署边界。

策略只能约束其实际能够看到的流量。如果代理还有另一条通往同一服务的路径，网关就只是部分边界。团队必须盘点每一项凭证和连接，而不能假设一个策略引擎治理了整个工作流。

精确性要求带来了另一项挑战。“不得泄露机密数据”对人而言似乎很清楚，但仍留下许多技术问题。团队必须定义哪些数据属于机密、哪些目的地算作外部，以及哪些转换仍被禁止。

自然语言策略编写可以帮助将意图转化为正式策略，但并不能免除审查假设的需要。即使一条不完整的规则被完美执行，它仍会允许其编写者忘记描述的行为。

这正是自动化推理发挥价值的地方。普通测试会抽样检查选定案例。形式化分析则评估系统表示，并寻找矛盾、不可达规则、非预期访问，或违反既定属性的路径。

AWS 已将自动化推理应用于基础设施服务超过十年。该公司称，IAM 每秒评估超过 21 亿个请求；形式化方法也支持包括 S3 Block Public Access 和 VPC Reachability Analyzer 在内的系统。

这一记录为 AWS 将类似方法扩展到代理领域提供了可信基础。不过，证明仍受限于所提供的模型、策略和假设。它并不能证明一个含糊的业务目标是明智或完整的。

这种区别很容易在营销语言中被淡化。形式化验证可以证明每一条建模路径都符合精确要求，但它不能证明该要求涵盖了所有法律、伦理或组织层面的关切。

对企业而言，实际启示是缩小每项证明声明的范围。不要问代理是否安全，而应问它能否在未获得必要授权时调用支付工具。还应问它在访问受保护记录后，能否向外部发送数据。

这些问题会产生可测试的安全属性，也为人工审查划定更清晰的边界。人可以专注于策略意图和例外决策，机器则执行那些能够适用精确规则的部分。

可观测性仍无法证明代理选择了正确目标

AWS 代理安全能够约束并重建操作，但无法消除目标本身的模糊性。

即使受到良好约束的代理，仍可能做出糟糕决定。它可能检索过时信息、选择错误但获准的工具、误读请求，或优化了错误的结果。这些失败未必会触发基础设施错误。

这揭示了系统健康与任务成功之间的鸿沟。一次运行可以快速完成，所有服务均可用，每次工具调用也都获得授权，但结果仍可能错误或有害。

AWS 将这一问题归入观察与评估。CloudWatch Omni 会记录模型调用、工具调用、策略决策和结果的追踪信息。评估器随后可以评估正确性、忠实性和工具选择等质量。

当团队能够将追踪信息与周边业务记录关联起来时，追踪最有价值。策略、需求、事故决策和此前的失败需要共享的证据链。可搜索的知识库可以帮助团队保留这些上下文，而不将原始追踪信息视为不言自明的结论。

生产追踪也会成为回归材料。当代理采取意外路径时，开发者可以将该路径加入未来评估。随后，团队会测试修订后的提示词、工具定义或策略是否解决了已观察到的失败。

这在运行与开发之间形成反馈循环。部署产生证据，证据改变评估与控制，更新后的控制随后又面临新的生产条件。

这个循环很有价值，但它是被动的。组织仍必须决定自己能够多快发现有害结果，以及能否逆转它们。一次不可逆转账后的追踪记录，并不能收回资金。

因此，可逆性应影响自主程度。低影响、可逆的操作可以获得更大的操作空间。不可逆或对外具有约束力的操作则应获得更窄的权限、更强的前置条件或人工确认。

独立框架强化了这一生命周期视角。AI RMF Core围绕治理、映射、衡量和管理来组织风险工作。NIST 将治理描述为一项贯穿各环节的职能，而不是最终的合规检查。

Trust in Depth 符合这一总体模式，但 AWS 提供了一条供应商特定的实施路径。这既带来优势，也形成依赖。企业可以在一个云环境中组装注册表、身份、网关、策略、护栏和追踪。

当代理跨云或跨外部软件运行时，这种依赖就会成为问题。AWS 表示，底层问题应适用于任何平台。不过，一些执行细节依赖于 AgentCore 网关、AWS 身份和 CloudWatch 遥测。

组织应将框架与其实施分开。范围、身份、外部执行、观察和证明是可移植的原则。为实现这些原则所使用的具体产品，会因企业而异。

互操作性将成为严峻考验。代理可能在一个运行时中启动，调用由另一团队运营的 MCP server，然后再调用第三方应用程序。在这些边界之间保留身份和策略上下文，比治理一个封闭演示环境更困难。

还存在衡量问题。评估器可以给出分数，但这些分数依赖于数据集、评分标准和基于模型的判断。高忠实性分数并不必然代表法律合规或可接受的客户结果。

企业应记录每项指标能够证明什么，以及哪些问题仍未回答。它们应避免把无关的衡量指标合并成单一的“信任分数”。这样的数字可能掩盖真正失效的具体控制措施。

人工判断仍然不可或缺，因为许多目标包含相互冲突的价值取向。客服代理可能需要在速度、同理心、欺诈防范和合同义务之间取得平衡。没有任何通用策略能在每一次对话中确定正确平衡。

AWS 通过将人工决策保留给真正存在模糊性的情况来承认这一限制。这一边界对于该方法的可信度至关重要。如果 Trust in Depth 将每项组织期望都视为可被形式化证明，它就会越界。

更困难的问题是，团队能否在压力下保持这种克制。一旦代理成功处理日常工作，管理者就会希望扩大其权限。降低成本可能成为比累积证据更强的激励因素。

因此，治理必须定义自主性如何扩大，以及如何收缩。团队需要可衡量的准入标准、事件阈值、回滚程序和明确的责任人。当证据发生变化时，信任应当可以撤销。

“人在回路中”这一表述对这项工作而言过于宽泛。企业需要明确是哪一位人员、在哪个决策点、依据什么证据、在什么截止期限内介入。否则，升级机制只会重新制造 AWS 希望避免的同一审批队列。

最可信的实施将采用多种干预模式。一些操作将保持自动化，另一些则需要预先批准、事后审查、抽样，或仅在发生策略例外后升级。

只有当这些区别能经受真实运营的考验，Trust in Depth 才会成功。其价值在于分配注意力，而非消除监督。人应审查那些上下文判断会改变结果的情形。

三个信号将显示 AWS Trust in Depth 能否超越框架本身

接下来的考验在于，企业能否将 AWS Trust in Depth 从一套有说服力的架构转化为可衡量的运营实践。

第一个信号是时序感知策略在生产环境中的采用。企业需要的不只是决定代理能否访问某个工具的静态权限，还需要证据表明，时序控制能够治理涉及批准、敏感数据和累积限额的多步骤工作流。

具体的采用将强化 AWS 的论点：代理能够在无需持续人工审查的情况下获得更大自主性。若只在受控演示中有限使用，则表明策略建模对日常运营而言仍然过于复杂。

买方应关注哪些工作流类别最先出现。员工访问、软件部署、理赔处理和支付运营都包含明确的前置条件。它们是合适的测试对象，因为团队至少可以精确定义其中一部分规则。

离职流程示例设定了清晰标准。已部署的系统应拒绝乱序操作，解释相关策略决策，并允许代理通过有效顺序恢复执行。它还应保留证据，以便审计人员日后重建过程。

第二个信号是跨平台身份与策略连续性。现实中的代理很少停留在单一服务边界内。它们会访问数据库、SaaS 应用、内部 API、云资源和 MCP servers。

AWS 记录了时序策略传播的账户和区域边界。第三方组件也可能需要自定义逻辑来转发身份上下文。这些限制并不会否定该方法，但揭示了执行可能碎片化的环节。

若能支持在这些转换过程中保持一致的控制，将强化 Trust in Depth 的论点。若持续依赖紧密耦合的 AWS 路径，则会削弱其作为通用企业模型的主张。

组织应审视上下文在各个环节之间丢失时会发生什么。接收系统会拒绝请求、降低权限，还是在没有会话历史的情况下继续执行？任何“默认放行”的转换都会削弱此前的控制措施。

他们还应要求提供代理级审计追踪，而不是使用一个共享的应用身份。如果多个代理共用同一凭证，调查人员或许能知道是哪个服务执行了操作，却无法确定是哪个自主进程发起了该操作。

第三个信号在于，客户是否发布结果证据，而非部署数量。真正有用的指标包括：被拒绝的不安全操作、调查耗时、升级处置质量、任务成功率，以及从政策违规中恢复的能力。

注册代理数量不断增加，并不能说明自主性值得信赖。一项有意义的案例研究应展示：哪些权限得到了扩展、哪些控制措施支撑了这种变化，以及组织如何衡量失败情况。

证据既应包括被阻止的操作，也应包括误拒绝。阻碍正当工作的政策可能迫使团队绕过限制，或寻求更宽泛的权限。过度限制可能让代理在技术上安全，却在运营中毫无用处。

客户还应报告模糊决策仍需交由人工处理的频率。只有当任务质量和事件严重程度仍处于可接受范围时，审查率下降才有意义。若在未衡量结果的情况下取消审批，只会以更不易察觉的方式重现原有风险。

这些信号将决定 AWS 代理安全能否成为一种持久的运营模式。该框架的核心主张是合理的：自主性应建立在验证之上，而非热情之上。其落地需要严谨的范围界定、明确的授权、外部执行机制、可观测的执行过程，以及有限且可验证的证明声明。

企业领导者应从一个具有实际影响的工作流开始，而不是部署通用型代理。明确哪些操作可以撤销、哪些边界可以形式化，以及哪些决策仍需要判断。随后衡量代理尝试了什么、政策阻止了什么，以及哪些问题必须由人工解决。

最后的问题很实际：在你当前的工作流中，哪一项决策虽然其约束规则已足够精确，却依然消耗人工注意力？这正是 AWS Trust in Depth 最适合的候选场景。谨慎地自动化这条边界，保留证据，只有当结果证明值得迈出下一步时，再扩大自主性。