Concepts
Human approval and response actions
High-impact changes to endpoints, identities, email, SaaS, or cloud are modeled as response actions. Creating one is not executing one. Approval is structural in the control plane — not a soft UI checkbox that the browser can skip.
Lifecycle of a response action
An analyst, domain workbench, Hunt Ledger proposal, or Automation step creates a response action with an action type, parameters, and the incident it belongs to. Supported types include isolate_endpoint, disable_account, revoke_session, reset_mfa, quarantine_file, quarantine_message, purge_email_campaign, suspend_saas_user, revoke_oauth_grant, block_egress (also referred to as block_ip in some paths), rotate_cloud_credential, quarantine_cloud_workload, and create_ticket.
Status starts as requested. An approver who holds response:approve and the exact action-scope permission confirms. The control plane records approved_by, writes an audit event, and only then allows executors to call the downstream connector. Where rollback is supported for that action type, a later rollback path is available and also audited.
Automation approval steps pause the playbook run until a matching response-action receipt exists for the intended action. Approving inside Automation → Approvals resumes the run. Cancelling or rejecting stops advancement. Hunt Ledger proposed findings today open cases and create pending create_ticket actions — they do not leapfrog this model into silent containment.
Permission model in practice
Requesting and approving are separate permissions. Action scopes are separate again. Holding a generic approve permission is not enough to approve every containment type. Role baselines differ: a user can typically read and escalate; a power_user can request response actions; an admin can approve and holds response scopes; a super_admin holds only platform Access Review permissions and cannot operate tenant response queues.
| Permission | What it unlocks |
|---|---|
| response:request | Create pending response actions from cases and workbenches |
| response:approve | Participate in approval when the matching action scope is also held |
| response:isolate_endpoint (and peer scopes) | Authorize that specific action type |
| automation:approve | Clear playbook gates waiting on response receipts |
| automation:run / cancel / retry / rollback | Operate runs without rewriting playbook definitions |
| detections:manage | Trigger Hunt Ledger runs and edit detection policy |
Where operators meet approvals in the UI
Incidents → Response tab is the primary case-attached queue for request and approve. Domain workbenches expose domain-appropriate requests (isolate, quarantine, revoke, disable, and peers) that still land in the same response_actions table. Hunt Ledger findings with disposition proposed may create a pending create_ticket linked to a new or existing case. Automation → Approvals lists playbook runs blocked on human decision.
Always treat the button as “request or approve,” not “already done in the vendor.” Live mutation requires request + approval + executor. Evaluation mode may preview the flow without calling production executors — and must stay labeled.
Detection engines and hunt jobs must not silently execute isolate/disable/block/revoke paths. They may open cases and propose tickets; humans remain accountable for production change.