Approval modes, rollback and blast radius: questions to put to a vendor

When a platform contains an incident without a person in the loop, three controls stand between a good decision and an outage.

• Approval modes say which actions need a person and which do not.
• Rollback says how an action is undone, by whom and how quickly.
• Blast radius says how many hosts, accounts or mailboxes one run may touch.

A product can be strong on one and silent on the others. The rubric on this site scores them together as one criterion, approval, rollback and blast radius, because a buyer needs all three. Scores are capped where a vendor describes a mode but not the undo path.

Documentation varies from detailed to a single phrase.

Google's Response Agent documentation is the most specific we found. It states manual approval as the default, autonomous thresholds at Low, Medium or High risk, and per-integration or per-action overrides (read 2026-11-03). It also states that the feature is in Private Preview and not available to all customers in all regions. It describes no rollback.

D3 Security's platform page says it has built-in approval gates at every command-risk tier (read 2026-11-03), and its home page lists four autonomy modes: Deterministic, AI-Assisted, AI-Led and Autonomous (vendor claim, read 2026-11-03). Rollback and blast-radius controls are not stated on the platform page.

Prophet Security says its autonomous product takes only actions the customer has approved, and previews remediation before it runs (read 2026-11-03). Tiers, rollback and scope limits are not stated.

Cyware's Orchestrate page describes approvals through a mobile app for critical automation decisions and rollback of workflows to earlier versions (read 2026-11-03). That is workflow rollback. Undoing an action taken against a host or an account is a different thing and is not described.

CrowdStrike's Agentic SOAR page says autonomy can be set per workflow, from human approval to fully autonomous (page, read 2026-11-03). That is a vendor claim with no stated scope limit or rollback.

Microsoft documents access rather than approval. A Sentinel automation rule that runs a playbook needs the Microsoft Sentinel Automation Contributor role on the playbook's resource group (read 2026-11-03), and rules run in an order you set and can carry expiry dates. An approval step before an action inside a playbook is something you build in Logic Apps; the page does not describe a built-in one.

Several vendors publish nothing on the point. Swimlane says only that complex cases escalate to human review. The Splunk SOAR product page and Tines product page state no approval, rollback or blast-radius control on the pages read. In each case the finding is about public material. It does not show that the product lacks the control.

Ask how approval is configured, not whether it exists. The useful dimensions are:

1. Granularity. Is approval set per platform, per workflow, per integration, per action or per asset group?
2. Risk basis. Is it tied to a risk tier the vendor computes, to a rule you write, or to both?
3. Approver. Who can approve, from which device, and can an approver be on call outside the SOC?
4. Timeout. What happens if nobody answers: does the action expire, escalate or run?
5. Change control. Who may change an approval setting, and is that change recorded?

Google's per-action override and Cyware's mobile approval answer parts of this. Neither page answers all five.

For every containing action, ask what the undo is. Reconnecting an isolated host is a single call. Re-enabling an account is a single call. Un-rotating a key is not possible. Releasing a purged message works only if the mail platform kept it. A vendor that says "reversible" about key rotation has not thought it through.

Ask the vendor to show an undo in the demo, and ask for the audit entry it creates. Then run it in your pilot against a test account and a test host. If the vendor cannot show it, mark that action as approval-only for the life of the contract.

A scope limit is a number you can state: no more than five hosts per hour, no more than 50 mailboxes per purge, no accounts in the privileged group, no production tags without approval. Ask whether the platform enforces such a cap itself, or whether you must build the cap into each workflow.

The best case is a cap that is separate from the logic that proposes the action. Scoring reversibility outside the logic that proposes the action is a design choice worth testing for any platform, whatever the vendor: can the model that proposed the action also grant itself permission to run it?

Prophet's preview of remediation before it runs lets an analyst see the proposed action before it happens. That is slower than auto-run and it produces a record of what the platform would have done. Use it in the first month. It is the cheapest way to learn the platform's error rate.

Send this in writing and file the replies with the read date.

• List every autonomy mode and what each one may do without a person.
• Show the setting that changes an action from approval-required to automatic, and who can change it.
• State the undo for each containing action you ship, and the audit record the undo creates.
• State the maximum number of objects one run can touch, and whether the cap is enforced outside your own logic.
• State what happens to an approval request that nobody answers.
• Say which of these features are generally available and which are preview.

• Approval granularity, risk basis, approver, timeout and change control are documented for each platform on the shortlist.
• Each containing action has a tested undo and a named person who can run it.
• A numeric scope cap is set for every automated action.
• Approval timeouts default to expiry or escalation, never to execution.
• Changes to approval settings are logged and reviewed monthly.
• Preview or recommend-only mode runs for at least the first four weeks.
• Preview-stage features are marked as such and are not relied on for production containment.