Rule actions extend Workload Protection (Runtime Security) rules beyond detection. When a rule matches an event, the Agent can execute one or more actions to enrich the event, respond to a threat, or drive multi-step detection logic.

Actions are defined in Agent policy files (.policy) under the actions field of a rule.

Syntax

Each rule can define multiple actions as a YAML list. Each list item must contain exactly one action type.

rules:
  - id: my_rule
    expression: exec.file.name == "suspicious_binary"
    actions:
      - set:
          name: flagged_process
          value: true
          ttl: 5m
      - kill:
          signal: SIGKILL
          scope: process

Action filters

Every action supports an optional filter field: a SECL expression evaluated at action time. The action runs only when both the rule expression and the action filter match.

rules:
  - id: kill_container_process
    expression: exec.file.name == "malware"
    actions:
      - filter: process.container.id != ""
        kill:
          signal: SIGTERM
          scope: container

set: store variables

Use set to store state that persists across rules within the same policy. After it is defined, a variable can be referenced from any other rule in that policy.

When to use it

Variables are one of the most powerful capabilities in Agent rule authoring. They are essential for building stateful, multi-step detections that go beyond what a single SECL expression can express on its own.

• Chain rules within a policy by recording context in one rule and matching a follow-up rule that references that variable.
• Build rolling lists of process names, paths, or DNS activity.

Parameters

Examples

Set a Boolean flag:

rules:
  - id: flag_suspicious_exec
    expression: exec.file.path in ["/tmp/evil"]
    actions:
      - set:
          name: suspicious
          value: true
          ttl: 10m
  - id: detect_follow_up
    expression: open.file.path == "/etc/shadow" && ${suspicious}

Collect DNS queries into a rolling list:

rules:
  - id: collect_dns_queries
    expression: dns.question.name != ""
    actions:
      - set:
          name: queried_domains
          field: dns.question.name
          append: true
          size: 10
          ttl: 10s
          scope: process

Create a correlation rule:

Use private to keep internal state out of security events, and scope_field to bind a variable to a process other than the one that triggered the event (for example, the target of a cgroup_write event):

rules:
  - id: init_correlation_key
    expression: cgroup_write.file.path != "" && ${process.correlation_key} == ""
    actions:
      - set:
          name: correlation_key
          default_value: ""
          expression: '"attack_${builtins.uuid4}"'
          scope: process
          scope_field: cgroup_write.pid
          inherited: true
          private: true
  - id: detect_correlated_file_access
    expression: open.file.path == "/etc/shadow" && ${process.correlation_key} != ""

Compute a value from an expression: Use expression with default_value to define the variable type and store a computed result.

rules:
  - id: record_exec_context
    expression: exec.file.path in ["/tmp/evil"]
    actions:
      - set:
          name: exec_context
          default_value: ""
          expression: '"cmd_${process.pid}_${exec.file.name}"'
          scope: process
          ttl: 5m

kill: terminate a process

Use kill to actively stop malicious activity. The Agent sends a POSIX signal to the target process, container, or cgroup.

Configure in Datadog

In addition to defining kill actions in Agent policy files, you can configure process termination in Datadog:

• Automatic: Add kill actions to Agent rules in a policy, as described in this section, or use automated response.
• Manual: From a security signal, use Kill containers or processes under Respond in the signal side panel.

Both approaches require Agent enforcement, which is enabled by default. See Respond to Threats for an overview of enforcement and response actions.

When to use it

• Block cryptomining, reverse shells, or known malware at runtime.
• Gracefully stop a process (SIGTERM) or force-kill it (SIGKILL).

Requirements

• Enforcement must be enabled in the Agent configuration (runtime_security_config.enforcement.enabled). See Advanced configuration.
• Kill actions are rejected at policy load time if enforcement is globally disabled.
• Supported signals include SIGKILL, SIGTERM, SIGHUP, SIGINT, and other standard POSIX signal names.

Parameters

Safeguards

The Agent includes disarmers to prevent runaway kill loops during automated response. If too many kill actions fire against the same container or executable within a configured period, subsequent kills for that target are suppressed until the period expires.

Certain binaries can also be excluded from enforcement through runtime_security_config.enforcement.exclude_binaries.

Example

rules:
  - id: block_ping_process
    expression: >-
      exec.file.name == "ping"
    actions:
      - kill:
          signal: SIGKILL
          scope: process

Kill action report

When a kill action runs, the Agent attaches an action report to the triggering Agent event in agent.rule_actions. This is not a separate custom event—the report is serialized with the security event that matched the rule. For SIGKILL, the Agent may delay sending the event until the target process exits so timing fields are accurate.

