Cross-project search and detection rules

When cross-project search is enabled and you have linked projects, rules query data across linked projects based on the space-level cross-project search scope. You can't set a cross-project search scope on individual rules.

When you create or edit a rule, the CPS scope selector in the header shows the current cross-project search scope but is read-only. To change which projects rules query, update the cross-project search scope configured for the space.

For ES|QL rules, you can use SET project_routing in the rule query to target specific linked projects, overriding the space-level scope. For non-ES|QL rules that use index patterns, you can use qualified index expressions to scope the rule to specific projects.

For prerequisites such as linking projects and configuring default scope, refer to Cross-project search and Configure cross-project search access and scope.

If your data spans ECH, ECE, ECK, or self-managed clusters rather than linked Serverless projects, refer to Cross-cluster search and detection rules instead.

A rule that runs on the origin project queries the origin project and every linked project in the space-level cross-project search scope. 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 scope fields described in Cross-project search context in alerts and the event log.

Detection rules use the same API key model as other Serverless alerting rules. When you create or edit a rule, Kibana creates an API key with a snapshot of that editor's role assignments. The rule can search only the linked projects those roles can access.

For how keys are created, how role changes apply, and how to update a key, refer to Rules and Elastic Cloud API keys in Serverless.

If you create or update a rule through the API with an Elasticsearch 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, but it searches the origin only. There's no warning for that.

Plan for this when you migrate rules from another environment or create rules through automation. Rules still running on an Elasticsearch API key are tagged Missing Elastic Cloud API Key on the Detection rules (SIEM) page.

The Max alerts per run advanced setting limits the number of alerts a rule creates in a single execution. Under cross-project search, that limit covers the combined results from the origin project and all linked projects in the space-level scope rather than each project separately. The default is 100.

A rule that stayed comfortably under the limit on a single project can reach it once you link projects, which leaves matches without alerts. Review the limit for rules that run across a broad scope, and consider narrowing the scope with project routing instead of raising the limit.

When a detection rule runs with cross-project search 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.

Scope fields are written at rule execution time, not added to existing documents later. You need linked projects, a configured space-level cross-project search scope, and at least one enabled detection rule that has run successfully with cross-project search enabled.

On alert documents, kibana.cps_scope.expression and kibana.cps_scope.linked_projects are present only when that run generated an alert. Alerts created before cross-project search was enabled are not updated retroactively.

On event log entries, kibana.cps_scope_expression and kibana.cps_scope_linked_projects are recorded for every cross-project search-scoped execution, including runs that created no alerts.

When a detection rule runs with cross-project search enabled, each generated alert can include:

For the full list of alert fields, refer to the alert schema.

Rule execution events in the event log index record the same scope and linked project information:

To find rule executions that ran with a particular scope, run a search against the event log in Dev Tools or your own API client. The following example returns recent detection rule execution events that include cross-project search scope fields:

GET .kibana-event-log-*/_search
{
  "size": 5,
  "query": {
    "match": { "kibana.cps_scope_expression": "_alias:*" }
  },
  "_source": [
    "event.action",
    "message",
    "kibana.cps_scope_expression",
    "kibana.cps_scope_linked_projects",
    "kibana.space_ids"
  ]
}
		

1. Change size to return more or fewer events.
2. Replace _alias:* with the scope you want to find. To match the scope from a specific alert, copy the value from that alert's kibana.cps_scope.expression field.
3. Edit the _source array to include the fields you need in the response.

This request searches the event log indices (.kibana-event-log-*) for documents that have a kibana.cps_scope_expression value. It limits the response to five events and returns only the fields listed in _source, including the cross-project search scope, linked projects, and space ID for each execution. The event log is a system index, so by default only users with a superuser role can run this search. For more example queries and details on required privileges, refer to the event log index.