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

在我与企业领导人的每一次对话中，他们都会说同样的话。他们希望智能体做更多的事，但并不信任它们每次都能做对。

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

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

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

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

纵深信任：可验证的信任

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

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

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

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

AWS 已在生产环境中运行自动化推理超过十年，从每秒超过 21 亿次请求的身份与访问管理（IAM），到 AWS Nitro Hypervisor、Amazon S3 Block Public Access 和 VPC Reachability Analyzer 等关键系统。现在我们将其引入代理。只要代理的规则能够被精确表述，自动化推理就能对其进行检查。

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

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

将你的代理范围限定为仅满足工作所需

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

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

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

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

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

了解每一个代表你行事的代理，以及它们是在谁的授权下行事

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

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

在你设定的限制内，约束你的智能体说什么和做什么

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

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

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

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

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

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

Trust in Depth 在实践中的样子

一位经理让服务台智能体为 Sam 办理离职，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 正在为客户树立的标准，也是我们邀请整个行业共同坚守的标准。纵深防御让系统安全地连接世界成为可能。纵深信任则让智能体在其中自主行动变得安全。

从一个智能体、一个工作流、一条你能证明的边界开始。然后随着信任的赢得而扩展。

要开始实施可强制执行的规则，请探索 Amazon Bedrock AgentCore 中的策略 和 Amazon Bedrock Guardrails 中的自动推理检查。

关于作者

Shawn Bice

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