---
title: Respond to Threats
description: >-
  Terminate processes and containers or block network traffic with automated and
  manual Workload Protection response actions.
breadcrumbs: Docs > Datadog Security > Workload Protection > Respond to Threats
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Respond to Threats

{% callout %}
# Important note for users on the following Datadog sites: app.ddog-gov.com, us2.ddog-gov.com

{% alert level="danger" %}
This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site.md). ({% placeholder "user-datadog-site-name" /%}).
{% /alert %}

{% /callout %}

Workload Protection acts on threats by terminating processes and containers or blocking network traffic. The Datadog Agent runs these actions automatically when an Agent rule matches, or when you trigger them manually from a signal. Both methods depend on Agent enforcement.

## Response requirements{% #response-requirements %}

Response actions run in the Agent, so both automated and manual response depend on Agent settings and on the right RBAC permissions.

### Configure Agent enforcement{% #configure-agent-enforcement %}

Response actions use the `runtime_security_config.enforcement` settings in `/etc/datadog-agent/system-probe.yaml`. Enforcement is enabled by default, and the default settings are sufficient for most configurations. For the full parameter reference, see [Workload Protection Agent configuration](https://docs.datadoghq.com/security/workload_protection/setup/advanced_configuration.md).

These settings let you exclude binaries from response actions or control which rule sources can trigger them. By default, no binaries are excluded, and the `file` and `remote-config` rule sources are allowed.

### Response permissions{% #response-permissions %}

Both automated and manual response require specific [RBAC permissions](https://docs.datadoghq.com/account_management/rbac/permissions.md):

- The `security_monitoring_cws_agent_rules_actions` permission lets users configure automated response and manually respond to threats.
  - A user with the Datadog Admin role must create a role that includes this permission, then assign that role only to users who manage automated response or need to run manual response actions.
- The **Datadog Standard** role lets users create and update custom rules by default, as long as the changes do not modify **protection** settings on the rule. Users with the Standard role cannot enable a disabled rule that includes an automated response action and cannot use manual response actions.

## Automated response{% #automated-response %}

Automated response enables you to proactively block threats identified by Datadog Agent detection rules by terminating matching processes or containers.

Automated response splits the decision between two teams:

- Security decides which threats warrant an automated action.
- DevOps decides which applications and resources are resilient enough to withstand targeted protection.

The result is threat detection followed by immediate, targeted mitigation of high-confidence threats.

### Automated response availability{% #automated-response-availability %}

If automated response is active for an Agent rule, you can verify it in the rule:

1. In [Agent Configuration](https://app.datadoghq.com/security/workload-protection/agent-rules), open the rule.
1. Confirm that Automated response appears in the list of active actions.

To check whether automated response applies to a rule that generated a signal:

1. In [Signals](https://app.datadoghq.com/security), open the signal.
1. View Next Steps. If automated response is available for the matching rule, Proactively block threats displays Automated response enabled.

### Configure automated response on Agent rules{% #configure-automated-response-on-agent-rules %}

By default, all out-of-the-box (OOTB) Agent rules are active without automated response. You must configure the automated response action manually in order to kill processes.

#### Protection states{% #protection-states %}

An Agent rule can be in one of the following states:

- **Inactive:** The Agent does not monitor for the rule events and does not send detections to the Datadog backend.
- **Active:** This is the default setting for enabled rules. The Agent monitors for the enabled rule and displays detections in [Signals](https://app.datadoghq.com/security).
- **Active with automated response:** The Agent monitors for the enabled rule, terminates matching processes, and displays detections in [Signals](https://app.datadoghq.com/security).

{% alert level="info" %}
Automated response is applied to all threats detected after automated response is enabled. Automated response is not retroactive.
{% /alert %}

To enable automated response on an Agent rule:

1. In [Agent Configuration](https://app.datadoghq.com/security/workload-protection/agent-rules), open a rule. If there is no Automated response action in the Agent's actions section, then automated response is not available for that rule.

1. Click Edit.

1. Under Add actions for the agent to follow, select Automated response.

   {% image
      source="https://docs.dd-static.net/images/security/workload_protection/respond_and_report/automated_response_activation.18661cc9e878f2c382eb374c12ed0003.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/workload_protection/respond_and_report/automated_response_activation.18661cc9e878f2c382eb374c12ed0003.png?auto=format&fit=max&w=850&dpr=2 2x"
      alt="An Agent rule Protection section displaying the automated response action" /%}

1. Under Link the rule to policies, verify that the rule is Active in at least one policy.

1. Click Update Agent Rule.

### Review blocked attack attempts{% #review-blocked-attack-attempts %}

After automated response is enabled for an Agent rule, blocked threats appear in [Signals](https://app.datadoghq.com/security).

Any automated response is listed in the Response table, along with manually submitted responses.

## Manual response{% #response %}

Manual response lets you protect your infrastructure from the signal side panel after Workload Protection generates a [signal](https://docs.datadoghq.com/security/workload_protection/investigate_and_triage/security_signals.md). Use manual response if you do not want an Agent rule to terminate processes automatically.

{% image
   source="https://docs.dd-static.net/images/security/workload_protection/respond_and_report/response_actions.25e525258941ca93939a6c77b6444ee7.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/workload_protection/respond_and_report/response_actions.25e525258941ca93939a6c77b6444ee7.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="Response section showing isolate container and kill container actions with ISOLATED and KILLED statuses" /%}

### Additional requirements for manual response{% #additional-requirements-for-manual-response %}

Confirm that each environment with hosts or containers running the Workload Protection-enabled Agent meets these requirements:

- Datadog **Agent 7.78** or later on the hosts that should execute response actions.
- [**Remote Configuration**](https://docs.datadoghq.com/agent/remote_config.md?tab=configurationyamlfile) is enabled so response policies can be delivered to the Agent.
- Enforcement is enabled by default in `system-probe` as described in Configure Agent enforcement.

### Available actions{% #available-actions %}

The Agent supports the following **enforcement** action types:

#### Kill{% #kill %}

Terminate a malicious process or all processes in a compromised **container** (cgroup), depending on scope.

#### Network filter (network isolation){% #network-filter-network-isolation %}

Block network traffic using an eBPF-based filter (for example, drop egress to specific ports). Any isolation can be reverted.

Network isolation uses eBPF **Traffic Control** classifiers and raw packet programs. The Agent enables the required network probes by default in `event_monitoring_config.network` in `system-probe.yaml`.

### Action statuses{% #action-statuses %}

When a response action runs, the Agent records it in the Response table, along with automated responses. Each action has a status. The table below summarizes the main outcomes for each action type.

| Status                | Description                                                                                                                       | Kill | Network isolation |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ---- | ----------------- |
| `performed`           | The action completed successfully.                                                                                                | yes  | yes               |
| `partially_performed` | Part of the kill succeeded (for example, some processes terminated) but not all targets could be killed.                          | yes  |
| `removed`             | An isolation rule was **removed** from the current ruleset while it was present before—used when **reverting** network isolation. | yes  |
| `error`               | An error occurred during the response. The action failed and the process or container is still running or not isolated.           | yes  | yes               |
| `not_triggered`       | The Agent did not find the targeted resource. The container or process may have exited before the response action ran.            | yes  | yes               |

## Further reading{% #further-reading %}

Additional helpful documentation, links, and articles:

- [Workload Protection detection rules](https://docs.datadoghq.com/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md)
- [Setting up Workload Protection](https://docs.datadoghq.com/security/workload_protection/setup.md)
- [Workload Protection Agent configuration](https://docs.datadoghq.com/security/workload_protection/setup/advanced_configuration.md)
- [Detect Host and Container Compromises with Workload Protection](https://learn.datadoghq.com/courses/workload-protection-detect-compromises)