Trust in Depth：让 Agent 获得更多自主权而不失去控制

在我与企业领导者进行的每一次交流中，他们都表达了同一件事：他们希望 Agent 承担更多工作，但并不完全相信它们每次都能正确完成。

这很合理。正是让 Agent 有用的创造性和自主性，也让它们难以被信任。给 Agent 一项任务后，它会自行寻找完成路径，选择工具并安排步骤顺序，而这些并非开发者预先编写。即使同一项任务运行两次，它每次也可能采取不同的路线。今天通过的一项测试，几乎无法说明 Agent 明天会做什么。

通常的解决办法是让人类参与其中，批准 Agent 的每一项操作。这在小规模场景下有效，但随着 Agent 承担更多工作，人工审批会不断累积，审查疲劳随之出现。被要求检查一切的人，最终会错过真正重要的问题。谨慎变成了瓶颈，而本可在高价值工作中发挥更大作用的 Agent 则被闲置。

解决方法是：当 Agent 的行为能够被验证时，让它自行行动；将人工判断保留给真正需要判断的决策。随着 Agent 承担风险更高的工作，例如金融交易，一次错误操作造成的危害会不断上升。组织需要有信心将重要工作交给 AI Agent，并确信即使无人监督，它也会留在预先设定的边界内。这种信心必须被建立起来。

内容过滤、测试和监控各自都发挥着重要作用，但这些能力中的任何一项，单独来看都无法承诺 Agent 下一次运行时会正确行为。信任来自相互强化的独立层级——这与行业在过去二十年中实践的“纵深防御（Defense in Depth）”是同一种分层纪律，只是被用于新的目标。纵深防御限制可能出错的范围，而这一方法扩展了你能够安全允许的范围。AWS 将其称为 Trust in Depth（纵深信任）。

Trust in Depth：可验证的信任

你需要在 Agent 生命周期的不同阶段回答一组问题，以建立信任：

• Scope（定义范围），运行之前： 这个 Agent 的用途是什么？这项工作需要哪些能力？它绝不能做什么？
• Know（识别身份），部署时： 谁授权了它？它携带什么身份？你能否追溯每一个代表你行动的 Agent？
• Bound（施加边界），运行期间： 它的操作是否始终处于你设定的限制内？它是否仍能完成工作？
• Observe（持续观察），每次运行之后： 你能否还原 Agent 做了什么、为什么这么做，并从中学习？

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

对于精确定义的规则，测试可以显示控制措施是否在预期场景中有效，但 Agent 可能会走上你未曾预料的路径。更进一步的技术是自动化推理（automated reasoning）：它利用数学逻辑检查一条规则是否在每一种可能情况下都成立。它可以确定：在系统及其假设被精确描述所覆盖的所有路径上，某项规则均成立；或者找出规则失效的确切情形。这样的结果就是证明（proof），而证明的可靠性取决于其背后的规则和假设。因此，最困难的工作发生在 Agent 运行之前。

AWS 已在生产环境中运行自动化推理超过十年，其应用范围包括每秒处理超过 21 亿次请求的 Identity and Access Management（IAM），以及 AWS Nitro Hypervisor、Amazon S3 Block Public Access 和 VPC Reachability Analyzer 等关键系统。现在，我们正将它带给 Agent。只要 Agent 的规则能够被精确表述，自动化推理就可以对其进行检查。

但并非每条规则都能被精确定义。“只有经理可以批准访问权限”可以被证明；“保持友好语气”则不能。在证明无法适用的地方，应限制 Agent 的访问权限和操作范围，评估其行为，并将真正存在歧义的问题交给人类作出判断。随着你确认相关规则得到了执行、Agent 能够可靠完成任务、且故障可以被发现和处理，你就可以赋予它更多自主权。

以下是 Trust in Depth 各层要求你回答的问题，以及 AWS 如何帮助你作答。

将 Agent 的范围限定为工作所需的内容

