AWS Trust in Depth Gives AI Agents More Autonomy Without Surrendering Control

AWS introduced Trust in Depth on October 15, 2026, arguing that AI agents need five reinforcing control layers before enterprises should expand their autonomy. The conflict is immediate. Companies want agents to complete valuable work independently, yet one incorrect action can expose data, alter access, or disrupt a financial process. AWS Trust in Depth aims to replace constant human approval with autonomy that organizations can verify.

That argument challenges the default compromise in enterprise agent deployments. Keeping a person in every loop appears safe, but approvals accumulate as workloads grow. Reviewers become bottlenecks, and repeated low-risk decisions create fatigue. Removing people entirely creates the opposite problem because a model can select unexpected tools, sequences, and intermediate actions.

AWS proposes a third route. Agents can choose how to complete approved work, while identities, permissions, policies, traces, evaluations, and formal checks constrain what they can actually do. This is not a claim that AI agents have become consistently trustworthy. It is a plan for making autonomy conditional on evidence, with people retained for ambiguity and consequential judgment.

AWS Trust in Depth Turns Autonomy Into an Evidence Question

AWS is reframing agent trust as an engineering claim that must be supported at several points in an agent’s lifecycle.

In its Trust in Depth announcement, AWS organizes that lifecycle around five ideas: scope, know, bound, observe, and prove. Each answers a different question about an autonomous system.

Scope defines the agent’s job before it runs. A team identifies the tools, services, and data needed for that job. It also decides which actions remain prohibited and which decisions require a person.

Know concerns identity and authority at deployment. Every agent should have a distinct identity, and each action should trace back to that identity. The organization must also know who authorized the agent to act.

Bound covers enforcement during execution. The agent can choose a route toward its objective, but infrastructure outside the model evaluates its attempted actions. Those controls determine whether each tool request falls within the established policy.

Observe addresses what happens after and during a run. Operators need more than uptime, latency, and error rates. They must reconstruct the model context, tool choices, policy decisions, outputs, and final outcome.

Prove applies when a requirement can be stated precisely. Automated reasoning uses mathematical logic to test whether a rule holds across every path described by a system model. It can also produce a counterexample showing where the rule fails.

These layers target different failure modes. A registry cannot stop an authorized agent from misusing a tool. A content filter cannot determine whether an account was disabled before its mailbox was transferred. A trace can explain a bad outcome, but it cannot prevent that outcome by itself.

AWS therefore treats trust as a composition of controls, not a score produced by one model evaluation. The approach borrows its logic from defense in depth, where multiple safeguards limit damage when one control fails. Trust in Depth changes the objective from containing attacks to permitting more verified activity.

The distinction matters because agent behavior is less predictable than conventional workflow automation. Traditional software usually follows paths developers explicitly encoded. An agent interprets an objective, selects tools, and sequences actions according to changing context.

Two runs can reach the same result through different routes. A successful test covers the route that occurred, not every route the agent might choose later. That limits what ordinary testing can establish about future behavior.

AWS does not claim formal proof applies to every business requirement. A rule stating that only managers approve access can be expressed precisely. A request to handle a sensitive employee situation appropriately cannot be reduced so easily.

The framework separates these categories instead of pretending one control can cover both. Machines can enforce precise rules. Evaluations can measure behavior that admits some variation. People can decide genuinely ambiguous cases.

That separation is the first important change in the AWS agent security argument. Human involvement becomes risk-based rather than universal. Autonomy expands only where boundaries, enforcement, and evidence justify it.

The Human Approval Queue Is Becoming Its Own Enterprise Risk

The primary contest is no longer autonomous agents versus human control, but blanket approval versus verifiable autonomy.

A person approving every action can reduce immediate anxiety during a pilot. The arrangement becomes harder to defend when an agent handles hundreds of routine steps. Review volume rises with usage, even when most decisions present little risk.

AWS argues that this produces review fatigue. People asked to approve repetitive actions eventually give each request less attention. The control remains present on paper, while its ability to catch meaningful problems declines.

The same pattern already appears in other security systems. Excessive alerts train users to clear queues instead of investigating anomalies. Agent approval workflows can reproduce that weakness when every tool call receives identical treatment.

Blanket approval also compresses different risks into one binary question. Reading a public document is not equivalent to changing an employee’s access. Drafting a response is not equivalent to sending it. Looking up an invoice is not equivalent to issuing a refund.

A more defensible design assigns controls according to consequence. An agent might retrieve approved information without interruption. It might need deterministic policy checks before altering records. A payment beyond an established boundary can still require explicit human authorization.

