[Security][CPS] Document detection rule behavior and correct app availability

explore-analyze/alerting/alerts/alerting-setup.md

@@ -158,12 +158,4 @@ serverless: preview
 stack: unavailable
 ```
 
-When [{{cps}}](/explore-analyze/cross-project-search.md) is enabled and you have [linked projects](/deploy-manage/cross-project-search-config/cps-config-link-and-manage.md), alerting rules query data across linked projects based on the **space-level {{cps}} scope**. You cannot set a {{cps}} scope on individual rules.
-
-When you open a rule to create or edit it, the [{{cps-init}} scope selector](/explore-analyze/cross-project-search/cross-project-search-manage-scope.md#cps-in-kibana) in the header shows the current {{cps}} scope but is read-only. To change which projects rules query, update the [{{cps}} scope configured for the space](/deploy-manage/cross-project-search-config/cps-config-access-and-scope.md#cps-default-search-scope).
-
-For {{esql}} rules, you can use [`SET project_routing`](/explore-analyze/cross-project-search/cross-project-search-project-routing.md) in the rule query to target specific linked projects, overriding the space-level scope. For non-{{esql}} rules that use index patterns, you can use [qualified index expressions](/explore-analyze/cross-project-search/cross-project-search-search.md#search-expressions) to scope the rule to specific projects.
-
-:::{note}
-{{ml-cap}} rules don't support {{cps}}. {{ml-cap}} rules search data in the origin project only.
-:::
+When [{{cps}}](/explore-analyze/cross-project-search.md) is enabled, alerting rules query linked projects using the space-level scope. For how that scope works and which rule types can override it, refer to [{{cps-cap}} scope for rules](/explore-analyze/alerting/alerts/create-manage-rules.md#cps-scope-for-rules).

explore-analyze/alerting/alerts/create-manage-rules.md

@@ -49,14 +49,7 @@ serverless: preview
 stack: unavailable
 ```
 
