Automation policies

Not every action needs a human every time. Each environment has one setting - how much agents may do on their own - that decides which actions run unattended and which pause for approval.

It is a single threshold: every action is rated for risk before it runs, and an action goes ahead on its own when its risk sits at or below the level you chose. Anything above it waits for a person.

One tier sits above the threshold entirely. Actions rated Critical - the ones that destroy data or infrastructure for good - always wait for a person, on every setting. There is no configuration that lets them run on their own.

The three policies

You pick one per environment.

Policy	What agents do on their own
Human-gated	Nothing. Every action waits for a person.
Supervised	Inspect, and make reversible changes. Anything destructive waits.
Autonomous	Everything the environment’s IAM roles allow, unattended, except Critical actions.

In the app, selecting a policy shows you exactly which risk tiers it covers - each tier marks itself Auto-approved or Approval required as you change the setting.

Action risk tiers

Every action an agent proposes is rated before it runs:

Risk	Examples
Low	Read-only inspection, no changes
Medium	Reversible changes
High	Destructive but recoverable changes, IAM or security policy changes, data migrations, bulk or cost-impacting operations
Critical	Deleting a database, deleting storage that holds data, wiping stored records, tearing down infrastructure that holds state, turning off a security control, audit log, or backup

Anything rated above the policy you chose stops and asks a person. Critical is above every policy, so it always does.

The line between High and Critical is whether the change can be undone. Resizing a production database is High: disruptive, but reversible. Deleting that database is Critical, because no approval you grant afterwards brings the data back.

What happens, by policy and risk

Action risk	Human-gated	Supervised	Autonomous
Low	Approval	Auto-granted	Auto-granted
Medium	Approval	Auto-granted	Auto-granted
High	Approval	Approval	Auto-granted
Critical	Approval	Approval	Approval

The Critical row is the same all the way across. That is the point of it: it is not a threshold you can raise.

Production environments

Each environment is classified as Production or Non-production. The classification does one thing: it feeds the risk rating.

An action against a production environment is rated one tier higher than the same action elsewhere. A reversible change that is Medium risk in staging becomes High risk in production - so on a Supervised environment it goes ahead in staging and waits for a person in production, without you configuring anything twice.

Two limits on that bump:

It stops at the bottom. Read-only inspection stays Low everywhere. Reading a production resource is no riskier than reading a staging one, so it is not treated as though it were.
It carries to the top. A destructive change that is High elsewhere becomes Critical in production. So anything that destroys production data or infrastructure waits for a person, even on an Autonomous environment. This is the one case where setting an environment to Autonomous does not make it fully unattended, and it is deliberate.

The threshold is compared against the resulting risk and nothing else, so there is no second table to read: classify the environment accurately and the threshold means what it says.

Per-environment configuration

The threshold is set independently for each environment. A production account can be Human-gated while a sandbox account runs Autonomous, in the same workspace.

A newly connected environment starts at Supervised, production included. It needs no stricter default: production raises a change’s risk a tier, so the same work that runs unattended in staging stops for a person in production under the very same policy.
Setting an environment to Autonomous does not remove the Critical gate. If you need an environment where nothing at all is destroyed without review, that gate is already there.
Only workspace admins can change an environment’s threshold and classification, and choose who is allowed to approve.

When a change takes effect

Updating the threshold takes effect on the next approval evaluation. Approvals already in flight are not changed retroactively: a request that was already routed keeps the decision it was given. Tightening or relaxing the setting affects the work that comes after the change, not work already under way.