信任始于 Agent 运行之前，而这也是最值得投入精力的地方。在这里发现的问题，修复成本很低。定义范围意味着决定 Agent 负责哪些工作、可以访问哪些工具、数据和服务、必须遵循哪些规则，以及哪些决策仍由人类负责。

“解决客户的问题”描述了要实现什么，而没有说明 Agent 为实现目标可以如何行动。Agent 仍然需要明确限制：它可以看到什么、可以做什么，以及何时必须停止并询问。只授予其工作所需的访问权限，不要更多。还要警惕那些并非有意授予的能力，例如工具或角色附带的权限。为一项任务授予管理员角色，Agent 就可能继承整个环境中的权限。

范围界定从构建阶段开始，即从你如何定义 Agent 开始。Kiro 是一个 Agentic 编码系统，它将严谨性和成熟的工程实践带入 Agent 的构建阶段。它将高层意图转化为结构化、由规格驱动的需求，并利用自动化推理在任何代码编写之前发现矛盾、歧义和缺口。Kiro 还会推导基于属性的测试，在广泛的输入范围内检查实现是否符合这些需求，从而发现难以检测的 bug。Strands 提供开源工具包，用于定义 Agent 的模型、指令和工具，以及用于运行 Agent 的托管运行时。无论你选择何种框架，定义 Agent 的工作及其边界的责任都是相同的。

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

为 Agent 定义范围是最困难的部分，因为将人类意图转化为持久、可执行的策略，需要精确性和完整性。然而，这也是回报最高的部分。后续建立的一切都依赖于你在此处设定的内容；策略越精确，Agent 就能越安全地自行完成更多工作。

识别每一个代表你行动的 Agent，以及它们依据谁的授权行动

你无法治理你看不见的事物。团队创建 Agent 的速度快到无人能够完全追踪，而一个无人知晓的 Agent，就是一个无人控制的 Agent。每个 Agent 都需要自己的身份，并且在每次行动时接受验证。任何操作都不应成为无主操作。当出现问题时，你应能够知道是哪个 Agent 做了什么，以及是谁授权它这么做。

AWS Agent Registry 为整个组织中的 Agent、Model Context Protocol（MCP）服务器、工具和技能提供一个受管理、经批准的目录。管理员通过审批工作流，控制哪些内容可以被发现，并移除不再满足安全、合规和质量标准的内容。人类和 Agent 都可以查找并复用已有内容，而不必重复构建。但目录只能告诉你有哪些内容。在 Agent 被识别后，AgentCore 会为每个 Agent 签发独立身份，并在每次请求时验证该身份，使每一项操作都能追溯到一个在已知授权下运行的特定 Agent。这就是你如何识别每一个代表你行动的 Agent。

在你设定的限制内，约束 Agent 的言行

设置边界之所以重要，是因为 Agent 可能执行了 10 个你批准的步骤，却依然达成了无人预期的结果。它可能暴露敏感数据、偏离主题，或以策略禁止的方式组合多个被允许的操作。限制可能在两个方向上失效：过于宽松，Agent 会做不该做的事；过于严格，Agent 则根本无法完成工作。因此，应让 Agent 自行选择如何完成任务，但绝不能依赖它来执行自身的限制。这些限制定义了 Agent 的边界，应当存在于 Agent 周围的环境中，以确定性方式执行，并对完整的操作序列进行评估，而不是一次只检查一个步骤。

这正是你在 Scope 阶段定义的策略生效的地方。AgentCore 中的 Policy 会对通过 AgentCore Gateway 路由的每一次工具调用执行策略。AgentCore Gateway 是 Agent、工具和模型的安全入口点。由于执行机制位于 Agent 的推理过程之外，即使 Agent 存在 bug、受到操纵或遭遇提示词注入，同样的检查仍然有效：它无法关闭一个并非由自己运行的控制措施。授权也不必始终固定不变。由于任务风险会随执行过程而变化，时序策略会衡量会话中已经发生的事情，并在工作持续进行时调整权限。Amazon Bedrock Guardrails 治理 Agent 说出的内容和接收到的内容。它过滤有害或偏离主题的内容，并对敏感数据进行脱敏。Automated Reasoning checks 更进一步：它能够证明某个响应符合你设定的策略，而不是只符合模型对策略的理解。

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

