Signals

What is a Signal?

A Signal is a timestamped, static record that a detection rule produces when it matches activity in your environment. Signals capture what fired, why it fired, and which entities were involved, providing the raw detection data that the clustering engine uses to build Alerts.

Signals are the direct output of Analytics-Based Alerting (ABA) detection rules. Every time a rule detects a match, it creates a Signal. A Signal is a standalone, immutable record that doesn’t change after creation.

What a Signal captures

Each Signal records the following at the moment of detection:

• Detection source - The event source or integration that generated the underlying log data (for example, CrowdStrike Falcon, Okta, or a SIEM (InsightIDR) endpoint agent).
• Detection rule - The rule that matched and its associated MITRE ATT&CK tactic.
• Key entities - The users, assets, and IP addresses involved in the detected activity.
• Evidence - The log payload and matched keys that triggered the rule.
• Timestamp - When the detection event occurred.
• Severity - The priority level that the detection rule assigned.

Signals and Alerts

Once your organization is migrated to Agentic SOC, the AI clustering engine automatically groups every Signal into an Alert. You don’t need to manually promote Signals to Alerts. This happens continuously and automatically. No Signal ever sits unclustered. If no existing open Alert is a strong enough match, the engine creates a new Alert and makes that Signal its first member.

The Alert is where investigation and triage work takes place. The Signals page is a reference layer that lets you view and search the individual detection events that make up your Alerts.

View the Signals page

From the left navigation menu, select Signals. The Signals page displays a table of all Signals generated in your environment, ordered by creation time.

Each row in the Signals table shows:

• Signal name - The name of the detection rule that generated the Signal.
• Severity - The priority level of the Signal.
• Source - The event source or integration.
• Created - The date and time the Signal was created.
• Alert - A link to the Alert that this Signal has been clustered into.
• Key entities - The users and assets identified in the Signal.

From the Signals page, you can:

• Inspect Signal details - Select any row to open the Signal detail panel, which shows the full detection evidence: the rule logic that fired, the matched log payload in table or JSON format, and the key entities involved.
• Pivot to Log Search - From the Signal detail panel, click View Log Entry to open the associated log in Log Search with the relevant log set and time range pre-selected.
• Search and filter - Narrow your view using the filters and query bar.

Search for Signals

To narrow your view of Signals, apply filters at the top of the Signals page. You can combine multiple filters to focus on the Signals most relevant to you.

Available filters:

• Date Created - Filter for Signals created within a specific time range.
• Severity - Filter by Informational, Low, Medium, High, or Critical.
• Source - Filter by the event source or integration that generated the Signal.
• Detection Rule - Filter by the name of the detection rule.
• Alert - Filter by the Alert ID that the Signal belongs to.
• Key Entity - Filter by a specific user, asset, or IP address.
• MITRE ATT&CK Tactic - Filter by a specific MITRE ATT&CK tactic.

Use the query bar

You can also enter a query using Log Entry Query Language (LEQL) in the query bar to perform more precise searches across Signal fields. After entering your query, click Apply.

View Signal details

Select any row in the Signals table to open the Signal detail panel. The detail panel shows the full detection evidence for that Signal, including the rule logic, the matched log payload, and the key entities. To navigate directly to the Alert that contains this Signal, click the linked Alert ID.

Clustering: Signals into Alerts

Clustering is the process by which the Agentic SOC AI engine groups related Signals together into a single Alert. Instead of presenting each detection event as a separate work item, clustering surfaces the bigger picture, combining Signals that belong to the same attack pattern, actor, or incident so your team can investigate the full story in one place.

Why clustering matters

Modern attacks rarely generate just one detection event. A credential compromise might first appear as a suspicious login Signal, followed by a lateral movement Signal, and then a data staging Signal, all involving the same user across a short time window. Without clustering, these arrive as three separate items, each requiring independent triage.

Clustering connects those Signals into a single Alert for:

• Lower Alert volume - Clustering consolidates related detections instead of presenting them individually.
• Preserved context - The full sequence of activity stays visible in one investigation unit.
• Faster triage - Analysts and the AI agent work from a complete picture instead of fragments.
• Surfaced patterns - The clustering engine identifies relationships that might not be obvious when you review Signals one by one.

How clustering works

The clustering engine evaluates every new Signal as it arrives and determines which existing open Alert, if any, it belongs to. If no suitable Alert exists, the engine creates a new Alert with that Signal as its first member.

The engine groups Signals together when they share significant overlap across one or more of these dimensions:

• Shared entities - The same user account, asset, IP address, or process appears in multiple Signals.
• Temporal proximity - The Signals occurred within a short time window relative to each other.
• Source correlation - Signals originate from the same integration or the same attack surface (for example, multiple cloud identity events for the same tenant).
• Semantic similarity - The detection rules describe closely related behavior, for example, two rules that both detect credential-stuffing variations. The engine uses a combination of these factors to score similarity between detection events. When the similarity score exceeds the clustering threshold, the engine adds the Signal to an existing Alert. The engine can group up to 1,000 Signals into a single Alert.

Clustering for all other integrations

For Signals from integrations other than Microsoft, CrowdStrike Falcon, and SentinelOne, such as Okta, Rapid7 native endpoint detections, or other third-party sources, clustering still occurs. The clustering engine groups related Signals into Alerts and extracts key entities. However, these Alerts don’t receive a full AI investigation.

Your MDR team reviews these Alerts using the clustered context and entity data. Automated rules continue to run on these Alerts and may update disposition or status based on their configured logic.

What customers see for these Alerts

The Alert Details page for non-autonomously investigated Alerts displays 5 tabs: Evidence, Timeline, Threat Intelligence, Related Activity, and Audit Log. The page omits the AI Overview and Playbook tabs because no AI investigation ran. No AI-generated narrative or determination exists. Analysts build their understanding directly from the Evidence and Timeline tabs.

This differs from the experience for autonomously investigated Alerts, where the AI Overview tab provides a ready-made summary and the Playbook makes the full investigation transparent. Customers with a mix of integration sources see both experiences across their Alert queue, depending on which integration generated the underlying Signals.

Clustering outcomes at a glance