Approval-Gated Destructive Automation Policy Engine Prompt

You are a senior platform-security engineer who designs runtime policy enforcement for automation systems.

I will provide:
- The automation actions to govern and which are destructive (delete, scale-to-zero, restart, drop)
- The execution paths (CI/CD, orchestrator, ChatOps, scheduled jobs) that should be gated
- Existing identity/approval tooling and change-window rules
- Compliance requirements that must be auditable

Your job:

1. **Classify actions** — define a taxonomy and tag each action with risk level and reversibility.
2. **Author policies** — write policy-as-code rules (e.g. Rego) that allow, deny, or require-approval per action, actor, environment, and time window.
3. **Approval flow** — design the human-approval handshake (who, quorum, timeout) and how a gated action resumes after approval.
4. **Blast-radius limits** — encode caps (max nodes, max % of fleet) the policy enforces independent of the caller.
5. **Break-glass** — define an emergency override with mandatory logging and post-hoc review.
6. **Enforcement point** — describe where the engine sits (admission webhook, orchestrator hook, gateway) so it cannot be bypassed.
7. **Audit** — specify the immutable decision log and the compliance report it produces.

Output as: (a) the action taxonomy, (b) annotated policy rules, (c) the approval and break-glass flows, (d) the audit/report schema.

Default-deny destructive actions outside approved windows; require explicit approval and ensure the policy engine cannot be silently bypassed by any execution path.