观察 Agent 做了什么，然后持续改进

即使已经具备范围界定、身份和边界，Agent 仍可能在毫秒内响应、没有任何错误、所有仪表盘均显示正常，却依然做错事情。它可能检索了错误的信息、选择了错误的工具，或遵循了无人预料的路径。系统健康并不等于任务成功。要区分两者，你必须还原 Agent 实际做了什么：它接收了什么上下文、调用了哪些工具、应用了哪些策略决策，以及最终结果是什么。部署前测试仍然必不可少。生产环境则提供了真实条件下的行为证据，并为运营人员提供调查、干预和改进所需的信息。

Amazon CloudWatch Omni 专为持续观察而构建。它会捕获每一条追踪记录，并以时间线形式展示 Agent 的每一个步骤——从模型调用到工具调用——供团队调查。其内置评估器会针对传统监控无法覆盖的质量维度，为 Agent 响应评分，例如正确性、忠实性，以及 Agent 是否选择了正确工具。Agent 出错时的追踪记录还会成为测试修复方案的数据集，因此运营 Agent 与改进 Agent 都基于同一份证据。

Trust in Depth 在实践中是什么样子

一位经理要求服务台 Agent 为即将离职的客户经理 Sam 办理离职流程。Agent 需要移除 Sam 的访问权限、将他的邮箱移交给继任者，并释放公司不再需要的许可证。但 Sam 的电子邮件中也可能包含客户纠纷所需的证据。错误的执行顺序可能导致 Sam 离职后仍保有访问权限，或使这些证据面临风险。安全、消息传递、法务和财务团队各自都有 Agent 必须遵循的要求，尽管并没有人编写完整的工作流脚本。

两条规则决定了执行顺序。必须先阻止 Sam 登录，才能将其邮箱转换并与继任者共享。在更改他的电子邮件许可证之前，Agent 必须检查是否存在法务保全（legal hold）——即为纠纷保留记录的要求——并确认该变更能够继续保护这些记录。

Scope（定义范围）。在 Agent 运行之前，团队将这些规则编写为 AgentCore 中的策略。每项策略都要求：在下一步执行前，Sam 账户的前置步骤必须已成功完成。Agent 被精确授予六项工具：阻止登录、检查法务保全、施加保全、转换邮箱、授予继任者访问权限，以及更改许可证。它没有删除账户的工具，因为共享邮箱需要该账户继续存在。

Know（识别身份）。Agent 携带自己的身份，因此对 Sam 账户的每一项更改都能追溯到它。

Bound（施加边界）。Agent 尝试将 Sam 的邮箱转换为供继任者 Priya 使用的共享邮箱。由 AgentCore Gateway 执行的 AgentCore Policy 阻止了该调用：Sam 仍然可以登录，而转换邮箱不会更改他的密码，因此他的旧凭证仍可打开邮箱。Agent 随后阻止 Sam 登录，再转换邮箱并授予 Priya 访问权限。接着，它开始处理经理的实际请求——释放许可证——但网关再次阻止该操作，因为尚未有人检查法务部门的保全清单。Agent 进行检查后发现，法务部门要求为一项客户纠纷保留 Sam 的电子邮件。它放置了……（原文在此处截断）

In every conversation I have with enterprise leaders, they say the same thing. They want agents to do more, but they don’t trust them to do it right all the time.

That’s fair. The same creativity and autonomy that makes agents useful makes them hard to trust. Give an agent a task and it finds its own path to finish it, picking tools and sequencing steps no developer scripted. Run the same task twice and it might take a different route each time. A test that passes today tells you little about what the agent does tomorrow.

