Guardrails before automation
Approval workflow, blast-radius limits, spend ceilings, per-action cooldowns, a global kill switch, and account-aware "never touch production" policy — with a signed audit trail on every action. Operators stay in control.
Automation without brakes is a liability. One over-eager script can terminate the wrong instance in the wrong account. Teams won’t enable automation they can’t bound, so they leave it off — and keep doing everything by hand.
Built to do the work, not just show it
Account-aware policy
"Production" is a property of the account: block the prod account, allow staging — same tenant, layered defaults → env → tenant → account.
Blast-radius & spend limits
Cap how many resources one run can touch and the dollars it can move; cooldowns rate-limit repeat actions.
Kill switch + single-use overrides
A global stop for emergencies, plus signed, single-use overrides that bypass one block for one run — audited with the account.
Everything is audited
Every action, approval, block, and override is a signed audit row with pre/post state.
From signal to result
Resolve
The safety layer merges default → env → tenant → per-account policy to decide what’s allowed.
Gate
The plan stage runs the rails before any side-effect; a block notifies the right channel and owner.
Override (rarely)
An admin can grant a single-use override from Slack, a signed email link, or in-app — for one run only.
- Delete/terminate verbs are permanently blocked; overrides only relax "block production" for one run.
- Blocks route to the account’s Slack channel with the account named, plus an in-app bell + email.
- Guardrails are independent of autonomy — they fire even in fully-automated lanes.
Questions
Can automation ever delete a resource?
Destructive verbs (delete/terminate) are blocked by policy and are not relaxable by an override.
How do we recover if something goes wrong?
Flip the global kill switch to halt everything, then use single-use overrides to run only what you intend.