AWS's Trust in Depth makes agent approval a policy-engineering problem

On 15 October 2026, AWS described Trust in Depth, a framework for allowing autonomous agents to act without sending every step to a human approver. Its proposed layers are scope, know, bound and observe, with formal proof wherever rules can be expressed precisely. The difficult part is not reducing approval prompts. It is converting business requirements into enforceable conditions outside the agent's own reasoning.

AWS illustrates the problem with employee offboarding. An agent must block sign-in before converting a mailbox and must check legal-hold requirements before changing a licence. Both operations can be legitimate in isolation. Their order determines whether the workflow creates an access or evidence-preservation failure. The control has to understand the sequence, not simply the individual tool.

Policy needs to describe the allowed sequence

AWS says Amazon Bedrock AgentCore Policies can check policy gaps and contradictions using automated reasoning, while AgentCore Gateway applies policy to tool calls. Its example shows a gateway refusing mailbox conversion while the departing employee can still sign in. That is more meaningful than asking a model to remember an instruction buried in a prompt.

For production adoption, engineers should define preconditions and postconditions for each consequential action. A licence change can require a confirmed legal-hold decision; access transfer can depend on successful account disablement. Model outputs must never be the only source of truth for those prerequisites. Query authoritative systems and enforce decisions at the execution boundary.

Removing human approval is defensible only when an independent control can prove that the action was permitted at that point in the workflow.

Formal proof cannot repair a missing requirement

AWS distinguishes properties that automated reasoning can verify from contextual judgements that remain unsuitable for mathematical proof. Even a successful proof is conditional on the stated policy and its assumptions. If a workflow neglects a legal hold, separation-of-duties constraint or emergency-access exception, the proof may establish a narrower property than the business actually needs.

Security teams should review policy coverage with process owners before granting autonomy. Create negative tests for skipped prerequisites, unexpected tool combinations, stale identity claims and adversarial retrieved content. Run those cases against the actual gateway, not only the agent's simulated reasoning. Keep a human approval route for ambiguous or irreversible decisions.

Operational evidence is the release gate

AWS also describes individual agent identity, a registry of tools and agents, and CloudWatch Omni traces that record model calls, tool invocations and outcomes. Those signals are useful only if operators can correlate a request, the agent identity, a policy version, the decision and the final state of the target system.

Start with one constrained workflow. Measure blocked unsafe attempts, legitimate actions rejected by policy, human escalations and successful verified completions. Investigate failures as changes to policy, tools or identity rather than simply adjusting the prompt. Expand autonomous authority only when those measurements show that the safeguards work under realistic conditions. AWS presents a framework and product mechanisms, not independent proof that every deployment will meet that standard.

Produced through Devence Lab's automated research and publishing workflow, without prepublication human review. Devence Lab retains editorial responsibility. Sources are linked; report factual errors to contact@devencelab.com.

Written by the Devence Lab research team.