AWS introduced its Trust in Depth approach for AI agents on October 15, 2026. The framework asks teams to define an agent's job, identify who authorized it, enforce limits outside the model, observe what happened and prove precise rules where formal reasoning applies. It is an AWS description of layered agent governance, not evidence that any single product can make every autonomous action safe.
The five layers answer different questions
AWS groups the approach into five connected layers. Each addresses a different failure point in an agent workflow, from unclear requirements before deployment to a misleadingly healthy dashboard after a run.
| Layer | Question to answer | Evidence to keep |
|---|---|---|
| Scope | What may this agent do, and what must it never do? | Task requirements, allowed tools, data boundaries and approval rules |
| Know | Which agent is acting, and under whose authority? | Agent identity, authorization and action attribution |
| Bound | Are actions kept within the policy during the run? | Enforced tool permissions, denied actions and policy decisions |
| Observe | What did the agent actually do and what result followed? | Traces, tool calls, evaluations, outputs and failures |
| Prove | Can a precise rule be shown to hold under defined assumptions? | Formal checks, stated assumptions and counterexamples when a rule fails |
Scope the job before choosing the tools
A task description such as “resolve the customer issue” says what the agent should achieve, but it does not define the authority it needs. Teams should list the data the agent may read, the services it may call, the actions it may take, and the situations where it must stop and ask a person. The scope should also cover side effects, such as sending an email, changing an account or updating a record.
Least privilege matters because tools often carry more capability than a single task requires. A broad administrator role may let an agent perform unrelated actions even if its instructions tell it not to. Make the boundary explicit in the environment and give the agent only the permissions needed for the workflow.
Give every agent a traceable identity
A shared service account can make it hard to tell which agent initiated a change or who authorized it. AWS describes using an approved registry and agent-specific identity so actions can be traced to a known actor. The same principle applies outside AWS: record the agent identity, the requesting user or service, the authorization decision and the target system for each meaningful action.
Identity is useful only when the receiving tool checks it. A label in a log does not restrict access by itself. Bind identity to permissions at the gateway or service that handles the action, and make sure revoked or unapproved agents cannot keep using old credentials.
Enforce boundaries outside the model
An agent can take several individually allowed steps and still reach a prohibited result. For example, a workflow might be allowed to read a mailbox and update a user record, but must block sign-in before transferring mailbox access. A policy should check the required order and stop the next action when the prerequisite has not succeeded.
AWS describes policy enforcement through Bedrock AgentCore Gateway, content controls through Bedrock Guardrails, and sandbox boundaries through Strands Box. These are examples of controls around an agent rather than instructions inside its prompt. Teams using another stack should apply the same principle: the model can request an action, but a separate control must decide whether that action is allowed.
Temporal policies can also account for what has already happened in a session. An agent may need narrower permissions at the start, broader access after a verified approval, or an automatic stop after a high-risk action. These rules should be deterministic where possible and tested against sequences, not only isolated tool calls.
Observe outcomes, not only service health
A successful API response does not prove that the agent completed the user's task correctly. It may have selected the wrong record, used an unsuitable tool or returned a result that violates a business rule. Keep traces that connect the initial request, relevant context, tool calls, policy decisions, output and final state.
Evaluation should check the result that matters. For an account-offboarding workflow, that may mean confirming sign-in is blocked, required records are preserved, the successor has the right access and the license change follows policy. For a research agent, it may mean checking that claims have supporting sources. Use failed traces as test cases when improving instructions or tool descriptions.
Prove only the rules that can be stated precisely
AWS describes automated reasoning as a way to check precise rules against a formal model and identify counterexamples when they fail. A rule such as “only a manager can approve this permission” can be expressed in a way a verifier can check. A subjective expectation such as “respond in a friendly tone” cannot be proven in the same way.
Formal verification is only as reliable as the model, assumptions and policy being checked. It does not automatically prove that the real environment matches the model or that every unstructured judgment is correct. Use formal checks for rules that can be stated precisely, behavioral evaluations for softer requirements, and a human decision for ambiguity or high-impact exceptions.
Start with one workflow and a measurable boundary
- Choose one agent task with a clear outcome and limited external effects.
- Write down allowed tools, data, actions, prohibited outcomes and human approval points.
- Test identity and policy enforcement with both permitted and denied requests.
- Record complete traces and define a result-based evaluation set.
- Run failure cases, including prompt injection, missing data, repeated actions and partial outages.
- Expand the agent's authority only after the controls and recovery process work reliably.
Our MCP permissions guide covers tool access checks. The independent AI agent evaluation workflow explains how to grade results rather than trusting a model's own confidence. For production systems, also keep a versioned rollback path for prompts and policy changes in our prompt versioning guide.