Background detection is an AI-driven part of Cribl Guard that samples data in your Pipelines, scans it for sensitive data patterns, and surfaces findings. You then review findings, ignore them, or mitigate them by adding Guard rules. Background detection runs as part of Cribl Guard, so there is no separate feature to enable or disable.

Background detection also runs a preliminary scan before you enable Guard, so the Guard homepage can show you where sensitive data already reaches your Destinations and nudge you to enable protection.

Background detection works in two stages:

• Preliminary scan (before you enable Guard): Cribl Guard runs a lightweight scan that shows the amount and type of sensitive data reaching a Destination, even before you enable protection. Use this preliminary scan to see what Guard would catch, then enable Guard where it matters.
• Full background detection (after you enable Guard): Once Guard protects a Destination, background detection samples more data and produces detailed findings, including sampled events and recommended actions.

Background detection workflow at-a-glance:

1. Review the preliminary scan results on the Guard homepage to see where sensitive data reaches your Destinations.
2. Enable Cribl Guard on the Destinations where you want full protection and detection, then Commit & Deploy.
3. Review and act on findings from the Guard page (create rules, mark mitigated, or ignore).
4. Review the recommended actions that Cribl generates automatically for each detection, and apply them.
5. Optionally refine scope per Pipeline when needed.

Before You Start ​

• Environment: Background detection is available only in Cribl Stream, in the following deployment types:
  • Hybrid environments with Cribl-managed Cloud Workers (AWS-hosted Cloud Worker Group).
  • Cribl.Cloud-only environments (AWS-hosted Cloud Worker Group).
  • On-premises deployments.
• The preliminary scan runs without enabling Guard. Full background detection runs once Cribl Guard protects a Destination. Choose the AI model it uses from the Detection model drop-down at the top of the Guard page.
• Outbound connectivity: Your Leader Node must reach ai.cribl.cloud over outbound HTTPS to download the Named Entity Recognition (NER) model bundle and to send anonymized usage analytics. No event data or sensitive values are sent to this endpoint (see Data Privacy). In air-gapped or restricted-network environments, allow ai.cribl.cloud in your firewall or proxy.

How Background Detection Works ​

Background detection runs entirely on your Cribl Stream Worker Nodes, and no event data leaves your environment for inference. Detection runs in a separate process from your Pipeline processing, so it does not block your data-flow Worker Processes. The Cribl NER model runs locally on each Worker Node.

Cribl downloads the detection model bundle from ai.cribl.cloud to the Leader Node, which then distributes it to your Worker Nodes. For the connectivity this requires, see Before You Start.

Sampling ​

Background detection samples 1 in every 10 events. The sampling rate is fixed and not configurable, which keeps detection coverage consistent without overwhelming Worker Node resources. Cribl stores sampled events temporarily on the Worker Node and removes them automatically.

Data Privacy ​

Your event data never leaves your Cribl environment. All sampling, scanning, and NER inference happen locally on your Worker Nodes.

Cribl never receives your raw events, sampled events, detected values, or Pipeline names. Background detection communicates with ai.cribl.cloud for two purposes only:

• Model bundle download: Your Leader Node downloads the NER model bundle from ai.cribl.cloud. This is a download to your environment. No data about your events is sent in the request.
• Usage analytics: Cribl receives anonymized, aggregate counts only, such as the total number of detections and tokens processed. These counts contain no raw events, no sampled events, no detected values, and no Pipeline names.

See Sensitive Data Before You Enable Guard ​

Cribl Guard runs a preliminary scan so you can see the sensitive data reaching your Destinations before you enable Guard. The scan gives you an idea of how much sensitive data flows and which types Cribl detects, which helps you decide where to enable protection.

The preliminary scan:

• Runs automatically, without a separate opt-in or a Commit & Deploy step.
• Does not accrue charges. Cribl does not bill you for this initial scanning.
• Reports counts and types only. The scan surfaces the number and Datatype of detections. It does not store or display raw sensitive values.

Background detection processes events on the Worker Node using local regex rules and a Named Entity Recognition (NER) model. It records only detection counts and Datatypes, never raw sensitive values, and does not send sampled events to an LLM or a Custom AI Provider.

When background detection is active, Cribl shows an in-product notice. Detection models sample data streams locally to surface privacy risks, your data never leaves your Cribl environment, and any Pipeline changes require your approval.

On the Guard homepage, the Status column shows Clear when Cribl finds no sensitive data for a Destination, or Sensitive data detected when it does. When sensitive data reaches Destinations that Guard doesn’t protect yet, Guard also shows a nudge banner (for example, Sensitive data is flowing to 3 Destinations) with an Enable All button to enable protection for all affected Destinations.