That design pressures several groups inside an enterprise. Security teams must convert broad principles into enforceable rules. Platform teams must provide identity, policy, and tracing across multiple agent frameworks. Business owners must decide which outcomes remain too ambiguous or consequential to delegate.

Developers also lose the option of treating a system prompt as the security boundary. Instructions can guide model behavior, but the agent still interprets them. Prompt injection, model error, or an unexpected context combination can change that interpretation.

AWS places enforcement around the agent instead. AgentCore policy controls evaluate requests traveling through an AgentCore Gateway before granting tool access. The policy engine operates separately from the model selecting the action.

That separation creates a useful security property. A manipulated agent cannot simply decide that a control no longer applies. It does not own the mechanism that grants or denies the tool call.

The model still has room to plan. It can select among permitted tools, recover from a denied request, and pursue a different valid sequence. The surrounding environment retains authority over the actions that reach real systems.

This balance is especially relevant for enterprises building agents across multiple departments. One team might create a customer support agent, while another builds a procurement assistant. A third could deploy a coding agent with production access.

Without shared governance, each team invents its own identity rules, approval logic, and audit format. That fragmentation makes it difficult to know which agents exist or who authorized them. It also makes consistent incident investigation nearly impossible.

AWS Agent Registry is intended to address the inventory problem by cataloging agents, tools, skills, and Model Context Protocol servers. Model Context Protocol, or MCP, is a standard interface through which agents connect to external capabilities. Administrators can govern which components become discoverable.

A registry still cannot establish trustworthy execution alone. It shows what has been approved, but runtime identity must connect each action to a specific agent. Policy enforcement must then decide whether that agent has authority for the requested operation.

This is where AWS Trust in Depth becomes more than a collection of security product names. The layers form a chain of accountability. Scope establishes intended authority, identity assigns it, policy limits it, and traces preserve evidence about its use.

The framework also shifts what enterprise buyers should request from agent vendors. Accuracy benchmarks remain useful, but they do not answer operational questions. Buyers need to know whether agents receive individual identities, whether policies sit outside model reasoning, and whether tool sequences can be reconstructed.

They should also ask whether controls travel across integrations. An agent can appear constrained inside one environment while reaching an external tool through a less governed route. The weakest connection can undermine the larger policy design.

Verifiable autonomy therefore demands architectural work that a demonstration rarely reveals. The model’s visible response is only the last step. Identity, authorization, tool mediation, and evidence determine whether the system deserves greater operational freedom.

External Policies Let Agents Choose a Path Without Choosing Their Limits

The central mechanism gives agents freedom over planning while denying them authority over the rules that govern execution.

AWS illustrates this mechanism with an employee offboarding scenario. A manager asks a help desk agent to remove an employee’s access, transfer a mailbox, and release an unneeded software license. The apparent task contains security, legal, operational, and financial dependencies.

The order matters. The employee’s sign-in must be blocked before the mailbox is converted and shared. Otherwise, existing credentials might still open the converted mailbox.

The agent must also check whether the mailbox is under a legal hold. A legal hold requires the organization to preserve relevant records for litigation or another formal dispute. Changing the license without protecting those records could destroy evidence or violate a retention obligation.

AWS gives the example agent exactly six tools. It can block sign-in, check for legal holds, place a hold, convert a mailbox, grant successor access, and change a license. It receives no account-deletion tool because deletion conflicts with the preservation requirement.

That is scoping in concrete form. The design removes an unnecessary hazardous capability before execution begins. It does not rely on a prompt asking the agent to avoid deletion.

Runtime policies then enforce the required sequence. If the agent attempts to convert the mailbox before blocking sign-in, the gateway denies the call. The agent can correct its sequence and continue without requesting a person’s approval.

The same happens when it tries to change the license before checking the legal hold. The gateway blocks the action until the prerequisite has occurred. If a hold exists, the agent must place and verify it before proceeding.

This example explains why single-request permissions are insufficient for some agent workflows. Each action might be permissible in isolation. Risk emerges from their order, accumulated context, or combined effect.

AWS addresses that problem through temporal policies. These rules consider earlier events within the same session when evaluating the current request. They can require a prior approval, impose a session total, or prevent an action after sensitive data was accessed.

The policies use Dogwood, a session-aware language compatible with Cedar. Cedar expresses authorization decisions involving a principal, action, resource, and relevant conditions. Dogwood extends that model with conditions based on session history.

The documentation describes deny-by-default behavior. A request proceeds only when a permit applies, while a matching prohibition overrides permission. This structure reduces dependence on an agent correctly interpreting the absence of a rule.

Temporal enforcement also introduces real operational constraints. Policy history is scoped to a session, and the caller supplies the session identifier. Starting a new session resets session-specific history, so a per-session limit is not an organization-wide spending control.

