Separate a recommendation from an action
Correlated evidence can support a proposed response. That proposal should explain why the action is relevant, which assets or accounts it affects and what could happen if it is wrong. Treat recommendations and executed changes as separate states.
Define the approval boundary
Agree which actions can run automatically and which require human approval. Consider operational impact, privileges, tenant boundaries and the scope of a bulk change. Approval should apply to the actual affected targets, not a vague future action.
Plan the reversal before execution
Some actions can be rolled back; others cannot. Document the reversal path and any limitations before execution. Record the original state where appropriate, and verify that the environment supports the planned rollback.
- Propose with evidence
- Approve within agreed scope
- Execute with safety boundaries
- Verify the outcome
- Roll back when supported and required
Leave an auditable trail
Preserve who approved the action, what was targeted, when it ran and what it returned. An action that was submitted is not necessarily an action that succeeded. Explicit failure and partial completion states help the next analyst make a sound decision.