[Security Solution] [AI4SOC] Alerts from all removed integrations reappear after reinstalling a single integration

[pborgonovi]

Describe the bug:

When all integrations are removed from an AI for SOC project, the Alerts page is cleared (as expected). However, if the user reinstalls only one of the previous integrations, the Alerts page unexpectedly displays all alerts, including those from the integrations that are still removed. These unrelated alerts appear with an empty integration field.

Screen.Recording.2025-07-28.at.9.21.57.AM.mov

privateRuleRegistryAlertsSearchStrategy response logs: privateRuleRegistryAlertsSearchStrategy.json.txt

Kibana/Elasticsearch Stack version:

VERSION: 9.2.0
BUILD: 88867
COMMIT: a48f653d01e8a48d9e8d18d804a18cb9ff07744a

Functional Area (e.g. Endpoint management, timelines, resolver, etc.):

AI4SOC Alerts

Steps to reproduce:

1. Create an AI for SOC project with 3 integrations:

• SentinelOne
• Microsoft Sentinel
• CrowdStrike

2. Generate alerts for all three integrations.
3. Delete all 3 integrations from the project.
4. Go to the Alerts page:

• ✅ No alerts are shown — expected behavior.

5. Reinstall only the CrowdStrike integration.
6. Open the Alerts page again:

• ✅ CrowdStrike alerts are correctly displayed with the integration name.
• ❌ Alerts from SentinelOne and Microsoft Sentinel also reappear, even though these integrations are still removed.

Current behavior:

• Alerts from previously deleted integrations resurface after installing one unrelated integration.
• These alerts are incorrectly shown with no integration context.
• The behavior suggests that re-adding any integration triggers loading of all historical alerts, regardless of their origin.

Expected behavior:

Only alerts from currently installed integrations should be displayed after reinstallation.

Any additional context (logs, chat logs, magical formulas, etc.):

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[PhilippeOberti]

@pborgonovi thanks for opening this issue.

I read the description and unfortunately this is kind of expected with the current way the code is implemented. I think this is actually more a UIUX issue rather than a code issue.

Let me try to explain: the filter functionality of the page works in 2 ways:

• the KQL bar where users can enter a query they want to filter the page by
• the integration filter button to the left of the KQL bar

The way the integration filter button works is as follows:

• by default when loading the page, all integrations in the filter button are checked and we fetch all alerts
• when users click on the integration button, they can uncheck one or multiple integrations. We then filter out all the alerts that are generated by the rule that match the integration that was unchecked

In the case here, after we uninstall integrations, we load the alert summary page, and we see all alerts. Those matching the remaining integration(s) and those generated by integration(s) that have been uninstalled.

---

On one hand I can see how this is a bit confusing as we show data that the UI stipulates should not be shown...
On another hand, if we change that logic into the opposite that it works now (meaning we show only the alerts from the integration(s) that are selected), then users would never have a way to view alerts from uninstalled integrations.

Wouldn't we want them to be able to see the alerts that have been generated from old integrations?

[pborgonovi]

Hey @PhilippeOberti
I'm not sure I understood the filter part:

by default when loading the page, all integrations in the filter button are checked and we fetch all alerts
when users click on the integration button, they can uncheck one or multiple integrations. We then filter out all the alerts that are generated by the rule that match the integration that was unchecked

In this case, as there's only 1 integration there's also only 1 option in the filter as you can see below.
So, if I uncheck the installed Integrations, we keep showing the alerts from the removed ones.

Screen.Recording.2025-07-28.at.1.22.31.PM.mov

That's also a bit confusing if it's expected behavior as we don't even display the integration information in the alerts column.
(which may be part of our recent changes to fetch rule_id instead of id)

Wouldn't we want them to be able to see the alerts that have been generated from old integrations?

[PhilippeOberti]

Hey @pborgonovi,

Yup I agree that the UX here can be improved. With the current implementation here, users can still see alerts that were generated by an integration that was uninstalled. I believe this is a behavior that we'd want (?) as those alerts exist in the system. If we were to switch the filtering logic to make those alerts not appear, I could see users be surprised that they cannot access alerts that were generated and are in the system, just because they uninstalled an integration.
For me uninstalling integration has an impact on the future (meaning we're not going to generate new alerts), but not on the past (meaning we don't delete or hide alerts that were previously generated).

Ultimately, I believe this is a low to very low severity issue, as it feels to me that it's a bit of un edge case that users will uninstall integrations...
I do believe though that I need to discuss this with Bonnie and James when I'm back from vacation, as the UX can be improved.

Let me know if you agree! 😄

[pborgonovi]

Thanks @PhilippeOberti

I do agree with you. Let's then follow up on this when you're back.

cc @spong