The usual answer is a person in the loop, approving everything the agent does. That works at small scale, but as agents take on more work, human approvals pile up and review fatigue sets in. People asked to check everything stop catching the things that matter. Caution becomes a bottleneck, and agents capable of far more sit idle on the valuable work that could be making more of an impact.

The fix is to let the agent act on its own when its actions can be verified, and reserve human judgment for the decisions that need it. As agents take on higher stakes work, like financial transactions, a wrong action becomes increasingly harmful. Organizations need the confidence to hand an AI agent important work, knowing it will stay within the limits set, even when no one is watching. That confidence must be built.

Content filtering, testing, and monitoring each serve an important purpose, but none of these capabilities alone can promise an agent will behave correctly the next time it runs. Trust comes from independent layers that reinforce one another, the same layered discipline the industry has practiced for two decades as Defense in Depth, turned to a new purpose. Where Defense in Depth limits what can go wrong, this expands what you can safely allow. AWS calls it Trust in Depth.

Trust in Depth: Trust you can verify

You build trust by answering a set of questions at different moments in the agent’s lifecycle:

• Scope, before it runs: What is this agent for, what capabilities does the job require, and what must it never do?
• Know, at deployment: Who authorized it, what identity does it carry, and can you account for every agent acting on your behalf?
• Bound, while it runs: Do its actions stay within the limits you set, and can it still do the job?
• Observe, after each run: Can you reconstruct what the agent did and why, and learn from it?

Across these questions, some requirements can be expressed as precise rules, while others call for judgment. A company might require that only a manager can approve access, or that an employee’s sign-in must be blocked before their mailbox can be shared. Other expectations, such as keeping a friendly tone or handling a sensitive situation appropriately, depend on context and human judgment.

For precisely defined rules, testing shows whether the controls work in the cases you anticipate, but an agent takes paths you didn’t. The technology that goes further is automated reasoning, the mathematical logic that checks whether a rule holds in every possible case. It can establish that a rule holds on every path covered by a precise description of the system and its assumptions, or uncover the exact case where it fails. That result is a proof, and it is only as good as the rules and assumptions behind it, which is why the hardest work comes before the agent runs.

AWS has run automated reasoning in production for more than a decade, from Identity and Access Management (IAM) at more than 2.1 billion requests per second to critical systems like the AWS Nitro Hypervisor, Amazon S3 Block Public Access, and VPC Reachability Analyzer. Now we are bringing it to agents. Wherever an agent’s rules can be stated precisely, automated reasoning can check them.

However, not every rule can be stated precisely. “Only a manager can approve access” can be proven. “Keep a friendly tone” cannot. Where proof does not apply, limit the agent’s access and actions, evaluate its behavior, and send genuine ambiguity to a person to apply judgment. Grant more autonomy as you establish that the relevant rules are enforced, the agent performs reliably on the task, and failures can be detected and handled.

Here is what each Trust in Depth layer asks of you, and how AWS helps you answer it.

Scope your agent to only what the job requires

Trust begins before an agent runs, and this is where to invest the most effort. Problems caught here are cheap to fix. Scoping means deciding what work the agent owns, which tools, data, and services it may reach, the rules it must follow, and which decisions stay with a person.

“Resolve the customer’s issue” says what to achieve, not how the agent may act to achieve it. The agent still needs limits on what it may see, what it may do, and when it must stop and ask. Give it only the access its job requires, and no more. Watch for capabilities no one granted on purpose, the ones bundled with a tool or a role. Grant an admin role for one task, and the agent can inherit permissions across your whole environment.

Scoping starts at the build stage, with how you define the agent. Kiro, the agentic coding system, brings rigor and mature engineering practices to the build stage of agents. It turns high-level intent into structured, spec-driven requirements and uses automated reasoning to surface contradictions, ambiguities, and gaps before any code is written. Kiro also derives property-based tests that check the implementation against those requirements across a wide range of inputs, catching bugs that are hard to detect. Strands provides an open-source tool kit for defining an agent’s model, instructions, and tools, and a managed runtime for operating it. Whatever framework you choose, the responsibility to define the agent’s job and its boundaries is the same.

