AWS Proposes 'Trust in Depth': Replacing Human Approvals with Verifiable Layers to Grant AI Agents Autonomy
Addressing enterprise fears of uncontrolled AI agents, AWS introduces the 'Trust in Depth' framework. It advocates for granting autonomy through four layers—Scope, Know, Bound, and Observe—combined with automated reasoning, ensuring agents act within verifiable limits without requiring step-by-step human approval, thus solving review fatigue at scale.
ImportanceStructuralEvidenceE3 inspectableWrite-upStandard
In conversations with enterprise leaders, a common contradiction emerges: they want AI agents to do more work but don't fully trust them to act correctly every time. This distrust is fair. The same creativity and autonomy that make agents useful also make them hard to predict. Run the same task twice, and an agent might take a different route each time; a test that passes today tells you little about what the agent will do tomorrow. 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.
In the blog post "Trust in Depth: Giving agents more autonomy without losing control," AWS proposes a new approach: let the agent act on its own when its actions can be verified, and reserve human judgment for the decisions that truly need it. This method is called Trust in Depth, borrowing from the cybersecurity concept of Defense in Depth. However, instead of just limiting what can go wrong, this framework aims to expand what can be safely allowed. The core idea is building independent, reinforcing layers of trust so organizations can confidently hand important work to AI, knowing it will stay within set limits even when no one is watching.
The Trust in Depth framework revolves around four key questions across the agent's lifecycle: Scope (before it runs), Know (at deployment), Bound (while it runs), and Observe (after each run). First, before an agent runs, teams must define its purpose, required capabilities, and absolute prohibitions. This isn't just about goals; it's about precise permission boundaries. AWS recommends granting only the access the job requires, avoiding inherited admin roles. Second, every agent needs its own identity to trace actions and authority, preventing "orphaned" agents that no one controls.