-When [{{cps}}](/explore-analyze/cross-project-search.md) is enabled and you have [linked projects](/deploy-manage/cross-project-search-config/cps-config-link-and-manage.md), alerting rules query data across linked projects based on the **space-level {{cps}} scope**. You cannot set a {{cps}} scope on individual rules.
-
-When you open a rule to create or edit it, the [{{cps-init}} scope selector](/explore-analyze/cross-project-search/cross-project-search-manage-scope.md#cps-in-kibana) in the header shows the current {{cps}} scope but is read-only. To change which projects rules query, update the [{{cps}} scope configured for the space](/deploy-manage/cross-project-search-config/cps-config-access-and-scope.md#cps-default-search-scope).
-
-For {{esql}} rules, you can use [`SET project_routing`](/explore-analyze/cross-project-search/cross-project-search-project-routing.md) in the rule query to target specific linked projects, overriding the space-level scope. For non-{{esql}} rules that use index patterns, you can use [qualified index expressions](/explore-analyze/cross-project-search/cross-project-search-search.md#search-expressions) to scope the rule to specific projects.
-
-:::{note}
-{{ml-cap}} rules don't support {{cps}}; they search data in the origin project only. Other features also have limited or no {{cps}} support. For details, refer to [{{cps-cap}} availability by app](/explore-analyze/cross-project-search/cross-project-search-manage-scope.md#cps-availability).
+:::{include} /solutions/_snippets/cps-sec-obs-rules.md
 :::
 
 ## Create and edit rules [create-edit-rules]

explore-analyze/cross-project-search/_snippets/cps-availability-security-apps.md

@@ -1,15 +1,33 @@
-{{elastic-sec}} apps have partial {{cps-init}} support. The following features work across linked projects:
+{{elastic-sec}} apps have partial {{cps-init}} support. The following table shows, for each app, whether the {{cps-init}} scope selector is available and whether you can override that scope in a query. **Read-only** means the app uses the [space default](/deploy-manage/cross-project-search-config/cps-config-access-and-scope.md#cps-default-search-scope) and you can't change it from the header.
 
-- **Timeline:** Tables display documents from linked projects. Actions that don't apply to remote documents are disabled.
-- **Alert, event, and attack flyouts:** Flyouts render correctly for documents from linked projects. Remote documents are clearly identified, and actions that don't apply to remote documents are hidden or disabled. Investigate in Timeline remains available.
-- **Dashboards:** The Detection & Response and Data Quality dashboards support {{cps-init}}.
-- **Intelligence:** Threat intelligence indicator searches support {{cps-init}}.
+<!-- TODO: After https://github.com/elastic/docs-content/pull/7814 merges, restore the link on "{{ml-cap}}" "read data from linked projects" to /explore-analyze/machine-learning/anomaly-detection/ml-ad-run-jobs.md#ml-ad-cps-scope. -->
+<!-- TBD scope (confirm with Security): Timeline, flyouts, Dashboards, Intelligence, and Defend/Osquery are listed as Read-only (space default). Confirm whether any of these use the session selector (Editable) or search all linked projects. Entity store: confirm federated read is every linked project, not space-scoped. -->
 
-The following features remain scoped to the origin project:
+| App | {{cps-init}} scope selector | Query-level overrides |
+| --- | --- | --- |
+| **Alert, event, and attack flyouts** | Read-only | Not available |
+| **Alerts** | Not available | Not available |
+| **Attack Discovery** | Not available | Not available |
+| **Cases** | Not available | Not available |
+| **Dashboards** (Detection & Response, Data Quality) | Read-only | Not available |
+| **Detection rules** | Read-only | Available |
+| **{{elastic-defend}} and Osquery** | Read-only | Not available |
+| **Entity store** | Not available | Not available |
+| **Explore page** | Read-only | Not available |
+| **Intelligence** | Read-only | Not available |
+| **{{ml-cap}}** | Read-only | Not available |
+| **Overview page** | Read-only (event widgets); not available (alert widgets) | Not available |
+| **SIEM Readiness** | Not available | Not available |
+| **Timeline** | Read-only | Not available |
+| **Value report** | Not available | Not available |
 
-- **Alerts:** The Alerts page does not display remote alerts from linked projects.
-- **Explore page:** Host, network, and user exploration searches are scoped to the origin project only.
-- **Entity store:** Entity risk scoring and entity profiles do not include data from linked projects.
-- **Attack Discovery**: AI-generated attack discoveries are based on alerts from the origin project only.
-- **Overview**: The Security Overview page reflects data from the origin project only.
-- **Defend and Osquery**: Elastic Defend and Osquery are scoped to the origin project only. Defend and Osquery are managed through Fleet, meaning their configuration is tied to a single project. Endpoint artifacts, policies, response actions, and Osquery saved queries and packs are managed per project and are not shared across linked projects.
+Some apps have additional limitations:
+
+- **Alert, event, and attack flyouts:** Documents from linked projects are clearly identified. Actions that don't apply to these documents are hidden or disabled. Investigate in Timeline remains available. Session View isn't available for documents from linked projects.
+- **Alerts:** The Alerts page shows alerts generated by origin project rules, including those created from linked-project data. It doesn't show alerts that a linked project generated on its own.
+- **Cases:** You can't attach an alert or event from a linked project to a case.
+- **Detection rules:** {{esql}} rules support `SET project_routing`. For non-{{esql}} rules that use index patterns, you can use [qualified index expressions](/explore-analyze/cross-project-search/cross-project-search-search.md#search-expressions). Origin rules write alerts to the origin project. The **Max alerts per run** limit applies across the projects the rule queries. A rule searches only the linked projects the user who last saved it can access. For details, refer to [{{cps-cap}} and detection rules](/solutions/security/detect-and-alert/cross-project-search-detection-rules.md).
+- **{{elastic-defend}} and Osquery:** The **Endpoints** page, host details, **Response actions history**, and Osquery query results include data from linked projects. Policies, artifacts, response action dispatch, and Osquery saved queries and packs stay per project because they're managed through Fleet.
+- **Entity store:** Origin profiles include entities from every linked project. Each project still builds its own store, and risk scoring stays on the origin project. A host that appears in more than one project isn't combined into a single entity at the origin.
+- **{{ml-cap}}:** {{anomaly-detect-cap}} job {{dfeeds}} can read data from linked projects. Jobs and results are stored on the origin project. {{ml-cap}} rules alert on those stored results, including anomalies produced from linked-project data.
+- **Timeline:** Tables display documents from linked projects. Actions that don't apply to documents in linked projects are disabled.

solutions/_snippets/cps-sec-obs-rules.md

@@ -1,10 +1,13 @@
-
 When [{{cps}}](/explore-analyze/cross-project-search.md) is enabled and you have [linked projects](/deploy-manage/cross-project-search-config/cps-config-link-and-manage.md), rules query data across linked projects based on the **space-level {{cps}} scope**.
 
-For how {{cps}} applies when you create or edit rules (space-level scope, the read-only scope selector, and query-level overrides) refer to [{{cps-cap}} availability by app](/explore-analyze/cross-project-search/cross-project-search-manage-scope.md#cps-availability). 
+When you create or edit a rule, the [{{cps-init}} scope selector](/explore-analyze/cross-project-search/cross-project-search-manage-scope.md#cps-in-kibana) in the header shows the current {{cps}} scope but is read-only. To change which projects most rules query, update the [{{cps}} scope configured for the space](/deploy-manage/cross-project-search-config/cps-config-access-and-scope.md#cps-default-search-scope).
+
+You can't select a {{cps}} scope for an individual rule in the header. These rule types can still control which projects they query:
+
+- **{{esql}} rules:** Add [`SET project_routing`](/explore-analyze/cross-project-search/cross-project-search-project-routing.md) at the start of the rule query to override the space-level scope.
+- **Rules that use index patterns:** Use [qualified index expressions](/explore-analyze/cross-project-search/cross-project-search-search.md#search-expressions) in the index pattern to target specific projects.
+- **{{ml-cap}} rules:** These rules alert on {{anomaly-detect}} results stored on the origin project. {{anomaly-jobs-cap}} can read linked-project data; jobs and results stay on the origin.
 
-For prerequisites such as linking projects and configuring default scope, refer to [{{cps-cap}}](/explore-analyze/cross-project-search.md) and [Configure {{cps}} access and scope](/deploy-manage/cross-project-search-config/cps-config-access-and-scope.md). 
+<!-- TODO: After https://github.com/elastic/docs-content/pull/7814 merges, restore the link on "can read linked-project data" to /explore-analyze/machine-learning/anomaly-detection/ml-ad-run-jobs.md#ml-ad-cps-scope. -->
 
-:::{note}
-{{ml-cap}} rules don't support {{cps}}; they search data in the origin project only. Other features also have limited or no {{cps}} support. For details, refer to [{{cps-cap}} availability by app](/explore-analyze/cross-project-search/cross-project-search-manage-scope.md#cps-availability).
-:::
+For prerequisites such as linking projects and configuring default scope, refer to [](/explore-analyze/cross-project-search.md) and [](/deploy-manage/cross-project-search-config/cps-config-access-and-scope.md).

solutions/security/detect-and-alert/advanced-data-source-configuration.md

@@ -15,11 +15,11 @@ These pages cover deployment-level data settings that affect detection rule beha
 
 Most users don't need these pages during initial setup. Review them if any of the following apply to your environment:
 
-**[{{ccs-cap}} and detection rules](/solutions/security/detect-and-alert/cross-cluster-search-detection-rules.md)**
-:   Relevant if your data is spread across multiple {{es}} clusters and you need detection rules on one cluster to query indices on another. Covers establishing trust between clusters, remote cluster connections, and how to reference remote indices in rule index patterns. {{stack}} only.
+**[{{ccs-cap}} and detection rules](/solutions/security/detect-and-alert/cross-cluster-search-detection-rules.md)** {applies_to}`stack: ga`
+:   Relevant if your data is spread across multiple {{es}} clusters and you need detection rules on one cluster to query indices on another. Covers establishing trust between clusters, remote cluster connections, and how to reference remote indices in rule index patterns.
 
-**[{{cps-cap}} and detection rules](/solutions/security/detect-and-alert/cross-project-search-detection-rules.md)**
-:   Relevant if you use {{cps}} to query data across linked {{serverless-short}} projects. Explains how detection rules use the space-level {{cps}} scope and how to use project routing to target specific projects. {{serverless-short}} only.
+**[{{cps-cap}} and detection rules](/solutions/security/detect-and-alert/cross-project-search-detection-rules.md)** {applies_to}`serverless: preview`
+:   Relevant if you use {{cps}} to query data across linked {{serverless-short}} projects. Explains which projects a rule searches, where its alerts are stored, and how the alert limit applies across them.
 
 **[Using logsdb index mode with {{elastic-sec}}](/solutions/security/detect-and-alert/using-logsdb-index-mode-with-elastic-security.md)**
 :   Relevant if your indices use logsdb index mode (enabled by default in {{serverless-short}}). Explains how synthetic `_source` reconstruction can affect field formatting in alerts and rule queries, and what to watch for when writing rules against logsdb-backed indices.

solutions/security/detect-and-alert/common-rule-settings.md

@@ -104,6 +104,8 @@ Configure these settings by clicking **Advanced settings** in the **About rule**
 **Max alerts per run** (optional)
 :   Specify the maximum number of alerts the rule can create each time it executes. Default is 100.
 
+    {applies_to}`serverless: preview` When {{cps}} is enabled, this limit covers the combined results from every project the rule queries in that run, rather than each project separately. By default, that's the space-level scope, unless you override it in the query. Refer to [{{cps-cap}} and detection rules](/solutions/security/detect-and-alert/cross-project-search-detection-rules.md#cps-rules-max-alerts).
+
 ::::{admonition} System-level alert limit
 The `xpack.alerting.rules.run.alerts.max` [{{kib}} setting](kibana://reference/configuration-reference/alerting-settings.md) acts as a system-level limit on alerts per rule execution, and can supersede a security rule's **Max alerts per run** setting. If a rule's **Max alerts per run** value exceeds `xpack.alerting.rules.run.alerts.max`, the lower system setting takes precedence and the rule will not generate more alerts than it allows.
 ::::

solutions/security/detect-and-alert/cross-project-search-detection-rules.md

@@ -4,7 +4,7 @@ applies_to:
   stack: unavailable
 products:
   - id: security
-description: Learn how detection rules work with cross-project search to query data across linked projects.
+description: With cross-project search, origin detection rules query linked projects, write alerts on the origin, and apply the max-alerts limit across the combined scope.
 ---
 
 # {{cps-cap}} and detection rules [sec-rules-cross-project-search]
@@ -14,6 +14,33 @@ description: Learn how detection rules work with cross-project search to query d
 
 If your data spans ECH, ECE, ECK, or self-managed clusters rather than linked {{serverless-short}} projects, refer to [{{ccs-cap}} and detection rules](/solutions/security/detect-and-alert/cross-cluster-search-detection-rules.md) instead.
 
+## Where detection alerts are stored [cps-rules-scope-and-alerts]
+
+The rule writes every alert it generates to the origin project, no matter which project the matching events came from.
+
+This lets one project hold your detections and your analysts' alert triage while the data stays in the projects that produce it. It also means the origin project's **Alerts** page shows every alert your origin project rules generated, but not every alert in your organization. Rules that run independently on a linked project write their alerts to that project, and the origin project's **Alerts** page doesn't read them.
+
+To confirm which projects a rule covered when it created an alert, use the {{cps-init}} scope fields described in [{{cps-cap}} context in alerts and the event log](#cps-context-in-alerts).
+
+## Which linked projects a rule can access [cps-rules-api-key]
+
+Detection rules use the same API key model as other {{serverless-short}} alerting rules. The rule can search only the linked projects the user who last saved it can access. For how keys are created, how role changes apply, and how to update a key, refer to [](/explore-analyze/alerting/alerts/rules-and-elastic-cloud-api-keys.md).
+
+### When a rule searches the origin project only [cps-rules-origin-only-key]
+
+If you create or update a rule through the API with an {{es}} API key, the rule keeps that credential and searches the origin project only:
+
+- If the origin project has no matching indices, the rule doesn't run and its last-run status shows a warning.
+- If those patterns exist on the origin, the rule still runs and reports success. The last-run status doesn't indicate that linked projects were skipped.
+
+Plan for this when you migrate rules from another environment or create rules through automation. Rules still running on an {{es}} API key are tagged **Missing {{ecloud}} API Key** on the **{{siem-rules-ui}}** page.
+
+## How the alert limit applies across linked projects [cps-rules-max-alerts]
+
+The **Max alerts per run** [advanced setting](/solutions/security/detect-and-alert/common-rule-settings.md#rule-ui-advanced-params) limits the number of alerts a rule creates in a single execution. Under {{cps}}, that limit covers the combined results from every project the rule queries in that run, rather than each project separately. By default, the rule queries the origin project and all linked projects in the space-level scope. The default limit is 100.
+
+A rule that stayed under the limit on a single project can reach the limit after you link projects, which leaves matching events without alerts. Review the limit for rules that run across a broad scope. To search fewer projects, add [`SET project_routing`](/explore-analyze/cross-project-search/cross-project-search-project-routing.md) at the start of the **{{esql}} query**, or enter a [qualified index expression](/explore-analyze/cross-project-search/cross-project-search-search.md#search-expressions) in **Index patterns**, instead of raising the limit.
+
 ## {{cps-cap}} context in alerts and the event log [cps-context-in-alerts]
 
 When a detection rule runs with {{cps}} enabled, the scope in effect at execution time is recorded on generated alerts and in rule execution events. During investigations, use the scope and linked project fields on the alert or in the event log to confirm which linked projects were in scope when an alert was created.