AWS 提出 Trust in Depth：让智能体获得更多自主权而不失控

在我与企业领导者的每一次交流中，他们说的都是同一件事。他们希望智能体承担更多工作，却不相信它们每次都能做对。

这很合理。让智能体变得有用的那种创造力和自主性，恰恰也让它们难以被信任。给智能体一个任务，它会自己找到完成路径，自行挑选工具、安排步骤，这些都不是开发者预先编写的。同一个任务运行两次，它可能每次走的路线都不同。今天能通过的测试，几乎说明不了智能体明天会做什么。

通常的答案是让人留在环路中，批准智能体所做的一切。这在规模较小时可行，但随着智能体承担更多工作，人工审批会不断堆积，审查疲劳随之而来。被要求检查一切的人，反而会漏掉真正重要的问题。谨慎变成了瓶颈，而能力远不止于此的智能体，却闲置在那些本可产生更大影响的有价值工作上。

解决办法是：当智能体的行为可以被验证时，就让它自主行动；把人类判断留给真正需要它的决策。随着智能体承担更高风险的工作，比如金融交易，一次错误行为会变得越来越有害。组织需要信心，才能把重要工作交给 AI 智能体，并确信即使无人监督，它也会保持在设定的限制之内。这种信心必须被建立起来。

内容过滤、测试和监控各有其重要作用，但单靠其中任何一项能力，都无法保证智能体在下一次运行时行为正确。信任来自相互强化的独立层次，这正是行业二十年来一直实践的纵深防御（Defense in Depth）纪律，如今被用于新的目的。纵深防御限制的是可能出错的范围，而这一新方法扩展的是你可以安全允许的范围。AWS 称之为 Trust in Depth。

Trust in Depth：可验证的信任

你通过在智能体生命周期的不同时刻回答一系列问题来建立信任：

• 范围，在它运行之前：这个智能体是做什么的，这项工作需要哪些能力，它绝不能做什么？
• 知晓，在部署之时：谁授权了它，它携带什么身份，你能否交代清楚每一个代表你行动的智能体？
• 约束，在它运行期间：它的行为是否保持在你设定的限制之内，同时它还能完成工作吗？
• 观察，在每次运行之后：你能否重建智能体做了什么、为什么这么做，并从中学习？

在这些问题中，有些要求可以表达为精确规则，另一些则需要判断。公司可能要求只有经理才能批准访问权限，或者员工的登录必须先被阻止，其邮箱才能被共享。其他期望，比如保持友好的语气或妥善处理敏感情况，则取决于上下文和人类判断。

对于精确定义的规则，测试能显示控制措施在你预期的情况下是否有效，但智能体会走你未曾预料的路径。更进一步的技术是自动推理，即用数学逻辑检查某条规则在所有可能情况下是否都成立。它可以证明某条规则在系统及其假设的精确描述所覆盖的每条路径上都成立，或者找出它失败的确切情形。这个结果是一个证明，而它的可靠性取决于背后的规则和假设，这就是为什么最艰难的工作发生在智能体运行之前。

AWS 已在生产环境中运行自动化推理超过十年，从每秒超过 21 亿次请求的 Identity and Access Management (IAM)，到 AWS Nitro Hypervisor、Amazon S3 Block Public Access 和 VPC Reachability Analyzer 等关键系统。现在我们正把它引入智能体。只要智能体的规则能够被精确表述，自动化推理就能对其进行检查。

然而，并非每条规则都能被精确表述。“只有经理才能批准访问”可以被证明。“保持友好的语气”则不能。在证明不适用之处，限制智能体的访问权限和操作，评估其行为，并将真正的模糊之处交由人来判断。随着你确认相关规则得到执行、智能体在任务上表现可靠、且故障能够被检测和处理，再授予其更多自主权。

以下是 Trust in Depth 的每一层对你的要求，以及 AWS 如何帮助你满足这些要求。

将智能体的范围限定为仅满足工作所需

信任在智能体运行之前就已开始，而这正是最值得投入精力的地方。在此阶段发现的问题修复成本很低。限定范围意味着决定智能体负责哪些工作、它可以访问哪些工具、数据和服务、它必须遵循哪些规则，以及哪些决策仍由人来做。

“解决客户的问题”说明的是要实现什么，而不是智能体可以如何行动来实现它。智能体仍然需要在其可见内容、可执行操作以及何时必须停下并询问方面受到限制。只授予其工作所需的访问权限，不多给。留意那些无人有意授予的能力，即随工具或角色捆绑而来的能力。为一个任务授予管理员角色，智能体就可能继承你整个环境中的权限。

