Automated response is the entire point of SOAR — a playbook detects a pattern and does something about it without waiting for an analyst to be awake. XCloak has that. It also has a rule that undercuts the "fully automatic" pitch on purpose: if a playbook wants to kill a process, isolate a host, or quarantine a file, it can't just do it. It creates a task in a pending-approval queue, and an analyst has to click approve before the agent ever receives the instruction.
The failure mode this prevents
Automated response systems fail in a specific, well-known way: a detection rule with an unexpectedly high false-positive rate gets connected to an automated action, and the system faithfully executes exactly what it was told to do, at scale, against production infrastructure, at 3am, with nobody watching. The action itself isn't the bug — the trigger condition was too broad, or a new deployment changed traffic patterns in a way the rule didn't anticipate, or a legitimate admin's session looked enough like a compromised one that the correlation logic connected them. None of that requires the detection to be "wrong" in some obvious way; it just requires it to be wrong occasionally, connected to an action with real consequences, and unattended.
Non-destructive playbook actions — Slack notification, Jira ticket creation, enrichment lookups — don't have this failure mode in any serious way. Sending a false-positive Slack message costs someone a moment of annoyance. Isolating a production database server because a detection rule misfired costs considerably more, and it's the kind of cost that compounds if it happens automatically and repeatedly before anyone notices.
What's actually gated
Three action types require approval when triggered by a playbook: kill_process, isolate_host, quarantine_file. These are specifically the actions that are hard to reverse quickly and that affect availability, not just visibility. Everything else in a playbook chain — enrichment, notification, ticket creation, even non-destructive agent queries — executes immediately, because gating those too would just slow down the response without meaningfully reducing risk.
It's worth being precise about scope here: this approval requirement applies to actions triggered by an automated playbook. An analyst manually issuing a kill-process command from the dashboard, deliberately, in response to something they're looking at, doesn't go through this queue — that's a human already making the decision the gate exists to protect. The gate is specifically about removing the "nobody was watching when this fired" scenario, not about adding friction to deliberate manual response.
Why this isn't a configuration toggle
We considered making the approval requirement optional — a setting a tenant could disable if they were confident enough in their detection tuning. We didn't ship that option, on purpose. The moment "require approval for destructive actions" becomes a checkbox, it becomes a checkbox someone unchecks under pressure to hit a faster response-time metric, and the entire point of the gate was to be the thing that's still there when someone's under pressure to move fast. A safety mechanism that can be disabled by the person it's meant to slow down isn't really a safety mechanism — it's a default.
Stale approvals expire, too
A queued destructive task expires after 15 minutes if nobody approves it — deliberately shorter than the 1-hour expiry for non-destructive tasks. The reasoning is symmetric with the approval gate itself: if 15 minutes have passed and nobody's reviewed a kill/isolate/quarantine request, the host or process it was targeting may no longer be in the state that triggered the recommendation in the first place. Executing a stale destructive action against a system that's since changed is close to as bad as executing an unreviewed one.