Human gates before destructive AWS actions

Human gates before destructive actions

The rule

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.

Procedure

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.

Blast-radius caps

1. Agents work in dedicated accounts or OUs with service control policies limiting the expensive and irreversible actions.
2. Protect the load-bearing stuff: termination protection on stateful resources, versioning on state buckets, MFA delete where it matters.
3. Every destructive action should be reversible for at least the time it takes a human to notice. Backups before deletes.

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