The preliminary scan gives you a limited preview. After you enable Cribl Guard on a Destination, background detection samples more data and returns fuller, more detailed findings.

Select a Cribl AI Model ​

Background detection uses a Cribl AI model to identify sensitive data. To choose the model:

1. In your Cribl Workspace, select Cribl Stream.
2. Open the Guard page. At the top of the page, find the Detection model drop-down.
3. Select a Cribl AI model from the drop-down. For details on each option, see About Cribl Guard Models.
4. Select Commit & Deploy.

About Cribl Guard Models ​

Background detection uses a Cribl AI model to identify sensitive data. At the top of the Guard page, the Detection model drop-down lists the available models:

• cribl-privacy-2.0 (Balanced): A balanced default, and the best option for most users. It balances speed and detection depth.
• cribl-privacy-2.0-fast (Fast): A lightweight, speed-optimized model. Use this when compute efficiency, throughput, or footprint matters more than maximum detection depth.

These are not large-language models (LLMs). They are based on Named Entity Recognition (NER) models, which automatically scan text to identify and classify key information. The Cribl Guard AI models do not run data through any configured Custom AI Providers. Background detection uses Cribl-managed models only. You cannot connect a Custom AI Provider for background detection, and Cribl does not train these models on customer data.

Review and Act on Findings ​

This is the main workflow after background detection is on: see what was found, then create rules, mark as mitigated, or ignore. Findings are scoped to one Worker Group at a time, so start by selecting the Worker Group you want to review.

1. Open the Guard homepage and select the Worker Group whose findings you want to review.

2. Open the findings for that Worker Group. Either:

   • Select Review All in the Background Detections tile, or
   • Select the yellow detections count in the Background Detection column for a specific Pipeline.

3. Review the type of data found. Select a detection type (for example, IP Address) to open the details panel on the right.

   The details panel stacks two areas. At the top, the Recommendations section lists the actions that Cribl AI suggests for this detection. At the bottom, the Sampled Events table shows the detected values, highlighted in context. This area also has a Delete Events button that removes the sampled events, available when the selected time range is at least one day.

4. Act on the detection, either by applying a recommendation or manually via the three dots in the Actions column (or from the events viewer):

   • Create Guard Rule: Cribl Copilot opens with the sampled events and a prompt to create a Guard rule for the detection. Copilot generates a proposed rule that includes a name, regex pattern, and description. Review the proposed pattern against the sampled events, then save the rule to a Scanning Ruleset. To activate the rule, select Commit & Deploy from the save confirmation. Creating the rule alone does not protect data. Once the rule is activated, it masks matching sensitive data in future events.
   • Mark as Mitigated: Labels the finding as mitigated for history; does not change rules or Pipelines. Use this after you create a Guard rule.
   • Ignore Datatype: Cribl ignores future detections for this PII type. In the Ignore Datatype modal:
     • Under Apply to, choose this Pipeline, All Pipelines, or Custom to select specific Pipelines.
     • Optionally select a Reason for ignoring.
     • Optionally add a Filter pattern (regex) to ignore only detections whose entity values match that pattern, instead of ignoring every detection of this Datatype. For example, enter ^/src/ to ignore only values that start with /src/, while Cribl still surfaces other detections of the same Datatype. Cribl validates the pattern and flags an invalid regular expression. A filter pattern applies to detections recorded after you add it. Detections already recorded for this Datatype stay visible until they age out. Cribl retains detections for 7 days, then removes them automatically.

Recommended Actions ​

Cribl Guard analyzes recent detections and suggests how to act on each one. When you select a detection type, the suggestions appear in the Recommendations section. This section sits at the top of the details panel, ahead of the sampled events. Each recommendation pairs the detection with an action that Cribl AI suggests.

When you open the Findings view and select the New tab, Cribl loads recommendations for your recent detections. If a detection does not have recommendations yet, select Generate Recommendations in the Recommendations section to run the analysis. The section header shows when Cribl last analyzed the detection and includes an information tooltip that explains the suggestions.

If you’re using a custom AI model, Cribl Guard runs the analysis through the model you selected. If not, Cribl analyzes your data using the in-house, Cribl-managed model. For more information, see Custom AI Providers.

To review and apply recommendations:

