AWS Proposes Graduated Autonomy Pattern for Production AI Agents

AWS is proposing a middle ground between read-only and fully autonomous agents

AWS published a new graduated autonomy architecture for AI agents on August 26, 2026. The pattern is aimed at a common production dilemma: giving an agent full permissions exposes organizations to unpredictable failures, while keeping it permanently read-only removes much of the value of automation.

Instead, AWS proposes that agents begin with minimal authority and earn broader permissions through sustained measured reliability. If safety or behavior degrades, authority is reduced immediately. The design uses Amazon Bedrock AgentCore capabilities for runtime, gateway, policy and evaluation, with DynamoDB maintaining trust state and AWS CodePipeline gating deployments.

This is an AWS architecture pattern and implementation proposal, not a new foundation model or a guarantee that autonomous agents become safe merely by assigning them scores.

Six layers separate evaluation from enforcement

AWS organizes the design into six replaceable layers: a scoring engine, an autonomy tier system, pre-execution checks, an external enforcement layer, post-execution evaluation and a deployment gate.

The scoring engine computes a trust score over a rolling window from five dimensions: accuracy, safety, consistency, compliance and efficiency. Crucially, AWS says safety acts as an independent floor rather than being averaged away by strong performance elsewhere. A system that is efficient and accurate most of the time should not retain elevated permissions if its safety behavior falls below the required threshold.

The tier system then converts sustained scores into four autonomy levels. New agents begin at T1 with read/list access. Higher tiers progressively introduce writes, execution and broader modification authority. AWS's example T4 tier permits full access with post-hoc auditing, but organizations can change those thresholds and permissions to fit their own risk model.

Promotion is slow; demotion is immediate

AWS's transition rules are deliberately asymmetric. Promotion requires the trust score to remain above the next-tier threshold for the entire rolling window. Demotion occurs immediately when safety falls below its floor or prompt-injection detection triggers.

The design also adds hysteresis: promotion requires a score above the tier boundary, while demotion happens at the boundary itself. That is intended to stop agents from rapidly oscillating between privilege levels around a threshold.

Trust history is stored in DynamoDB so policy decisions can use both current state and previous behavior rather than a single evaluation result.

Tool calls are checked before execution

A key point in the AWS design is that post-run scoring alone is not enough because some actions cannot be undone. The proposed pre-execution layer evaluates tool calls before they run, checking signals such as known prompt-injection patterns, credentials or private keys in arguments, destructive tool names, unusual tool-use behavior, confidence calibration and whether reasoning was supplied before the action.

AWS explicitly describes these as fast first-pass filters, not a complete defense. The stronger boundary sits outside the agent process.

AgentCore Gateway and Cedar policies enforce permissions externally

The enforcement layer uses Amazon Bedrock AgentCore Gateway and AgentCore Policy so the agent cannot simply rewrite its own permission checks. Tool invocations pass through Cedar policies with forbid-wins semantics: if any applicable forbid policy is satisfied, broader permits do not override it.

That separation is one of the most important parts of the architecture. Model reasoning can propose an action, but infrastructure outside the model process decides whether the current autonomy tier permits it.

AWS's example maps low-trust agents to policies that block write, execute and delete operations. Promotions remove some restrictions; demotions reapply them.

Post-execution evaluation creates a feedback loop

After actions complete, the architecture evaluates outcomes and feeds them back into the trust score. AWS emphasizes provenance and reversibility: audit records should preserve the pre-action state, the decision context, relevant safety signals and human overrides so operators can understand why an action happened and recover when possible.

The deployment gate then prevents degraded versions from reaching production. AWS proposes adversarial tests in CI/CD and says a single unauthorized tool call can block a release in the example policy.

Why graduated autonomy matters

The broader design principle is that agent permissions should be dynamic but externally enforced. Capability and reliability change after prompt edits, model upgrades, tool changes and environment shifts. Static IAM assignments alone do not measure whether the agent is currently behaving well enough to exercise the authority it has been given.

Graduated autonomy is not a substitute for least privilege, sandboxing, human approval or incident response. It is a pattern for combining those controls with continuous evidence. Teams considering it should validate the scoring model, test adversarial edge cases and be especially cautious about what any highest-autonomy tier is allowed to do irreversibly.