AWS Trust in Depth: five layers for letting agents act alone

AWS published a post on 15 October 2026 setting out "Trust in Depth", its framework for letting AI agents act on their own when their actions can be verified. The author, writing on the AWS Machine Learning Blog, says enterprise leaders want agents to do more but do not trust them to do it right every time. The post is vendor-published and promotes AWS products; it gives no measured results.

The problem AWS describes

AWS argues that a person approving every agent action does not scale: approvals pile up and review fatigue sets in, so reviewers stop catching the things that matter. It also says testing alone is not enough, because an agent picks its own path and may take a different route when the same task runs twice. Its answer is to let the agent act alone where actions can be verified, and keep people for decisions that need judgment.

The layers

• Scope, before it runs: define what the agent is for, which tools and data it may reach, and what it must never do. AWS says this is where to invest the most effort, because problems caught here are cheap to fix, and warns that a broad admin role granted for one task can let the agent inherit permissions across the whole environment.
• Know, at deployment: every agent gets its own identity, checked on every request, so each action traces to a specific agent and the authority behind it. AWS points to its Agent Registry, an approved catalogue of agents, MCP servers, tools and skills.
• Bound, while it runs: limits are enforced outside the agent. AWS says the agent should choose how to pursue a task but never enforce its own limits. Policy in AgentCore checks every tool call at AgentCore Gateway, and Bedrock Guardrails filters content and redacts sensitive data.
• Observe, after each run: capture traces of model calls and tool invocations and score them. AWS says an agent can respond in milliseconds with every dashboard green and still do the wrong thing. It names Amazon CloudWatch Omni for traces and built-in evaluators.
• Prove, where rules are precise: automated reasoning checks whether a rule holds on every path described. AWS says it has run this in production for more than a decade, including IAM at more than 2.1 billion requests per second.

The worked example

AWS walks through a help desk agent offboarding an account manager. Two rules govern the sequence: sign-in must be blocked before the mailbox is converted and shared with a successor, and a legal-hold check must run before the email licence changes. The agent gets six tools and no tool to delete the account.

In AWS's telling, the gateway blocked the mailbox conversion because the user could still sign in, and blocked the licence change until the hold check ran. The agent then blocked sign-in, converted the mailbox, found a legal hold, placed it and changed the licence. This is an illustration written by AWS, not a reported production incident.

What the post leaves out

• No numbers on how often policies blocked wrong actions, or how many false blocks stopped valid work.
• No cost or latency for enforcing policy on every tool call.
• AWS itself says a proof "is only as good as the rules and assumptions behind it", and that rules such as keeping a friendly tone cannot be proven; those go to limited access, evaluation and human review.
• The products named are AWS's. The post says the same questions apply on any platform, but gives no comparison.

What a team can take from it

The portable part is the order of work. Write the rules as precise, checkable sequences before building. Give the agent the fewest tools its job needs. Give each agent its own identity. Enforce the rules at the point where tool calls pass, not in the prompt. Keep traces so you can reconstruct what happened. Widen autonomy only as evidence builds, which AWS says should depend on rules being enforced, reliable task performance and detectable failures.