AWS also says temporal propagation does not cross AWS accounts or Regions. Components outside AgentCore must correctly forward the relevant workload token. Those limitations matter because real enterprise workflows often span accounts, vendors, and deployment boundaries.

A policy can only constrain the traffic it actually sees. If an agent has another route to the same service, the gateway becomes a partial boundary. Teams must inventory every credential and connection rather than assume one policy engine governs the entire workflow.

The precision requirement creates another challenge. “Do not expose confidential data” sounds clear to a person, but it leaves many technical questions unanswered. Teams must define which data is confidential, which destinations count as external, and which transformations remain prohibited.

Natural-language policy authoring can help translate intent into a formal policy. It does not eliminate the need to inspect assumptions. A perfectly enforced incomplete rule still permits the behavior that its author forgot to describe.

This is where automated reasoning adds value. Ordinary tests sample selected cases. Formal analysis evaluates the system representation and searches for contradictions, unreachable rules, unintended access, or a path violating a stated property.

AWS has applied automated reasoning to infrastructure services for more than a decade. The company says IAM evaluates more than 2.1 billion requests each second, while formal methods also support systems including S3 Block Public Access and VPC Reachability Analyzer.

That record gives AWS a credible foundation for extending similar methods toward agents. However, the proof remains bounded by the model, policy, and assumptions supplied. It does not prove that an ambiguous business objective is wise or complete.

The distinction is easy to lose in marketing language. Formal verification can prove that every modeled route respects a precise requirement. It cannot prove that the requirement captures every legal, ethical, or organizational concern.

For enterprises, the practical lesson is to narrow each proof claim. Instead of asking whether an agent is safe, ask whether it can call a payment tool without required authorization. Ask whether it can send data externally after accessing a protected record.

Those questions produce testable security properties. They also create clearer boundaries for human review. People can focus on policy intent and exceptional decisions, while machines enforce the parts that admit exact rules.

Observability Still Cannot Prove That the Agent Chose the Right Goal

AWS agent security can constrain and reconstruct actions, but it cannot remove ambiguity from the objective itself.

A well-contained agent can still make a bad decision. It might retrieve outdated information, choose the wrong permitted tool, misread a request, or optimize the wrong outcome. None of those failures necessarily trigger an infrastructure error.

This exposes a gap between system health and task success. A run can complete quickly with every service available and every tool call authorized. The result can still be incorrect or harmful.

AWS assigns that problem to observation and evaluation. CloudWatch Omni records traces across model calls, tool invocations, policy decisions, and results. Evaluators can then assess qualities such as correctness, faithfulness, and tool selection.

A trace is most useful when teams can connect it to the surrounding business record. Policies, requirements, incident decisions, and previous failures need a shared evidence trail. A searchable knowledge base can help teams preserve that context without treating raw traces as self-explanatory.

Production traces also become regression material. When an agent follows an unexpected route, developers can add that route to future evaluations. The team then tests whether a revised prompt, tool definition, or policy addresses the observed failure.

This creates a feedback loop between operation and development. Deployment produces evidence. Evidence changes evaluations and controls. Updated controls then face new production conditions.

The loop is valuable, but it is reactive. An organization must still decide how quickly it can detect harmful outcomes and whether it can reverse them. A trace recorded after an irreversible transfer does not recover the funds.

Reversibility should therefore affect autonomy. Low-impact, reversible actions can receive wider operating room. Irreversible or externally binding actions deserve narrower permissions, stronger prerequisites, or human confirmation.

Independent frameworks reinforce this lifecycle view. The AI RMF Core organizes risk work around governing, mapping, measuring, and managing. NIST describes governance as a cross-cutting function rather than a final compliance check.

Trust in Depth fits that general pattern, but AWS offers a vendor-specific implementation path. That creates both an advantage and a dependency. Enterprises can assemble registry, identity, gateways, policies, guardrails, and traces inside one cloud environment.

The dependency becomes a concern when agents operate across clouds or external software. AWS says the underlying questions should apply on any platform. Some enforcement details, however, rely on AgentCore gateways, AWS identities, and CloudWatch telemetry.

Organizations should separate the framework from its implementation. Scope, identity, external enforcement, observation, and proof are portable principles. The specific products used to provide them will differ across an enterprise.

Interoperability will become a serious test. An agent might start in one runtime, call an MCP server operated by another team, and then invoke a third-party application. Preserving identity and policy context across those boundaries is harder than governing a closed demonstration.

There is also a measurement problem. Evaluators can assign scores, but those scores depend on datasets, rubrics, and model-based judgments. A high faithfulness score does not necessarily represent legal compliance or an acceptable customer outcome.