The next step is turning those boundaries into rules you can hold the agent to. Amazon Bedrock AgentCore provides governance controls to scale agents safely and governs what the agent does. Using Policies in Bedrock AgentCore, you describe in plain language which tools, APIs, and data the agent may reach, and automated reasoning checks the policy for gaps, like catching a rule that grants too much access, and checks for contradictions that make a rule unable to ever be satisfied, before it takes effect.

Scoping your agent is the hard part, because turning human intent into durable, enforceable policy requires precision and completeness. However, it is also the part that pays off most. Everything that builds on what you set here, and the more precise the policy, the more your agent can safely do on its own.

Know every agent acting on your behalf, and under whose authority

You can’t govern what you can’t see. Teams are creating agents faster than anyone can track them, and an agent no one knows about is an agent no one controls. Every agent needs its own identity, checked every time it acts. No action should be orphaned. When something goes wrong, you can tell which agent did what, and who authorized it.

AWS Agent Registry provides a managed, approved catalog of the agents, Model Context Protocol (MCP) servers, tools, and skills across your organization. Administrators use approval workflows to gate what becomes discoverable and remove what no longer meets the bar for security, compliance, and quality. Both people and agents can find and reuse what already exists instead of rebuilding it. But a catalog only tells you what exists. Once the agents are known, AgentCore issues each agent its own identity and checks it on every request, so every action traces back to a specific agent operating under a known authority. That is how you know every agent acting on your behalf.

Bound what your agent says and does, within the limits you set

Setting boundaries matters because an agent can take 10 steps you approved and still reach an outcome no one intended. It can expose sensitive data, drift off topic, or combine permitted actions in ways your policies forbid. Limits can fail in both directions. Too loose, and the agent can do what it shouldn’t. Too tight, and it can’t do its job at all. So let the agent choose how to pursue its task but never rely on it to enforce its own limits. Those limits define the agent’s boundaries and belong in the environment around the agent, enforced deterministically and evaluated across the full sequence of actions, not one step at a time.

This is where the policy you defined in Scope takes effect. Policy in AgentCore enforces it on every tool call routed through AgentCore Gateway, a secure entry point for agents, tools, and models. Because enforcement sits outside the agent’s reasoning, the same checks can hold even when the agent is buggy, manipulated, or hit with a prompt injection: it cannot turn off a control it does not run. Authority does not have to stay fixed either. Because a task’s risk changes as it proceeds, temporal policies weigh what has already happened in a session and adjust permissions as the work continues. Amazon Bedrock Guardrails governs what the agent says and is told. It filters harmful or off-topic content and redacts sensitive data. Automated Reasoning checks go further, proving a response is consistent with the policy you set, not the model’s interpretation of it.

Boundaries also govern what an agent can reach in the first place: which files it can touch, which services it can call, and which credentials it can use. Strands Box, an open-source sandbox, enforces those boundaries from outside the agent’s instructions, so the agent can work with real tools and data but reach only what you allow. The same boundaries hold from a developer’s first local session through to production, so an agent can’t do in production what it couldn’t in development.

Observe what your agent did, then improve it

Even with scoping, identity, and boundaries in place, an agent can respond in milliseconds, with no errors and every dashboard green, and still do the wrong thing. It may have retrieved the wrong information, chosen the wrong tool, or followed a path no one expected. A healthy system is not the same as a successful task. To tell the difference, you must reconstruct what the agent actually did: the context it received, the tools it called, the policy decisions applied, and the result. Testing before deployment remains essential. Production adds evidence about behavior under real conditions and gives operators what they need to investigate, intervene, and improve.

Amazon CloudWatch Omni is built for continual observation. It captures every trace and lays out each step an agent took, from model calls to tool invocations, on a timeline a team can investigate. Its built-in evaluators score agent responses for qualities standard monitoring misses, such as correctness, faithfulness, and whether the agent chose the right tool. And the traces where an agent went wrong become the dataset you test the fix against, so operating an agent and improving it draw on the same evidence.

