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

[nastasha-solomon]

Summary

Contributes to #8050.

Corrects the cross-project search (CPS) availability information for Elastic Security apps and documents rule-level CPS behavior ahead of GA.

Previews

• CPS availability in Elastic Security apps - Corrected and expanded the availability list. (The same snippet also renders on Configure CPS.) Made the following changes to the section and moved the info into a table to align the format used for Kibana and Observability.

• CPS and detection rules — Expands the detection-rules row. The intro snippet also renders on Observability Create and manage rules, and states space default, read-only selector, and query-level overrides inline:

  • Which projects a rule searches and where alerts are stored - Origin rules search the space-level scope and write alerts to the origin. The origin Alerts page does not show alerts a linked project generated on its own.
  • Which linked projects a rule can access - Kibana creates an API key with a snapshot of the editor's role assignments. Elasticsearch API keys used through the API skip linked projects (with a matching-indices warning) or run origin-only with no warning.
  • How the alert limit applies across linked projects - Max alerts per run is a combined cap across the origin and linked projects in the space-level scope.
  • CPS context in alerts and the event log - Scope fields recorded on alerts and in the event log.

• Common rule settings - Max alerts per run notes that, with CPS enabled, the limit covers combined results from the origin and linked projects in the space-level scope, with a link to the full explanation.

Deliberately not included

The "Using cross-project search with Elastic Security" guidance page (item 2 of #8050) is not included as it's not a blocker to CPS GA'ing. It will be added in a separate PR.

Lifecycle note

CPS pages remain at serverless: preview. Flipping them to GA is intentionally left to a separate PR. The one inline {applies_to} tag added here, on Max alerts per run, will need to flip with them.

Generative AI disclosure

1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?

• Yes - Cursor + Claude Opus
• No

[github-actions]

Elastic Docs AI PR menu

Check the box to run an AI review for this pull request.

• Review docs changes (docs-review). Status: not started.

Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team.

[github-actions]

🔍 Preview links for changed docs

• explore-analyze/alerting/alerts/alerting-setup.md
• explore-analyze/alerting/alerts/create-manage-rules.md
• solutions/security/detect-and-alert/advanced-data-source-configuration.md
• solutions/security/detect-and-alert/common-rule-settings.md
• solutions/security/detect-and-alert/cross-project-search-detection-rules.md

[github-actions]

✅ Elastic Docs Style Checker (Vale)

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[shainaraskas]

hello thank you!

overall thoughts:

• I think it would be good if we could be clearer about when things use the space scope
• We can probably cut back/unify some of the info about API keys on rules - it reads as pretty cohesive between the two surfaces now and we should probably just document what is different about detection rules in this spot

[shainaraskas]

is this using the space scope?

[nastasha-solomon]

@PhilippeOberti @michaelolo24 does Timeline always use the space’s default CPS scope, or can it follow the CPS scope selector selection in the project's header? For reference, here's the latest draft.

[shainaraskas]

space scope?

[nastasha-solomon]

@chuddy-elastic who can clarify whether the threat intel features always use the space’s default CPS scope, or can follow the CPS scope selector selection in the project's header? For reference, here's the latest draft.

[shainaraskas]

also avoid remote

[shainaraskas]

looking nice! a couple of considerations for you about the table columns and some questions about rule scope.

the cutback on the API keys stuff for rules is looking especially nice 🎉

[shainaraskas]

🤔 if we can limit the scope with project routing, is this exactly true? or is it the scope of the query, which is by default the same as the space-level scope unless there's a query-level override?

[nastasha-solomon]

Hm, good callout. I'm unsure what the relationship is and if the setting supersedes the space-level scope and or query-level overrides. @chuddy-elastic can you answer this?

Claude edited this description as follows:

{applies_to}serverless: preview When {{cps}} is enabled, this limit is shared across every project the rule searched, not applied separately to each project. A query-level override (SET project_routing or a qualified index expression) changes which projects that execution searches; the limit still applies once. Refer to {{cps-cap}} and detection rules.

[shainaraskas]

is this stuff covered in the core alerting/rules docs?

[nastasha-solomon]

At the moment, it's not. @chuddy-elastic @tiamliu who would be able to provide this information for Kibana alerting v1 and Observability incident management?

[shainaraskas]

thank you for these edits! just a couple more comments, mostly around precision re: rule scope, and some stuff about making the snippet fit for purpose across its two homes :) ✅ anyway

[shainaraskas]

I think that this doesn't get to the heart of the takeaway, but is more like implementation detail. consider

Suggested change

	- **{{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.
	- **{{ml-cap}} rules:** These rules alert on {{anomaly-detect}} job results, so the job's scope determines what the rule can detect. To control which projects the job searches, set [`project_routing`](/explore-analyze/machine-learning/anomaly-detection/ml-ad-run-jobs.md) on the job's {{dfeed}}.

[shainaraskas]

this is not exactly true because not all rules allow query-level overrides. we prob want to lean on https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8064/explore-analyze/alerting/alerts/create-manage-rules#cps-scope-for-rules

[shainaraskas]

these are not the only ways

a) space scope
b) these two
c) ml job

consider linking up/out to wherever solutions/_snippets/cps-sec-obs-rules.md goes

[shainaraskas]

sorry I keep coming back to this single snippet.

The problem we have now is that it's being used to do two things:

1. explain availability/behavior here
2. act as a limitations list here (where it is pretty overwhelming)

... but it's not doing double duty as well because more things work now

I suggest that we do the following:

1. kill the snippet
2. put the content directly on Managing cross-project search scope in your project apps and rebrand as "support" rather than "limitations"
3. Create a mini list reduced to limitations, and put it on Configure cross-project search, and link across

shortlist of limitations might look like this

- **Alerts:** The Alerts page doesn't show alerts that a linked project generated independently. Only alerts created by origin project rules appear.
- **Attack Discovery:** Discoveries are based on origin project alerts only. Alerts from linked projects aren't included.
- **Cases:** You can't attach an alert or event from a linked project to a case.
- **Entity store:** A host that appears in more than one project isn't combined into a single entity at the origin. Risk scoring runs on the origin project only.
- **Flyouts:** Session View isn't available for documents from linked projects. Some actions are hidden or disabled.
- **{{elastic-defend}} and Osquery:** Policies, artifacts, response actions, and Osquery saved queries and packs can't be shared or managed across linked projects.
- **{{ml-cap}} rules:** {{ml-cap}} rules don't use the space-level {{cps}} scope. They use the scope of the underlying {{anomaly-detect}} job's {{dfeed}}, which might differ from the space default.
- **SIEM Readiness and Value report:** These features don't include data from linked projects.
- **Timeline:** Some actions are disabled for documents from linked projects.

[shainaraskas]

siiide note, I was doing a little poking around for another ml thing and I suspect that when i try to start a prebuilt job using this flow, it searches every linked project (doesn't use the space scope): https://www.elastic.co/docs/solutions/security/advanced-entity-analytics/anomaly-detection#manage-jobs

might be worth adding as a limitation and/or tweaking that page directly (or maybe it's a bug? :/)