限定范围始于构建阶段，始于你如何定义智能体。智能体编码系统 Kiro 将严谨性和成熟的工程实践带入智能体的构建阶段。它把高层意图转化为结构化、由规范驱动的需求，并在编写任何代码之前使用自动化推理来揭示矛盾、模糊之处和缺口。Kiro 还会派生基于属性的测试，在广泛的输入范围内对照这些需求检查实现，从而捕获难以发现的缺陷。Strands 提供开源工具包，用于定义智能体的模型、指令和工具，并提供用于运行它的托管运行时。无论你选择哪种框架，定义智能体工作及其边界的责任都是一样的。

下一步是将这些边界转化为你可以要求智能体遵守的规则。Amazon Bedrock AgentCore 提供治理控制，以安全地扩展智能体并治理智能体的行为。使用 Bedrock AgentCore 中的 Policies，你可以用自然语言描述智能体可以访问哪些工具、API 和数据，自动化推理会在策略生效前检查其中的缺口，例如发现授予过多访问权限的规则，并检查导致规则永远无法被满足的矛盾。

限定智能体的范围是困难的部分，因为将人类意图转化为持久、可执行的策略需要精确性和完整性。然而，这也是回报最大的部分。一切都在此基础上构建，而且策略越精确，你的智能体就能越安全地自主行动。

了解每一个代表你行动的智能体，以及它们是在谁的授权下行动

你无法治理你看不见的东西。团队创建智能体的速度超过了任何人追踪它们的速度，而一个无人知晓的智能体就是一个无人控制的智能体。每个智能体都需要有自己的身份，并在每次行动时接受核验。任何行动都不应成为无主之举。当出现问题时，你能分辨出哪个智能体做了什么，以及是谁授权的。

AWS Agent Registry 提供了一份受管理的、经批准的目录，涵盖你组织内的智能体、Model Context Protocol (MCP) 服务器、工具和技能。管理员通过审批工作流来控制哪些内容可被发现，并移除不再符合安全、合规和质量标准的内容。人和智能体都能找到并复用已有的内容，而不必重新构建。但目录只能告诉你存在什么。一旦智能体被知晓，AgentCore 就会为每个智能体颁发自己的身份，并在每次请求时进行核验，因此每个行动都能追溯到在已知授权下运行的特定智能体。这样你就能知道每个代表你行动的智能体。

在你设定的限度内，约束智能体的言行

设定边界很重要，因为一个智能体可能采取 10 个你已批准的步骤，却仍然达到无人预期的结果。它可能泄露敏感数据、偏离主题，或以你的策略禁止的方式组合被允许的操作。限制可能朝两个方向失效。太宽松，智能体就能做它不该做的事。太严格，它根本无法完成工作。因此，让智能体自行选择如何推进任务，但绝不要依赖它来执行自身的限制。这些限制定义了智能体的边界，应归属于智能体周围的环境，以确定性方式强制执行，并针对完整的行动序列进行评估，而不是一次只评估一步。

这就是你在 Scope 中定义的策略发挥作用的地方。AgentCore 中的 Policy 会对通过 AgentCore Gateway（智能体、工具和模型的安全入口）路由的每次工具调用强制执行该策略。由于强制执行位于智能体的推理之外，即使智能体存在缺陷、被操纵或遭受提示注入，同样的检查依然有效：它无法关闭一个不由它运行的控制。授权也不必一成不变。由于任务的风险会随着推进而变化，时序策略会权衡会话中已经发生的情况，并随着工作继续调整权限。Amazon Bedrock Guardrails 管控智能体说什么以及被告知什么。它会过滤有害或偏离主题的内容，并对敏感数据进行脱敏。自动推理检查更进一步，证明响应与你设定的策略一致，而不是与模型对策略的解读一致。

边界还管控智能体最初能触及什么：它能触碰哪些文件、能调用哪些服务、能使用哪些凭证。Strands Box 是一个开源沙箱，它从智能体指令之外强制执行这些边界，因此智能体可以使用真实的工具和数据，但只能触及你允许的范围。从开发者的首次本地会话到生产环境，同样的边界始终有效，因此智能体在生产环境中无法做它在开发环境中做不到的事。

观察你的智能体做了什么，然后改进它

即便有了范围界定、身份和边界，智能体仍可能在毫秒内做出响应，没有报错，所有仪表盘一片绿色，却依然做错了事。它可能检索到了错误的信息，选择了错误的工具，或者走上了一条没人预料到的路径。系统健康并不等同于任务成功。要区分二者，你必须重建智能体实际做了什么：它接收到的上下文、它调用的工具、所应用的政策决策，以及最终结果。部署前测试依然至关重要。生产环境则补充了关于真实条件下行为表现的证据，并让运维人员获得调查、干预和改进所需的信息。

