AWS proposes five layers for safer autonomous agents

AWS has introduced Trust in Depth, a five-layer framework for giving AI agents greater autonomy without routing every action through a person. The approach scopes the job, registers agent identity, enforces temporal tool policies outside model reasoning, reconstructs production traces and uses automated reasoning to prove precisely stated rules across possible execution paths.

Trust has to survive a different path

AWS has proposed a layered governance framework for enterprise agents called Trust in Depth. Published on 15 October, it responds to a central problem with autonomous systems: an agent can choose a different sequence of tools each time it receives the same task. A successful test demonstrates one route, not every route the agent may later discover.

Requiring a person to approve every step can control early deployments, but the queue grows as agents take on more work. Review fatigue then weakens the safeguard. AWS argues that autonomy should expand when actions can be verified, while decisions requiring judgement remain with people. The framework has five layers: scope, know, bound, observe and prove.

Scope the job before granting tools

Scoping defines the work an agent owns, the data and services it can reach, the rules it must follow and the point where it must stop. A goal such as resolving a customer issue is not enough because it says nothing about acceptable actions. The agent should receive only the tools and permissions needed for the defined workflow.

AWS highlights Kiro for turning intent into structured requirements and property-based tests, and Strands for defining models, instructions and tools. Bedrock AgentCore Policies can translate plain-language constraints into enforceable policies and use automated reasoning to identify contradictions or excessive access before a policy is deployed.

Identity and boundaries sit outside reasoning

The AWS Agent Registry provides an approved catalogue of agents, MCP servers, tools and skills. AgentCore gives each agent an identity checked on every request, so an action can be tied to an agent and the authority behind it. Inventory alone is insufficient; the identity must follow the agent into every tool call.

AgentCore Gateway enforces policies outside the model, meaning an agent cannot disable a restriction through faulty reasoning or prompt injection. Temporal policies consider earlier steps in the session and can change authority as risk develops. Bedrock Guardrails filters inputs and outputs, while sandboxing can limit files, services and credentials.

Observe outcomes and prove precise rules

CloudWatch Omni records model calls, tools and policy decisions on a timeline and evaluates qualities such as correctness, faithfulness and tool choice. A technically healthy service can still complete the wrong task, so operators need outcome evidence. Failed traces become regression tests for the next version.

Automated reasoning addresses precisely stated rules mathematically. It can establish that a property holds across paths covered by the system description and assumptions, or produce a counterexample. It cannot prove vague intentions or requirements omitted from the model. The hard work remains translating business and legal expectations into complete, testable policy.

Start with one provable boundary

AWS illustrates the pattern with an employee offboarding agent. Policies require sign-in to be blocked before mailbox conversion and a legal-hold check before changing the licence. The agent has six specific tools but no deletion capability. When it attempts steps out of order, the gateway blocks them until prerequisites are satisfied.

That example shows why sequence matters: every individual action may be permitted while the combined outcome is unsafe. Organisations should begin with one workflow, define one boundary that can be proved, test denied as well as permitted paths and review traces with the people who own the underlying process. Autonomy should grow only as evidence accumulates.

What to watch next

A mature programme should record who owns each policy, the assumptions behind a proof and the events that invalidate it. Changes to a tool, permission or workflow may require the proof to be rerun. Incident reviews should examine both model behaviour and whether the surrounding control expressed the intended rule. This keeps formal assurance connected to the changing production system rather than becoming a one-time launch certificate.

Practical implications

Human review still has a central role, but it becomes risk-based. A routine action that satisfies proved prerequisites may proceed automatically, while an exception, ambiguous policy or high-impact decision escalates. Reviewers then spend attention on cases where judgement changes the outcome instead of mechanically approving hundreds of predictable tool calls.

Teams should test negative capability as deliberately as successful completion. An offboarding agent must refuse deletion, cross-tenant access and licence changes made before a hold check. Red-team prompts should attempt to reorder steps or smuggle authority through retrieved content. A control earns trust when it blocks those paths while allowing the legitimate workflow to finish.

Trust in Depth is a framework rather than a guarantee supplied by one AWS service. Organisations remain responsible for policy quality, tool safety and the consequences of automation. The useful contribution is a common structure for deciding which assurance belongs before, during and after an agent run, and where mathematical proof is possible. It also gives security, engineering and business owners a shared vocabulary for approving autonomy in stages as evidence accumulates.