AWS Trust in Depth: Scope, Know, Bound, Observe for Autonomous AI Agents

AWS says the main thing blocking enterprise AI agents is trust, not capability, and it has a name for its answer: Trust in Depth. In a post titled Trust in Depth: Giving agents more autonomy without losing control on the AWS Machine Learning blog (October 15, 2026), the company argues that approving every agent action by hand does not scale, and proposes four independent layers instead: scope, know, bound and observe.

This is vendor framing, and a product map for Amazon Bedrock AgentCore. It is still a useful checklist, because the problem it describes, agents that pick their own path to a goal, is one every team building agents will meet. Below is what each layer says, how it maps to AWS products, and where to stay skeptical.

TL;DR: the four layers

Why human-in-the-loop breaks down

AWS's starting point is plain: agents find their own route, so the same task may take a different path on a second run, and "a test that passes today tells you little about what the agent does tomorrow." The usual remedy, a person approving everything, hits review fatigue. People asked to check everything stop catching the things that matter.

That echoes research we have covered on the AI verification tax: checking and redoing AI output is a real cost, and more review does not automatically mean better review. AWS's proposal is to let the agent act alone when its actions can be verified, and reserve people for decisions that need judgment.

Layer 1: Scope

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

Two points stand out. First, "resolve the customer's issue" says what to achieve, not how the agent may act, so you still need limits on what it can see, do, and when it must stop and ask. Second, watch for capabilities nobody granted on purpose: an admin role granted for one task can let the agent inherit permissions across the environment.

On tooling, AWS names Kiro, which turns intent into structured requirements and uses automated reasoning to surface contradictions and gaps before code is written, and Strands, an open-source toolkit for defining an agent's model, instructions and tools. Then Policy in Bedrock AgentCore lets you describe in plain language which tools, APIs and data an agent may reach. Automated reasoning checks the policy for gaps, such as a rule that grants too much access, and for contradictions that make a rule impossible to satisfy.

Layer 2: Know

"You can't govern what you can't see." AWS notes that teams are creating agents faster than anyone can track them, and says every agent needs its own identity, checked every time it acts. AWS Agent Registry is described as a managed, approved catalog of agents, MCP servers, tools and skills with approval workflows, and AgentCore issues each agent an identity checked on every request.

The goal is that no action is orphaned: when something goes wrong, you can tell which agent did what and who authorized it. Our piece on AI agent security platforms covers how the wider market handles inventory and identity.

Layer 3: Bound

This is the enforcement layer, and the most technically interesting claim. AWS argues you should "let the agent choose how to pursue its task but never rely on it to enforce its own limits." Limits belong in the environment around the agent, enforced deterministically and evaluated across the full sequence of actions, not one step at a time.

In AWS's design, Policy in AgentCore enforces rules on every tool call routed through AgentCore Gateway. Because enforcement sits outside the agent's reasoning, AWS says 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." Temporal policies weigh what already happened in a session and adjust permissions as work continues.

Other bounds named:

• Amazon Bedrock Guardrails filters harmful or off-topic content and redacts sensitive data, and its Automated Reasoning checks aim to prove a response is consistent with the policy you set.
• Strands Box, an open-source sandbox, restricts which files, services and credentials an agent can reach, with the same boundaries from a developer's first local session to production.

For comparison, see our posts on Google Cloud's agent sandboxes and Capsem's VM sandbox. The pattern is the same: enforcement outside the model.

Layer 4: Observe

A healthy system is not the same as a successful task, says AWS: an agent can respond in milliseconds with every dashboard green and still do the wrong thing. To tell, you must reconstruct the context it received, tools called, policy decisions applied and the result. Amazon CloudWatch Omni is described as capturing every trace on a timeline, with built-in evaluators for correctness, faithfulness and whether the agent picked the right tool. Failed traces become the test set for the fix.

The worked example: offboarding Sam

AWS illustrates all four layers with a help-desk agent asked to offboard an employee. Two rules apply: the employee's sign-in must be blocked before the mailbox is converted and shared with a successor, and a legal-hold check must happen before changing the email license.

In AWS's telling, the agent gets six tools and no delete-account tool. When it tries to convert the mailbox first, the gateway blocks the call because Sam could still sign in. The agent blocks the sign-in, converts the mailbox, then is blocked again from freeing the license until it checks the legal hold list, places the hold and changes the license. Every step is recorded.

This is a constructed scenario, not a measured deployment, so it demonstrates the design rather than its failure rate. It is a good illustration of one idea, though: rules that gate the order of operations, enforced outside the agent.

What is proven and what is judgment

The most careful part of the post is its limits. AWS says automated reasoning can establish that a rule holds on every path covered by a precise description of the system and its assumptions, or uncover the exact failing case. But "that result is a proof, and it is only as good as the rules and assumptions behind it."

It also says plainly that not every rule can be stated precisely: "only a manager can approve access" can be proven, "keep a friendly tone" cannot. For fuzzy rules, AWS recommends limiting access and actions, evaluating behavior, and sending real ambiguity to a person.

How it compares with the threat reality

A framework is only as good as the platform under it. We covered a Zenity research report on hijacking agents on Bedrock AgentCore, which is a reminder to test any vendor's controls rather than assume them. Prompt injection is the core risk the Bound layer is meant to survive; our explainer on indirect prompt injection shows why deterministic enforcement outside the model matters. And as agents begin to move money, see how AgentCore Payments handles keys.

What this means for what you build or pay

• Use the four questions on any platform. AWS itself says every organization deploying agents "on any platform" should answer them. Write down, for each agent: its scope, its identity, its limits, and where its traces go.
• Put limits outside the model. Whatever stack you use, enforcement should sit at the tool or gateway layer, not in the prompt.
• Start narrow. AWS's own advice is one agent, one workflow, one boundary you can prove, then expand.
• Budget for the product map. The post names many services. Check the pricing and availability of each before designing around them.
• Add an independent check. If you run coding agents locally, a tool that blocks dangerous actions before they run adds a layer; AgentBeam is the agent security platform from the explainx.ai team built for that.

What to check before you trust it

1. Which parts are generally available today, and which are announced?
2. Can you export policies and traces, or are they locked to one cloud?
3. What does a blocked call look like for the developer, and how long does debugging it take?
4. How does the system handle rules that cannot be stated precisely?
5. Has an independent party red-teamed the controls?

Related reading

• Zenity: hijacking agents on AWS Bedrock AgentCore
• AgentCore Payments: agents pay without private keys
• AI agent security platforms in 2026
• Google Cloud agent sandboxes: five things to know
• Capsem VM sandbox for coding agents
• What is indirect prompt injection?
• The AI verification tax

Descriptions of AWS products are as stated in AWS's October 15, 2026 post and may change.