Human gates before destructive AWS actions

TL;DR

An agent proposes destructive changes; an operator approves them. Destructive means: deleting buckets or tables, terminating databases, changing IAM policies, disabling versioning or logging, and any apply against production.

Steps

1. The agent produces a plan first: terraform plan, or a CloudFormation change set. No plan, no apply.
2. The operator reviews the diff. The diff is the unit of approval, not the intent ("update the stack").
3. Only then does the apply run, against the reviewed plan artifact.
4. Default to a sandbox account for agent experimentation. Production changes go through a pipeline with a manual approval step.
5. Agents work in dedicated accounts or OUs with service control policies limiting the expensive and irreversible actions.
6. Protect the load-bearing stuff: termination protection on stateful resources, versioning on state buckets, MFA delete where it matters.
7. Every destructive action should be reversible for at least the time it takes a human to notice. Backups before deletes.

When to use

You are seeing this: The operator reviews the diff. Use this skill when you run into "Human gates before destructive AWS actions".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Procedural skill encoding the plan-first, approval-gated operating model for destructive AWS changes, grounded in IAM least-privilege best practices. Verified against the live IAM user guide. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html