After SOAR

Approvals: per action, per playbook or per product

Published 4 November 2026. About 5 minutes.

Vendors set approval at different levels: per action class, per playbook step, or per product mode. Mate documents three autonomy modes, Sentinel leaves approval to the author, Cyware sends approvals to a mobile app. This guide maps each model and gives you a test for the level you need.

Approval is a design choice with three possible levels

Every SOC lead has seen a containment action that should have waited for a human, and a ticket update that should not have. Approval controls exist to separate those two. The question for a buyer is not whether a platform has approvals. It is at what level the platform lets you set them.

There are three levels, and they trade control against effort.

  • Per action. You decide for each kind of action, such as disable account, isolate host or block URL. High control, more configuration.
  • Per playbook or step. The author puts an approval step in the flow. The control is as good as the author's discipline.
  • Per product. A single mode applies to the whole agent or tenant: recommend only, supervised, autonomous. Fast to set, coarse.

Our rubric scores approvals at 12 of 100 points, and asks whether a step can pause for approval, who can approve, what is logged, and whether autonomy is set per action or per product. Here is what each vendor documents.

Per product, with a gradient: Mate and D3

Mate documents three autonomy modes on its platform page: Recommend only, Supervised, where risky changes still ask, and Auto-run under guardrails and audit. Its Gamebooks define when the agent must escalate, stop or ask for approval (Mate platform page) (read 2026-11-03, vendor claim). That mixes levels: a product mode, plus per-procedure escalation points written into each Gamebook. Mate also says it raises autonomy one action class at a time, and drops a category back to supervised if accuracy drifts. Mate's pages also name a scoring step, Confidence, Precision and Reversibility, checked before an agent acts on its own (Mate CPR post, 2026-10-18) (read 2026-11-03, vendor claim). Mate scores 8.5 on our approvals row, the highest of the twelve, on documentation alone. Mate is not a SOAR, and this is its documented answer to the job.

D3 says Morpheus has four autonomy modes: Deterministic, AI-Assisted, AI-Led and Autonomous, and that alerts the AI cannot resolve go to a human. It says approval and wait steps carry over in migrated playbooks (D3 playbook migration) (read 2026-11-03, vendor claim). D3 scores 6.0 on the row because the pages say little beyond that.

Per product with oversight and override: Torq

Torq's page says response can run fully autonomously or with human-on-the-loop oversight, with a manual override and transparent audit logs (Torq home page) (read 2026-11-03, vendor claim). We did not read per-action gating detail, which is the thing a SOC lead most wants to see. Torq scores 8.0 on the row. Read that as a good start, and ask for the gating page before you sign.

Per step, built by the author: Sentinel and migrated playbooks

Microsoft says high-impact automations should have human input. A Send approval email step is the Sentinel counterpart to a Splunk prompt. The approval is something the playbook author adds, and the product does not enforce it (Microsoft Splunk SOAR migration guide) (read 2026-11-03). Sentinel scores 7.0.

That model is flexible and fragile. Nothing stops a new playbook shipping without a gate. If you choose this model, you need a review step in your own change process, and a scan of playbooks for approval steps on destructive actions.

Microsoft's roles help here. Running a playbook from an automation rule needs the Microsoft Sentinel Automation Contributor role on the playbook's resource group (Microsoft, Automate threat response with playbooks) (read 2026-11-03). That controls who can wire a rule to a playbook, which is an approval of a different kind.

Where approval lives off the desk: Cyware and Swimlane

Cyware says approvers can run critical automation decisions from the enterprise mobile app, and lists playbook version control with audit trails (Cyware Orchestrate) (read 2026-11-03, vendor claim). A mobile approval helps at 03:00. It also moves a high-risk decision to a phone, so check the identity assurance on that device and what the log records.

Swimlane's Hero AI asks for user confirmation before key actions, per September 2025 coverage. The Swimlane page we read names guardrails and no approval workflow (Swimlane Turbine page) (read 2026-11-03, vendor claim). Swimlane scores 6.0.

Where we found nothing

Four of the twelve platforms score 4.0 on approvals because the pages we read said nothing: Cortex XSOAR, Google SecOps SOAR, Blink Ops and ServiceNow SecOps. For XSOAR, manual tasks and approval steps exist in the product but no page we read documents them (Cortex XSOAR product page) (read 2026-11-03). That is a scoring gap, not a finding that the feature is absent. It does mean you will be taking the vendor's word in the demo, and you should record what you see.

Splunk SOAR scores 5.0 because approval before actions is documented only through a third-party reading, and the Splunk page was not opened. Tines scores 7.0 on a home page that states governance, guardrails and monitoring, with human-in-the-loop detail from a search summary.

A test for the level you need

Pick three actions: one low risk, one medium, one high. For example, tag an alert, disable a user, isolate a server. Then ask each vendor to show, live:

  1. How you require approval for the high action only.
  2. Who can approve, and how that is restricted by role.
  3. What the log shows: requester, approver, time, evidence, action taken.
  4. What happens if nobody approves in the time you set.
  5. How you change the setting for one action without touching the others.

If the vendor can only answer at the product level, you get coarse control. That may be right for a small team and wrong for a bank.

Checklist for approvals

  • Classify your actions as low, medium or high risk.
  • Decide the level you need: per action, per step or per product.
  • Ask each vendor for the page that documents it, and note the date.
  • Test an approval on the high-risk action in a trial.
  • Check roles: who can approve, who can edit the gate.
  • Check the log fields and where the log is kept.
  • Test timeout behaviour: no approver responds.
  • If approval is author-built, add a review step for new playbooks.
  • Re-test after each major release, since agent features change quickly.