Detection rules action steps

Detection rules action steps let workflows enable or disable one or more detection rules in Elastic Security by rule ID list or KQL query. Use these named steps instead of a generic kibana.request call to the detection engine _bulk_action API when you only need to change rule enabled state.

Use detection rules steps for patterns like:

• Enable a newly imported rule as soon as a prerequisite data source is available.
• Disable a noisy rule (or every rule matching a tag query) until an investigation completes.
• Flip rule state from a scheduled health check without hand-writing a bulk-action request.

Both detection rules steps share the same conventions.

All parameters live under with. Both ids and query are with-level fields — there are no top-level fields specific to these steps.

Selector: exactly one of ids or query. ids is an explicit list of rule UUIDs. query is a KQL string that selects rules by their attributes. Providing both, or neither, is incorrect.

Use the rule id (UUID), not rule_id. The ids field takes the rule object's id. It must contain at least one ID. An empty query is also rejected (it would otherwise match every rule).

Idempotent, partial-success semantics. Rules already in the target state count as skipped, not failures. The step succeeds when succeeded + skipped > 0 and reports any per-rule failures in the output errors array. It fails only when every targeted rule fails (including "rule not found") or a non-recoverable error occurs.

Per-rule handling. To act on the outcome of individual rules, run a search first and foreach over the results, invoking the step once per rule.

Schema convention. In each schema table on this page, the Location column indicates where each parameter sits in the YAML:

• top level: Alongside type and name, at the top of the step or trigger definition.
• `with`: Inside the step's with: block.
• `on`: Inside the trigger's on: block.

Jump to either step:

security.enableRule · security.disableRule

Enable one or more detection rules.

# Enable a single rule by id
- name: enable_rule
  type: security.enableRule
  with:
    ids:
      - '{{ variables.rule_id }}'
		

# Enable every rule matching a query
- name: enable_high_severity_rules
  type: security.enableRule
  with:
    query: 'alert.attributes.params.severity: high'
		

Disable one or more detection rules.

# Disable a single rule by id
- name: disable_rule
  type: security.disableRule
  with:
    ids:
      - '{{ variables.rule_id }}'
		

# Disable every rule matching a query
- name: disable_noisy_rules
  type: security.disableRule
  with:
    query: 'alert.attributes.tags: noisy'
		

Both steps return the same summary object. Use it for branching or logging after the step.

• Security action steps: Overview of the security.* step namespace.
• Manage detection rules at scale: Patterns for automating rule-operations work with workflows.
• Kibana action steps: Generic kibana.request for other detection engine bulk actions (for example, run).
• Detection rule concepts: Background on how detection rules work.