Response & Orchestration
Automate response without removing human judgment
Response playbooks are directed graphs of governed actions. Each action class — block, isolate, revoke, notify — runs at a configured autonomy level. Every action records rollback state. The kill switch halts everything in under two seconds.
The autonomy ladder
Every action class in ManySignal runs at one of four autonomy levels. You configure the level per action class, per environment tag, and per alert severity. The configuration is declarative YAML stored in version control.
Action appears as a suggestion in the case timeline. Analyst clicks to execute. Nothing happens without a human click.
Workflow executes up to the action node, then pauses. A named approver receives a notification with a one-click approve or reject. Action executes only after approval.
Action executes immediately. A notification is dispatched post-execution. Rollback is available for reversible actions.
Action executes and is logged. Reserved for fully proven, low-blast-radius actions (e.g., adding a tag, updating a CMDB record). Requires explicit opt-in per action class.
Built for safe, fast response
Dry-run preview
Before any playbook executes in production, dry-run mode shows exactly which nodes would execute, which would be blocked by guardrails, which would require approval, and what the rollback state would be. Analysts can review the full execution plan on the case screen before clicking approve.
- Full execution graph preview in the UI
- Guardrail violations highlighted before run
- Estimated blast-radius impact displayed
Dry-run preview
Rollback state
Reversible actions — firewall rule additions, account suspensions, tag changes — record a rollback payload at execution time. A single-click rollback sends the inverse action to the target system. Rollback is available for up to 72 hours after execution and is gated at the same autonomy level as the original action.
- Rollback payload stored for 72 hours
- One-click rollback in the case timeline
- Rollback itself audited as a distinct action
Rollback state
Kill switch
A tenant-level kill switch stops all autonomous and approve-gated playbook execution within two seconds. In-flight actions complete; queued actions are cancelled. The kill switch state is visible on the SOC dashboard and requires an explicit re-enable action with a reason field.
- Sub-2-second halt of all queued actions
- In-flight actions complete; queue drained safely
- Re-enable requires reason and is audit-logged
Kill switch
Response & Orchestration — FAQ
What action types are available out of the box?
Shipped action modules cover: identity (suspend account, revoke OAuth token, force MFA), endpoint (isolate host, kill process), network (block IP at firewall, update security group), cloud (revoke IAM role, snapshot instance), and notification (Slack, PagerDuty, email, JIRA ticket).
Can I write custom actions?
Yes. The Universal Action connector lets you map any REST API call to an action module. You define the request template, success condition, and rollback payload in YAML. Custom actions are subject to the same guardrail and autonomy framework as built-in actions.
How are approvals routed?
Approval routing is configured per action class: on-call, named individual, LDAP group, or round-robin. Escalation rules fire if no approval arrives within a configurable window. Approvals can be actioned from Slack or email without opening the platform.
What happens if a response action fails mid-playbook?
The playbook records the failure, stops execution at the failed node, and creates a manual task for the analyst with the failure reason and the partial execution state. Completed actions before the failure are not automatically rolled back — that decision is left to the analyst.
Is response available in self-hosted deployments?
Yes. All response action modules run in the self-hosted environment. Outbound API calls to SaaS targets (Okta, CrowdStrike, etc.) originate from your network perimeter, not from ManySignal cloud infrastructure.
How does dry-run preview work before executing a response?
Before any response action executes, a dry-run simulation shows the exact API call that would be made, the entities that would be affected, and the estimated blast radius. Dry-run output is logged to the case timeline. Analysts can review and approve the actual execution from the same panel.
Can response playbooks integrate with ITSM tools like ServiceNow?
Yes. The ServiceNow action module creates, updates, and closes incidents bi-directionally. Approval flows can leverage ServiceNow approval workflows — a ManySignal approval gate waits for the ServiceNow change record to be approved before executing the response action.
How does ManySignal ensure response actions don't disrupt business-critical systems?
Entity tags (critical, production, executive) are respected by the guardrail engine. Actions against critical-tagged entities require human approval regardless of autonomy settings, and blast-radius limits prevent actions that would affect more entities than the configured threshold.
Is there a rate limit on how many automated actions can fire in a given window?
Yes. Per-tenant rate limits on action execution prevent a runaway detection from triggering mass automated response. Limits are configurable per action class and per time window. Actions that exceed the rate limit are queued for analyst review rather than silently dropped.
Respond faster without second-guessing
Book a walkthrough of the autonomy ladder and see a real playbook execution with dry-run preview.