Teams usually start automation in one of two places. Some automate nothing, because any change to production feels risky. Others automate a lot and lose track of what changed and who agreed to it. A small set of approval tiers gets you between the two.
Classify the change, not the tool
Risk belongs to the change itself. Restarting a sync agent on a laptop is low risk. Disabling public access on a storage account is usually medium: it can break a legitimate integration. Retiring a device, changing a privileged group or quarantining a switch port is high or critical.
We use four tiers:
| Change risk | Approvals | Who approves | Also required |
|---|---|---|---|
| Low | None, if the policy allows it | — | Automations and AI only when the tenant allows automatic execution |
| Medium | 1 | A different person | Self-service only with the device owner’s consent |
| High | 1 | An elevated approver | MFA step-up |
| Critical | 2 | Two different people | MFA step-up and a shorter approval window |
Rules that hold in every tier
- No self-approval. The person who asked for a change cannot approve it.
- Only people approve. API tokens and AI agents can request changes but can never approve them.
- Stricter, never weaker. A tenant can require more approvals than the default, but never fewer.
- AI waits for a person above low risk. Even when a tenant allows automatic execution, an AI-initiated change that isn’t low risk goes to a human.
Make every change reversible or at least provable
Before execution, a dry run shows what would change. After execution, verification checks the result: a re-scan for cloud changes, the device’s own report for endpoint fixes, a read-back from the switch for network changes. A fix that can’t be verified stays open.
Keep the record
Each step, request, approval, execution and verification, goes into the audit trail with the before and after state. Make that trail tamper-evident: append-only, and ideally hash-chained. That record is what lets you hand more work to automation over time: you can show exactly what it did.
Getting started
Begin with low-risk fixes that are easy to verify, such as clearing temporary files, restarting a stuck service or tightening a storage setting in a test environment. Let them run automatically for a month, review the audit trail, and widen the scope from there.