1. Open the Guard homepage and select the Worker Group whose findings you want to review.
2. Go to the Findings view (for example, select Review All in the Background Detections tile or open findings from a Pipeline detection count), then select the New tab.
3. Select a detection type to open the details panel. The Recommendations section lists the suggested actions for that detection.
4. Apply the recommendations:
   • Select the action button on a single recommendation (for example, Create & Apply, Apply, or Mark as Ignored). See Recommendation Types.
   • Select Apply All in the section header to apply every recommendation for the detection.
   • On a new-rule or existing-rule recommendation, select Ignore to dismiss it without applying it.
   • Select Ignore Datatype in the section header to ignore future detections of the same Datatype.

Recommendations are available only in the product while you review a detection. Cribl does not save them as a separate downloadable report or history entry.

What Each Recommendation Shows ​

Each recommendation is a row in the Recommendations section. A row shows the rule name and, when applicable, the regex pattern the rule uses. You can check that pattern against the sampled events to confirm it captures the intended PII. New-rule recommendations also carry a purple New Rule tag.

For a false-positive recommendation, the row also shows why Cribl suggests ignoring the detection. When a Pipeline and entity combination contains both true and false positives, the recommendation can include a regex pattern so Cribl ignores only the values that match the pattern and keeps the true positives.

A single detection can produce more than one recommendation. For example, Cribl might link an existing rule for the samples it already covers and propose a new rule for the rest. Each recommendation is a separate row with its own action button, so you can apply them independently.

Validate a Recommendation ​

Before you apply a recommendation, confirm that its regex captures the data you want to protect:

1. In the detection details panel, select a recommendation to view its regex pattern.
2. Review the Sampled Events below the recommendation to see the data the pattern was derived from.
3. Confirm that the highlighted matches correspond to the sensitive data you expect to protect.
4. If the pattern is too broad or too narrow, select Mark as Ignored, then create a custom Guard rule instead.

Analysis States and the 24-Hour Limit ​

While the analysis runs, the Recommendations section shows Loading recommendations…. When it finishes, the section lists the recommendations for the selected detection. As you apply or dismiss recommendations, Cribl removes them from the section. When a detection has no recommendations yet, the section shows an empty state with a Generate Recommendations button.

Analysis runs only on detections from the last 24 hours for the selected Worker Group. You need at least one detection in the last 24 hours for recommendations to appear, and detections older than 24 hours are not analyzed. Older findings still appear in the Findings table, but they don’t receive recommendations.

The Recommendations section reflects the current analysis state:

Recommendation Types ​

Each recommendation row includes an action button. The button label and behavior depend on the recommendation type:

Scope and Limitations ​

Keep the following in mind as you review findings:

• One Worker Group at a time: Findings are scoped to the selected Worker Group. To review findings for a different Worker Group, select it from the Worker Group selector. There is no cross-group aggregate view.
• All detections appear: Background detection samples events after Guard rules on that Pipeline run, so it is designed to find sensitive data those rules miss. The Findings table still lists every detection type that the NER model surfaces, including Datatypes that already have a Guard rule elsewhere (for example, a rule in Knowledge that is not attached to this Pipeline). There is no filter to show only detections that have no matching Guard rule.
• Preliminary scan is a preview: The preliminary scan reports detection counts and Datatypes, but does not provide raw sensitive values or a rule-by-rule comparison of what Guard would catch. It gives you a high-level sense of the sensitive data in your environment before you enable protection. Full background detection provides fuller, more detailed findings.
• 7-day retention: Cribl retains detections for 7 days, then removes them automatically.
• 24-hour recommendation window: Cribl generates recommendations only for detections from the last 24 hours. Older findings still appear in the Findings table, but do not receive recommendations.

Alerting and Notifications ​

Background detection does not support configurable alerts or notifications. The detection count indicators on the Guard homepage and the Pipeline configuration page link you to the Findings page, but they are not configurable alerts. To check for new findings, review the Findings page periodically.

Refine the Scope of Background Detection ​

Background detection runs as part of Cribl Guard, but you can control where it runs per Pipeline. Use the Background Detection toggle in the Cribl Guard Function to include or exclude a Pipeline.

Turn Off for Specific Pipelines ​

To exclude Pipelines that carry highly sensitive or constrained data:

1. Open the Worker Group, then Processing > Pipelines and the Pipeline with the Guard Function.
2. Expand the Cribl Guard Function and toggle Background Detection off.
3. Select Commit & Deploy.

When background detection is off for a Pipeline, PII in that Pipeline doesn’t get a Guard mitigation rule and doesn’t appear as a detection on the Guard page.

Why Use Background Detection? ​

Common Use Cases ​