Amazon CloudWatch Omni 专为持续观测而构建。它捕获每一条追踪记录，并在团队可调查的时间线上展示智能体所采取的每一步，从模型调用到工具调用。其内置评估器会针对标准监控所遗漏的质量对智能体响应进行评分，例如正确性、忠实度，以及智能体是否选对了工具。而智能体出错的那些追踪记录，会成为你用来验证修复方案的数据集，因此运行智能体和改进智能体依托的是同一份证据。

Trust in Depth 在实践中的样子

一位经理要求服务台智能体为即将离职的客户经理 Sam 办理离职手续。智能体需要移除 Sam 的访问权限，将他的邮箱转移给继任者，并释放公司不再需要的许可证。但 Sam 的邮件中可能还包含客户纠纷所需的证据。错误的操作顺序可能导致 Sam 离职后仍保有访问权限，或使这些证据面临风险。安全、消息、法务和财务部门各有智能体必须遵循的要求，尽管没有人把完整的工作流编写成脚本。

有两条规则约束操作顺序。必须先阻止 Sam 登录，然后才能转换他的邮箱并与继任者共享。在更改他的电子邮件许可证之前，智能体必须检查是否存在法律保留（即为纠纷保留记录的要求），并确认更改后这些记录仍受到保护。

范围。在智能体运行之前，团队将这些规则编写为 AgentCore 中的策略。每条策略都要求，针对 Sam 账户的前置步骤已经成功，下一步才能运行。智能体恰好获得六个工具：阻止登录、检查法律保留、实施保留、转换邮箱、授予继任者访问权限、更改许可证。它没有删除账户的工具，因为共享邮箱需要该账户继续存在。

知晓。智能体携带自己的身份，因此对 Sam 账户的每一次更改都能追溯回它。

边界。智能体试图将 Sam 的邮箱转换为供继任者 Priya 使用的共享邮箱。AgentCore 中在 AgentCore Gateway 处强制执行的政策阻止了该调用：Sam 仍能登录，而转换邮箱不会更改他的密码，因此他的旧凭据仍能打开邮箱。智能体阻止了 Sam 的登录，然后转换邮箱并授予 Priya 访问权限。接下来它转向经理的实际请求，即释放许可证，但网关也阻止了该操作，因为还没有人检查法务的保留清单。智能体进行检查，发现法务要求为一起客户纠纷保留 Sam 的邮件。它实施保留，确认保留已生效，然后将 Sam 的许可证更改为支持该保护的许可证。公司可以收回范围更广的许可证，同时保持证据完好无损。

观察。每一步都被记录：智能体尝试做什么、规则如何判定、暂停以及最终结果。

智能体在无需人工逐步批准的情况下完成了任务。其权限限制了它可以更改的内容，其身份使这些更改可追溯，策略阻止它在所需保障措施到位之前采取行动。记录下来的步骤让团队能够验证 Sam 的访问已被阻止、他的继任者可以使用该邮箱，并且所需的证据始终受到保护。

当智能体获得信任时，什么将成为可能

AWS 将这些层面整合在一起，使你可以将智能体的范围限定在其职责之内，知道哪些智能体在代表你行动，约束它们的言行，查看它们做了什么并持续改进，并在任何可以精确表述规则的地方证明你的规则成立。没有任何单一层面能独自赢得这种信任。它们共同构成了 Trust in Depth，正是它们将一个能力出众的智能体转变为可以被信任去承担重要工作的智能体。

由你划定界限：智能体可以自行做什么、什么需要人工批准，以及何时必须停止。这让你的人员得以专注于只有人才能做的事：权衡艰难的抉择、解决灰色地带，并对你选择保留在人类手中的决策负责。随着证据不断积累，表明智能体始终守在这些界限之内，你可以扩大或收窄它的职责。

在 AWS，我们相信每一个部署智能体的组织，无论使用何种平台，都应该能够用证据来回答这四个问题，并在适用之处提供证明。这就是 AWS 正在为客户树立的标准，也是我们邀请整个行业共同遵循的标准。Defense in Depth 让系统安全地连接世界成为可能。Trust in Depth 则让智能体在其中自主行动变得安全。

从一个智能体、一个工作流和一条你能证明的边界开始。然后随着信任的建立逐步扩展。

要开始实施可强制执行的规则，请探索 Amazon Bedrock AgentCore 中的 Policy 和 Amazon Bedrock Guardrails 中的 Automated Reasoning 检查。

关于作者

Shawn Bice

Shawn 是 Amazon Web Services（AWS）AI Services 的副总裁，领导 Automated Reasoning Group。该团队的核心使命是推进 AI 智能体的安全性。Shawn 推动科学与产品团队将神经符号 AI（结合大语言模型与形式化验证）引入开发者工具，使每位构建者都能创建可信的 AI 智能体，其关键行为经过数学证明。近 30 年来，Shawn 在 AWS、Microsoft 和 Splunk 领导安全、数据和产品组织。他的职业生涯始于美国陆军第 25 步兵师的一名军官。