To count how many times a kill action ran after a rule match, use the datadog.runtime_security_config.rules.action_performed metric with tags rule_id:<rule_id> and action_name:kill.

network_filter: monitor or block network traffic

Use network_filter to drop packets matching a BPF filter expression for the offending process or cgroup. This is network isolation at the host level.

Configure in Datadog

In addition to defining network_filter actions in Agent policy files, you can isolate a compromised workload in Datadog:

• Automatic: Add network_filter actions to Agent rules in a policy, as described in this section. When a rule matches, the Agent drops matching traffic automatically.
• Manual: From a security signal, use Network isolation under Respond in the signal side panel.

When to use it

• Cut off C2 communication after detecting a malicious process.
• Block DNS or specific port traffic from a compromised container.

Requirements

• Enforcement must be enabled.
• The raw_packet event type must be enabled in the Agent configuration.
• Linux only (eBPF-based packet filtering).

Parameters

Example

rules:
  - id: block_malicious_container_network
    expression: exec.container.id == "046f6a38c8b404a78fb9be56672d554ed5a326f4c568ffb137e16cf3e7e6be43"
    actions:
      - network_filter:
          filter: "dst net 10.0.0.0/8 or dst net 172.16.0.0/12 or dst net 192.168.0.0/16 or dst net 169.254.0.0/16 or dst net 127.0.0.0/8"
          policy: drop
          scope: cgroup

Raw packet action and metrics

Raw packet action event

When the kernel drops a packet that matches an active filter, the Agent can emit a rawpacket_action custom event (@agent.rule_id:rawpacket_action). These events are rate-limited under high drop volume, because the Agent cannot send one event for every dropped packet. The event payload includes:

Metrics

To track drop counts reliably, use the datadog.runtime_security_config.network.raw_packet.dropped metric.

hash: compute file hashes

Use hash to enrich an event with cryptographic hashes of a file referenced in the triggering event. This is useful for threat intelligence matching and forensic analysis.

When to use it

• Hash a binary at exec time before it is deleted or modified.
• Hash a file opened for write to correlate with known malware signatures.

Parameters

Supported algorithms

Hashes are computed by the Agent hash resolver and may include MD5, SHA1, SHA256, and SSDEEP, depending on Agent configuration. Results appear in the *.hashes field of the file event (for example, exec.file.hashes). To change the algorithms used, update runtime_security_config.hash_resolver.hash_algorithms in system-probe.yaml or set DD_RUNTIME_SECURITY_CONFIG_HASH_RESOLVER_HASH_ALGORITHMS. See Workload Protection Agent configuration for all hash resolver parameters.

Example

rules:
  - id: hash_dropped_binary
    expression: exec.file.path startswith "/tmp/" && exec.file.name not in ["systemd"]
    actions:
      - hash:
          field: exec.file
          max_file_size: 10485760  # 10 MB

log: write to Agent logs

Use log to emit a structured message to the Runtime Security Agent log when a rule fires. This is helpful for debugging custom rules or auditing rule triggers without generating a full security signal.

When to use it

• Debug rule logic during development.

Parameters

Example

rules:
  - id: log_sensitive_file_access
    expression: open.file.path startswith "/etc/"
    actions:
      - log:
          level: warning
          message: "Suspicious file access detected on sensitive path"

coredump: capture forensic state

Use coredump to snapshot internal Agent state at the time of a rule match. The dump is gzip-compressed (unless disabled) and attached to the security event.

When to use it

• Mostly used for debug purposes.
• Capture internal context caches such as process tree, mount table, or dentry cache state alongside the triggering event.

Platform

Linux only.

Parameters

At least one of process, mount, or dentry must be set to true.

Example

rules:
  - id: capture_forensic_state
    expression: exec.file.path startswith "/tmp/" && process.container.id != ""
    actions:
      - coredump:
          process: true
          mount: true
          dentry: true
          no_compression: false

Combining actions

A single rule can chain multiple actions. They execute in list order when the rule matches:

rules:
  - id: detect_and_respond
    expression: exec.file.path == "/tmp/payload"
    actions:
      - set:
          name: payload_seen
          value: true
      - hash:
          field: exec.file
      - log:
          level: info
          message: "Payload executed, hashing and killing"
      - kill:
          signal: SIGKILL
          scope: process

Typical patterns:

Platform summary

Validation rules

The Agent validates actions at policy load time:

• One action type per list item: set and kill cannot appear in the same action block.
• Required fields: for example, kill.signal, log.level, network_filter.filter.
• Enforcement gate: kill and network_filter require enforcement to be enabled.
• Event type compatibility: network_filter requires the raw_packet event type; hash.field must be compatible with the rule’s event type.