AWS Trust in Depth: Giving AI Agents More Autonomy Without Losing Control

AWS wants enterprises to let agents act alone — and its new Trust in Depth framework is, at its core, an admission that nobody trusts them enough yet. The pitch is autonomy with guardrails; the honest part is that the guardrails, not the agent, are the product.

The problem AWS names is real. A human approving every agent action works until it doesn't: approvals pile up, review fatigue sets in, and people stop catching the things that matter. Capable agents then sit idle while valuable work waits. The fix AWS proposes is not "trust the model more" — it's to let the agent act alone only where its actions can be verified, and reserve human judgment for decisions that actually need it.

• Scope first, because it's cheapest there. Trust begins before an agent runs. Decide what work it owns, which tools and data it may touch, and when it must stop and ask. A goal like "resolve the customer's issue" says nothing about limits — and the trap to watch is permissions nobody granted on purpose, bundled in with a tool or an admin role. The more precise the policy, the more the agent can safely do alone. That's also why scoping is the hard part: turning human intent into durable, enforceable policy takes precision, not vibes.

• You can't govern what you can't see. "Know" isn't about what the agent knows — it's whether you know the agent. Teams are spinning up agents faster than anyone can track them, and an agent nobody knows about is an agent nobody controls. Every agent needs its own identity, checked every time it acts, so when something goes wrong you can say exactly which agent did what, and who authorized it.

• Never let the agent enforce its own limits. An agent can take ten approved steps and still land somewhere nobody intended — leaking data, drifting off-topic, or combining permitted actions into a forbidden outcome. So the limits belong in the environment around the agent, enforced deterministically on every tool call and across the full sequence, not one step at a time. AWS is blunt here, and right: those checks have to hold even when the agent is buggy, manipulated, or prompt-injected, because it cannot turn off a control it does not run.

• Observe everything, prove what you can — and be honest about the rest. A system can look healthy, dashboards green, and still have done the wrong thing: wrong retrieval, wrong tool, wrong path. So reconstruct what actually happened — context, tool calls, policy decisions, result — and turn failures into test cases. Automated reasoning can prove a rule like "only a manager can approve access" holds in every case. It cannot prove "keep a friendly tone." Where proof doesn't apply, constrain access, evaluate behaviour, and send genuine ambiguity to a person.

Strip the product names and this is a useful checklist for any platform, not just Bedrock AgentCore — AWS itself says so. But call the framing what it is: this is also a product map for AgentCore, and the article's own research supplies no measured outcomes, adoption evidence, or independent evaluation that the framework works. It's a coherent proposal, not a proven result. Grant autonomy only as you establish that rules are enforced, performance is reliable, and failures can be detected and handled — not because a vendor framework says you're ready.

Go deeper

Read the full analysis on Agentic Affairs: AWS Trust in Depth: Giving AI Agents More Autonomy Without Losing Control

Originally published on Agentic Affairs (https://agentic-affairs.com)