Enterprises should document what each metric establishes and what it leaves unanswered. They should avoid combining unrelated measures into a single “trust score.” Such a number can conceal the exact control that failed.

Human judgment remains necessary because many objectives contain conflicting values. A support agent may need to balance speed, empathy, fraud prevention, and contractual obligations. No general policy determines the correct balance in every conversation.

AWS acknowledges this limitation by reserving human decisions for genuine ambiguity. That boundary is essential to the credibility of the approach. Trust in Depth would overreach if it treated every organizational expectation as formally provable.

The harder question is whether teams will preserve that restraint under pressure. Once an agent handles routine work successfully, managers will want to expand its permissions. Cost reduction can become a stronger incentive than accumulated evidence.

Governance must therefore define how autonomy increases and how it contracts. A team needs measurable entry criteria, incident thresholds, rollback procedures, and named owners. Trust should be revocable when the evidence changes.

The phrase “human in the loop” is too broad for this work. Enterprises need to identify which human, at what decision point, with what evidence, and under what deadline. Otherwise, escalation simply recreates the same approval queue AWS wants to avoid.

The most credible implementation will use several intervention patterns. Some actions will remain automatic. Others will require preapproval, post-action review, sampling, or escalation only after a policy exception.

Trust in Depth succeeds only if those distinctions survive real operations. Its value lies in allocating attention, not eliminating oversight. People should review the situations where contextual judgment changes the outcome.

Three Signals Will Show Whether AWS Trust in Depth Works Beyond the Framework

The next test is whether enterprises can convert AWS Trust in Depth from a persuasive architecture into measurable operating practice.

The first signal is production adoption of sequence-aware policies. Enterprises need more than static permissions that decide whether an agent can access a tool. They need evidence that temporal controls govern multi-step workflows involving approvals, sensitive data, and cumulative limits.

Concrete adoption would strengthen AWS’s argument that agents can receive greater autonomy without constant human review. Limited use in controlled demonstrations would suggest that policy modeling remains too complex for routine operations.

Buyers should watch which workflow categories appear first. Employee access, software deployment, claims processing, and payment operations all contain explicit prerequisites. They are suitable tests because teams can define at least some rules precisely.

The offboarding example sets a clear standard. A deployed system should deny an out-of-order action, explain the relevant policy decision, and let the agent recover through a valid sequence. It should preserve evidence that auditors can later reconstruct.

The second signal is cross-platform identity and policy continuity. Real agents rarely remain inside one service boundary. They reach databases, SaaS applications, internal APIs, cloud resources, and MCP servers.

AWS documents account and regional boundaries for temporal policy propagation. Third-party components may also need custom logic to forward identity context. Those constraints do not invalidate the approach, but they reveal where enforcement can fragment.

Support for consistent controls across these transitions would strengthen the Trust in Depth thesis. Continued dependence on tightly coupled AWS paths would weaken its claim as a general enterprise model.

Organizations should examine what happens when context disappears between hops. Does the receiving system deny the request, reduce privileges, or proceed without session history? A fail-open transition would undermine the previous controls.

They should also demand an agent-level audit trail rather than one shared application identity. If several agents use the same credential, investigators may know which service acted without knowing which autonomous process initiated the action.

The third signal is whether customers publish outcome evidence instead of deployment counts. The useful metrics concern denied unsafe actions, investigation time, escalation quality, task success, and recovery from policy violations.

A rising number of registered agents says little about trustworthy autonomy. A meaningful case study should show which permissions expanded, which controls supported that change, and how the organization measured failures.

Evidence should include false denials as well as prevented actions. Policies that block legitimate work can push teams toward bypasses or broader permissions. Excessive restriction can make an agent technically safe but operationally useless.

Customers should also report how often ambiguous decisions still reach people. A decreasing review rate only matters if task quality and incident severity remain acceptable. Removing approvals without measuring outcomes would reproduce the original risk in a less visible form.

These signals will determine whether AWS agent security becomes a durable operating model. The framework’s central proposition is reasonable: autonomy should follow verification, not enthusiasm. Its implementation demands disciplined scoping, explicit authority, external enforcement, observable execution, and limited proof claims.

Enterprise leaders should begin with one consequential workflow rather than a general-purpose agent. Define the actions that can be reversed, the boundaries that can be formalized, and the decisions that still require judgment. Then measure what the agent attempts, what policy blocks, and what people must resolve.

The final question is practical: which decision in your current workflow consumes human attention even though its governing rule is already precise? That is the best candidate for AWS Trust in Depth. Automate that boundary carefully, preserve the evidence, and expand autonomy only when the results justify the next step.