What Trust in Depth looks like in practice

A manager asks a help desk agent to offboard Sam, an account manager who is leaving the company. The agent needs to remove Sam’s access, transfer his mailbox to his successor, and free up the license the company no longer needs. But Sam’s emails may also contain evidence needed for a client dispute. The wrong sequence could leave Sam with access after he leaves or put that evidence at risk. Security, messaging, legal, and finance each have requirements the agent must follow, even though no one has scripted the full workflow.

Two rules govern the sequence. Sam’s sign-in must be blocked before his mailbox can be converted and shared with his successor. Before changing his email license, the agent must check for a legal hold, a requirement to preserve records for a dispute, and confirm the change keeps those records protected.

Scope. Before the agent runs, the team writes these rules as policies in AgentCore. Each policy requires that the prerequisite step already succeeded for Sam’s account before the next step can run. The agent gets exactly six tools: block sign-in, check for legal holds, place a hold, convert a mailbox, give the successor access, and change a license. It gets no tool to delete the account, because the shared mailbox needs the account to survive.

Know. The agent carries its own identity, so every change to Sam’s account traces back to it.

Bound. The agent tries to convert Sam’s mailbox to a shared one for Priya, the successor. Policy in AgentCore, enforced at the AgentCore Gateway, blocks the call: Sam can still sign in, and converting the mailbox wouldn’t change his password, so his old credentials would still open it. The agent blocks Sam’s sign-in, then converts the mailbox and gives Priya access. Next it moves to the manager’s actual request, freeing up the license, but the gateway blocks that too, because no one has checked Legal’s hold list. The agent checks and finds that Legal requires Sam’s emails to be preserved for a client dispute. It places the hold, confirms it is in effect, then changes Sam’s license to one that supports that protection. The company can reclaim the broader license while keeping the evidence intact.

Observe. Every step is recorded: what the agent tried to do, what the rules decided, the hold, and the outcome.

The agent completed the task without a person approving every step. Its permissions limited what it could change, its identity made those changes traceable, and policies stopped it from acting before the required safeguards were in place. The recorded steps let the team verify that Sam’s access was blocked, his successor could use the mailbox, and the required evidence remained protected.

What becomes possible when agents are trusted

AWS brings these layers together so you can scope an agent to its job, know which agents are acting for you, bound what they do and say, see what they did and improve over time, and prove your rules hold wherever they can be stated precisely. No one layer earns that trust on its own. Together, they are Trust in Depth, and they are what turns a capable agent into an agent that can be trusted to do important work.

You draw the lines: what an agent may do on its own, what needs a person’s approval, and when it must stop. That frees your people for what only people can do: weigh the hard calls, resolve the gray areas, and own the decisions you choose to keep in human hands. As evidence builds that an agent stays inside those lines, you can widen its responsibilities or narrow them.

At AWS, we believe every organization deploying agents, on any platform, should be able to answer these four questions with evidence, and with proof wherever it applies. That is the bar AWS is building for our customers, and the one we invite the industry to hold itself to. Defense in Depth made it safe to connect systems to the world. Trust in Depth makes it safe to let agents act autonomously within it.

Start with one agent, one workflow, and one boundary you can prove. Then expand as the trust is earned.

To begin implementing enforceable rules, explore Policy in Amazon Bedrock AgentCore and Automated Reasoning checks in Amazon Bedrock Guardrails.

---

About the author

Shawn Bice

Shawn is Vice President of AI Services at Amazon Web Services (AWS), where he leads the Automated Reasoning Group. The team’s core mission is advancing AI agent safety. Shawn drives science and product teams to bring neurosymbolic AI, which combines large language models with formal verification, into developer tooling so every builder can create trustworthy AI agents whose key behaviors are mathematically proved. Over nearly 30 years, Shawn has led security, data, and product organizations at AWS, Microsoft, and Splunk. He began his career as a U.S. Army officer in the 25th Infantry Division.