AWS Trust in Depth: Five Layers for Agent Autonomy Without Losing Control

AWS outlined a five-layer framework, called Trust in Depth, for giving AI agents autonomy while keeping them under control: scope, know, bound, observe, and prove. Scope and bound act as hard gates enforced at the orchestration layer, while know and observe are soft controls, and prove selects between automated verification and human review. The framework is implementation-agnostic, with each layer mapped to options such as IAM policies, RAG retrieval, rate limiters, CloudWatch telemetry, and schema validation.

Enterprise leaders want AI agents to do more work. They also don't trust them to act correctly every time. This tension blocks production deployment. AWS's Trust in Depth framework addresses it with five layers: scope, know, bound, observe, and prove. Each layer targets a specific failure mode. Together they let agents act autonomously when actions can be verified and reserve human judgment for decisions that need it. Scope constrains what resources and APIs an agent can access before it starts reasoning. This is pre-execution access control. You define allowed tools, data sources, and external services at orchestration time. If the agent tries to call an out-of-scope API, the request fails before the LLM even sees the response. Know means the agent has context about policies, constraints, and business rules. This is injected into the system prompt or retrieved dynamically. The agent knows it can't approve purchases over $10,000 or access customer PII without a valid ticket ID. Knowledge doesn't enforce limits, it informs reasoning. Bound is runtime enforcement. Rate limits, budget caps, execution timeouts, and sandboxing. If an agent tries to loop 500 times or spend $50,000 on API calls, bounds kill the workflow. This layer prevents runaway costs and resource exhaustion. Observe is telemetry and audit trails. Every tool call, state transition, and decision point gets logged. You can replay workflows, trace failures, and measure drift between expected and actual behavior. Observability doesn't stop bad actions, it makes them visible. Prove is verification. Some actions can be checked automatically did the API return 200, does the output match schema, is the result within tolerance . Others require human review does this email sound right, should we approve this exception . The prove layer decides which verification path to take. The framework doesn't prescribe a single implementation. You can layer these controls into different parts of your stack. | Layer | Implementation Options | Enforcement Point | |---|---|---| | Scope | IAM policies, tool allowlists, network ACLs | Orchestrator or runtime | | Know | System prompts, RAG retrieval, policy docs | LLM context window | | Bound | Rate limiters, budget trackers, timeouts | Orchestrator or middleware | | Observe | CloudWatch, X-Ray, custom telemetry | Distributed across stack | | Prove | Schema validation, human-in-loop queues | Post-execution or inline | Scope and bound are hard gates. Know and observe are soft controls. Prove sits in between, it can be either depending on what you're verifying. Scope is the first line of defense. An agent that can only call three APIs can't accidentally delete your S3 bucket. You define scope at the orchestration layer, not in the LLM. Bedrock Agents example: tool allowlist agent config = { "agentName": "expense-approver", "instruction": "Approve or reject expense reports under $10k", "actionGroups": { "actionGroupName": "expense-tools", "allowedActions": "get expense report", "approve expense", "reject expense" } , "knowledgeBases": "expense-policy-kb" } The agent can't call delete all expenses because it's not in the allowlist. The orchestrator blocks the request before the LLM sees it. This prevents prompt injection attacks that try to trick the agent into calling dangerous tools. Scope also applies to data. If the agent can only query a read-only replica or a filtered view, it can't leak sensitive data even if the LLM hallucinates a SQL injection. Bounds are trickier in multi-step workflows. A single API call might be cheap, but 500 calls in a loop costs real money. You need bounds at multiple levels. Per-action bounds : Maximum cost or latency for a single tool call. If send email takes more than 5 seconds, kill it. Per-workflow bounds : Total budget for the entire agent run. If the agent has spent $10 in API calls, stop execution even if it wants to make more calls. Per-time-window bounds : Rate limits across all workflows. No more than 100 agent runs per hour, regardless of who triggered them. You enforce these in middleware or the orchestrator. The agent doesn't know about bounds, it just sees tool calls fail when limits are hit. Pseudocode: workflow-level budget tracking class BudgetTracker: def init self, max cost : self.max cost = max cost self.spent = 0 def check and record self, tool name, cost : if self.spent + cost self.max cost: raise BudgetExceededError f"Would exceed ${self.max cost}" self.spent += cost log metric "agent.cost", cost, {"tool": tool name} The orchestrator wraps every tool call with budget checks. If the agent tries to spend more than allowed, the workflow terminates. Observe and prove sound similar but serve different purposes. Observe is passive telemetry. Prove is active verification. Observe answers: What did the agent do? How long did it take? What tools did it call? What was the final state? Prove answers: Was the action correct? Did it meet quality standards? Should a human review it? You always observe. You selectively prove. For low-risk actions send a notification, log an event , observation is enough. For high-risk actions approve a refund, modify production config , you need proof. Proof can be automatic or manual. Automatic proof uses schema validation, business rule checks, or output comparison. Manual proof routes the decision to a human review queue. python Pseudocode: proof routing logic def verify action action, result : if action.risk level == "low": Automatic proof: schema validation if validate schema result, action.expected schema : return ProofResult verified=True, method="automatic" else: return ProofResult verified=False, method="automatic" elif action.risk level == "high": Manual proof: human review queue for review action, result return ProofResult verified=False, method="pending human" The prove layer decides which path to take based on action metadata. You configure risk levels per tool or per workflow. | Failure Mode | Layer | How It Helps | |---|---|---| | Agent calls unauthorized API | Scope | Blocks request before execution | | Agent violates business policy | Know | Informs reasoning to avoid violation | | Agent loops infinitely | Bound | Kills workflow after N iterations | | Agent makes expensive mistake | Bound | Stops execution when budget exceeded | | Agent fails silently | Observe | Logs failure for debugging | | Agent produces wrong output | Prove | Catches error before downstream impact | | Agent needs human judgment | Prove | Routes decision to review queue | No single layer solves everything. You need all five to cover the failure surface. Not every decision needs a human. The prove layer lets you draw the line. Automate proof when: Require human proof when: You configure this per tool or per workflow. The orchestrator checks the proof requirement before executing the action. Trust in Depth isn't a product, it's a pattern. You implement it across your stack. Orchestration layer : Bedrock Agents, LangGraph, or custom orchestrator. Enforces scope and bounds. Routes to proof queues. Observability layer : CloudWatch, X-Ray, or custom telemetry. Captures every state transition and tool call. Verification layer : Lambda functions for automatic proof. SQS queues for human review. Step Functions for multi-stage verification. Policy layer : IAM for resource access. Knowledge bases for business rules. Config files for bounds. The framework is stack-agnostic. You can apply it to any agent architecture. Use Trust in Depth when you need to deploy agents in production but can't afford uncontrolled autonomy. The five layers give you granular control over what agents can do, how much they can spend, and when humans need to intervene. Skip it if your agents only run in sandboxed environments or if you're still in the prototype phase. The overhead isn't worth it until you're handling real workflows with real consequences. The framework shines when you have a mix of low-risk and high-risk actions. You can automate the safe stuff and gate the dangerous stuff without building a custom control plane from scratch. Avoid treating this as a checklist. The layers are interdependent. Scope without bounds still lets agents burn money. Observe without prove gives you telemetry but no verification. You need all five to balance autonomy and control.