diff --git a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md
index a5533642c30..5d1d086c93c 100644
--- a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md
+++ b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md
@@ -55,7 +55,11 @@ When ownership is known, the engine can route findings to the right team instead
 
 ## Filter findings by runtime signals
 
-When [Runtime Package Prioritization][4] is enabled, Datadog adds the runtime signals it observes to container image vulnerability findings for packages installed by an operating system package manager (`apt`, `yum`, or `apk`). Search, filter, and group by these tags:
+Datadog adds the runtime signals it observes to vulnerability findings. Use these signals in the [Vulnerability Explorer][11], combined with any other criteria.
+
+### Package is running
+
+When [Runtime Package Prioritization][4] is enabled, Datadog adds package-level runtime signals to container image vulnerability findings for packages installed by an operating system package manager (`apt`, `yum`, or `apk`). Search, filter, and group by these tags:
 
 | Signal | Tag |
 |---|---|
@@ -65,7 +69,7 @@ When [Runtime Package Prioritization][4] is enabled, Datadog adds the runtime si
 
 Datadog adds a tag when it observes a signal. An absent tag means Datadog did not observe the signal; it does not mean the package is unused. Use the tags to prioritize what to fix first, not to rule findings out.
 
-Use the tags in the [Vulnerability Explorer][11], combined with any other criteria. For example, high and critical vulnerabilities that are running and have a fix available:
+For example, high and critical vulnerabilities that are running and have a fix available:
 
 ```
 @risk.is_package_running:true @severity:(high OR critical) @remediation.is_available:true
@@ -73,6 +77,36 @@ Use the tags in the [Vulnerability Explorer][11], combined with any other criter
 
 Signals persist for the lifetime of an image version: after a package is observed running, findings for that image keep the signal. Because container images are immutable, the signal reflects what has run in that image. When the image is no longer deployed, its findings age out and close.
 
+### Image is running
+
+Datadog adds the **Container Image Running** signal to every container image vulnerability finding, with no additional Agent configuration. Search, filter, and group by this tag:
+
+| Signal | Tag |
+|---|---|
+| Image detected running in the last 12 hours | `@risk.is_image_running:true` |
+
+The tag is always `true` or `false` on container image findings, and absent on host, host image, and serverless findings. To prioritize running images across all asset types, exclude what is known to be stopped:
+
+```
+-@risk.is_image_running:false
+```
+
+For a window other than 12 hours, query `@risk_details.is_image_running.evidence.detected_at`, the time of the last detection in epoch milliseconds. This field has no facet and is independent of `@risk.is_image_running`.
+
+How Datadog detects a running image depends on how the image is scanned:
+
+| | Agent | Agentless |
+|---|---|---|
+| **Requires** | [Cloud Security vulnerability scanning][14] and [container monitoring][12] enabled on the Agent. | [Agentless Scanning][13] on the cloud account. |
+| **Registries** | Any. | Amazon ECR, Azure Container Registry, or Google Artifact Registry. See [compatibility][15]. |
+| **Source** | [Live Containers][12] reporting. | The cloud provider's service inventory, read at scan time. |
+
+Without container monitoring, or for an image in an unsupported registry, the tag reads `false`.
+
+Each detection restarts the 12-hour window, so a continuously running image does not read `false`. Nothing reports a stop and detection is periodic, so act on `true` and treat `false` as weaker evidence, especially for short-lived workloads such as CI jobs. The signal attaches to a specific image digest and does not change severity.
+
+The severity breakdown shows how long ago Datadog last detected the image running. When the tag is `true`, the vulnerability side panel lists that image's containers from [Live Containers][12], including ones that have since exited. Live Containers does not monitor Agentless-scanned workloads, so no containers appear for them.
+
 ## Get started
 
 1. Deploy the Datadog Agent, version **7.79.0** or later, with Cloud Security enabled. On Kubernetes, use **7.81.0** or later for the most complete signal coverage. See [Setting Up Cloud Security][3].
@@ -94,3 +128,7 @@ Signals persist for the lifetime of an image version: after a package is observe
 [9]: /security/cloud_security_management/setup/agent/docker/#runtime-package-prioritization-preview
 [10]: /security/cloud_security_management/setup/agent/linux/#runtime-package-prioritization-preview
 [11]: https://app.datadoghq.com/security/csm/vm
+[12]: /containers/
+[13]: /security/cloud_security_management/setup/agentless_scanning/
+[14]: /security/cloud_security_management/vulnerabilities/
+[15]: /security/cloud_security_management/setup/agentless_scanning/compatibility/