- AWS argues that approving every agent action causes review fatigue, and that rules should be enforced outside the agent so autonomy can grow.
- The idea matters because an agent picks its own path, so tests alone cannot show what it will do next.
- Ask who enforces each limit, which rules can be stated precisely, and whether every agent action can be traced.
The approval queue becomes a bottleneck
Putting a person in front of every agent action sounds like the safe choice. AWS argues it stops working at scale. Its October 15 post says a human sign-off on every step is fine for small jobs. As agents take on more work, approvals pile up and reviewers tire. People asked to check everything, in AWS's words, "stop catching the things that matter."
The post also explains why testing alone falls short. An agent picks its own tools and steps. Run the same task twice and it may take a different route. A test that passes today says little about tomorrow.
The lesson here is that autonomy is a property of the fence, not of the agent. You do not need to trust how the agent reasons. You need limits it cannot reach.
How the fence works
AWS calls its approach Trust in Depth. It starts from Defense in Depth, the layered design the industry has used for about two decades. That older idea is about containing damage. AWS's version is about widening the range of work you can safely hand over.
The layers follow the agent's lifecycle: scope its job, know which agents are acting, bound what they do, and observe what happened. The "bound" layer is the one to understand.
AWS says limits belong in the environment around the agent. Its Policy feature in Amazon Bedrock AgentCore checks every tool call that passes through AgentCore Gateway, the entry point for agents, tools and models. The platform runs the check, not the agent. So a buggy agent, a manipulated one, or one hit by a prompt injection (hidden instructions planted in content it reads) meets the same gate. AWS puts it this way: the agent "cannot turn off a control it does not run."
One offboarding, stopped twice by the rules
AWS walks through an illustrative scenario. A manager asks a help desk agent to handle the departure of Sam, an account manager. The agent must end his access, hand his mailbox to a successor named Priya, and release a license the company no longer needs. There is a catch: his emails may be evidence in a client dispute.
Two rules govern the order. Sign-in must be blocked before the mailbox is converted and shared. A legal hold check must come before any license change.
The agent first tries to convert the mailbox. The gateway blocks it, because Sam can still sign in and his old credentials would open the mailbox. The agent blocks sign-in, then converts it. It then tries to free the license. The gateway blocks that too, because nobody has checked Legal's hold list. The agent checks, finds a hold is required, places it, and then changes the license.
The agent got six tools and no tool to delete the account. No person approved each step. The rules did that work, and every step was recorded.
Where proof ends and judgment starts
AWS draws a careful line. Rules that can be stated precisely, such as "only a manager can approve access," can be checked with automated reasoning. This is mathematical logic that tests whether a rule holds in every case. AWS says it has run this in production for more than a decade, including in its identity and access system, IAM.
The proof has limits. AWS says it covers paths described by a precise model of the system and its assumptions. It is "only as good as the rules and assumptions behind it." Rules like "keep a friendly tone" cannot be proven. For those, AWS says to limit access, evaluate behavior, and send real ambiguity to a person.
Read it as a vendor's argument
The post is written by AWS and describes AWS products. The text we reviewed gives no failure rates or customer results. The offboarding case is a scenario, not a deployment.
The principle still travels. AWS ends by saying the bar applies on any platform: whoever deploys agents should be able to answer its four questions with evidence, and with proof where proof applies.
Questions for your team
Who enforces each limit on your agents: the agent, or the system around it? Does every agent have its own identity, so each action traces to a known authority? Which roles were granted for one task but carry wider permissions? Which of your rules can be written precisely, and who owns that writing? Can you reconstruct, step by step, what an agent did last Tuesday?
Autonomy is not a gift to the agent. It is a boundary you build around it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AWS.
