On October 15, 2026, AWS introduced AWS Trust in Depth, a framework for giving AI agents more autonomy without losing control. The announcement starts from a complaint the author says he hears in every conversation with enterprise leaders: they want agents to do more work, but they do not trust them to do it right all the time. Trust in Depth is AWS’s answer, and it is worth understanding on its own terms, because the problem it describes is one every team building agents will meet, whether or not they run on AWS.
What AWS Trust in Depth is and why AWS announced it
The post, by Shawn Bice, AWS vice president for agentic AI, frames the problem plainly: “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.” 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.
Trust in Depth is modelled on Defense in Depth, the layered discipline the industry has practiced for two decades. “Where Defense in Depth limits what can go wrong, this expands what you can safely allow.” AWS presents the framework as four questions, asked at different moments in the agent’s lifecycle: scope before it runs, know at deployment, bound while it runs, and observe after each run. A fifth element, prove, is the verification applied across all four: automated reasoning that checks whether a rule holds in every possible case. Some secondary write-ups count five layers; AWS’s own text frames four questions plus prove.
The trust bottleneck: why approving every action does not scale
“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 capable agents sit idle on valuable work. The stakes rise as agents take on higher-stakes work, like financial transactions, where a wrong action becomes increasingly harmful.
“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.” 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, layer by layer: content filtering, testing, and monitoring each serve an important purpose, but none of them alone can promise an agent will behave correctly the next time it runs.
Scope: deciding what the agent owns before it runs
“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. A goal such as “resolve the customer’s issue” says what to achieve, not how the agent may act, so it 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.”
One trap deserves attention: capabilities nobody 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. Kiro, the agentic coding system, turns high-level intent into structured, spec-driven requirements and uses automated reasoning to surface contradictions, ambiguities, and gaps before any code is written. Whatever framework you choose, the responsibility to define the agent’s job and its boundaries is the same.
Scoping is the hard part, because turning human intent into durable, enforceable policy requires precision and completeness. It is also the part that pays off most: the more precise the policy, the more your agent can safely do on its own.
Know: which agents are acting on your behalf
“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.
Know is not about what the agent knows; it is about whether you know the agent. One secondary write-up describes know as policy context injected into the agent’s system prompt, but that is the author’s interpretation, not AWS’s definition, which is identity and accountability. AWS Agent Registry provides a managed, approved catalog of the agents, Model Context Protocol (MCP) servers, tools, and skills across your organization. AgentCore then 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.
Bound: the guardrails that limit what an agent can do
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 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 Amazon Bedrock AgentCore enforces it on every tool call routed through AgentCore Gateway. “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: 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, filtering harmful or off-topic content and redacting sensitive data, and Automated Reasoning checks prove a response is consistent with the policy set.
Observe and prove: watching agents and verifying their work
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. Amazon CloudWatch Omni captures every trace on a timeline a team can investigate, and its evaluators score responses for correctness, faithfulness, and whether the agent chose the right tool. The traces where an agent went wrong become the dataset you test the fix against.
Prove turns observation into a guarantee, where a guarantee is possible. Automated reasoning, the mathematical logic that checks whether a rule holds in every possible case, 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 the Nitro Hypervisor, S3 Block Public Access, and VPC Reachability Analyzer. 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.
How it maps to Bedrock AgentCore, and where the vendor framing ends
The mapping: scope is Policies in Bedrock AgentCore; know is AWS Agent Registry plus the per-agent identity AgentCore checks on every request; bound is Policy enforcement at the AgentCore Gateway, temporal policies, Bedrock Guardrails with Automated Reasoning checks, and Strands Box; observe is CloudWatch Omni. AWS’s worked example is an offboarding: a manager asks a help desk agent to offboard Sam, an account manager who is leaving. The agent must remove Sam’s access, transfer his mailbox to his successor Priya, and free up the license, while Sam’s emails may be evidence in a client dispute. Two rules govern the sequence: Sam’s sign-in must be blocked before his mailbox can be converted and shared, and a legal hold check must come before any license change. The agent gets exactly six tools and no tool to delete the account. The gateway blocks the mailbox conversion until sign-in is blocked, and blocks the license change until the legal hold is checked and placed. The agent completes the task without a person approving every step, and every step is recorded, so the team can verify the access was blocked, the successor could use the mailbox, and the evidence remained protected.
But the framework is also, plainly, an AWS announcement. One independent analysis calls it vendor framing and a product map for AgentCore, while still calling it a useful checklist. The four questions are platform-independent: AWS itself says every organization deploying agents, on any platform, should be able to answer them with evidence, and with proof wherever it applies. What the supplied research establishes is narrower: it provides no measured outcomes, adoption evidence, or independent evaluation that would validate the framework’s effectiveness, and whether such evidence exists elsewhere is left unresolved. Trust in Depth is a proposal, and a coherent one, but its effectiveness is unmeasured in the research supplied.
What it means for teams building agents
Stripped of the product names, Trust in Depth is a checklist for the moment an agent may act without a person watching every step. Before you grant that autonomy, write down what the agent owns and what it must never do. Give it an identity you can account for. Put its limits in the environment around it, not in its instructions. Record everything it does. Prove the rules that can be proven. Where proof does not apply, constrain the agent’s access and actions, evaluate its behavior, and escalate genuine ambiguity to a person. Then grant more autonomy only as you establish that the rules are enforced, the agent performs reliably, and failures can be detected and handled.
“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.” The closing advice is deliberately small: “Start with one agent, one workflow, and one boundary you can prove. Then expand as the trust is earned.” It does not claim agents can be trusted; it claims trust can be built, one verifiable boundary at a time, and that the work belongs before the agent runs, not after it goes wrong. What remains open is the evidence. The supplied research leaves unanswered whether further case studies exist beyond AWS’s own worked example, whether independent measurements of AgentCore Policy or Automated Reasoning checks exist, and how teams outside AWS implement the know layer without a registry.
