An automated containment playbook isolated a production database server from the network after a false-positive alert, causing a significant outage. The team wants to keep automated containment for most endpoints. Which change BEST reduces this risk?
Select an answer to reveal the explanation.
Short Explanation
Automation without guardrails is a robot with a sledgehammer - fast, and not too picky about what it hits. Guardrails let you keep it swinging at ordinary laptops while asking a human before it touches the crown jewels. Ripping the playbook out entirely is the overcorrection trap.
Full Explanation
Guardrails are constraints that keep automation operating within acceptable boundaries. Here, a critical-assets list combined with a human approval step for those assets preserves fast automated containment for ordinary endpoints while preventing an unattended action from taking down business-critical systems. Additional guardrails can include confidence thresholds, rate limits on how many hosts can be isolated per hour, and automatic notification of system owners. This addresses the process risk the incident revealed: automation logic that treated every asset the same. Removing the playbook entirely throws away the speed benefit for the large majority of endpoints where automated isolation is safe and valuable. Isolating hosts before enrichment completes increases the chance of acting on false positives, which is the failure that caused the outage. Running the playbook under a shared administrator account with rights everywhere broadens the impact of any error or compromise of the automation and destroys accountability. Exam caveat: automation can introduce new single points of failure and technical debt, and the considerations in this objective exist to keep those risks visible. Operational check: replay the triggering alert in a test environment and confirm the playbook pauses for approval on the database server but still isolates a standard workstation automatically.