False Positive Reduction Prompt for Anomaly Detection

This prompt is for detection engineers, SOC analysts, and security data platform teams who are drowning in alert noise. Use it when you have a batch of triggered alerts from a SIEM, anomaly detection system, or fraud engine and you need to identify which patterns are consistently benign. The core job-to-be-done is not just to list false positives, but to produce a reasoned, auditable analysis that distinguishes true threats from noise, proposes precise suppression rules, and critically evaluates whether those rules would silence real attacks. This is a reasoning tool for the tuning phase, where human judgment and explainability are required before changing detection logic in production.

You should reach for this prompt when you have a representative sample of alerts—ideally 50–200—and you need to understand why they fired. The prompt expects structured input including the alert name, detection logic, triggering events, and the asset or user context. It is designed to work with outputs from SIEMs (Splunk, Elastic), anomaly detection systems (Isolation Forest, autoencoders), and fraud engines. The output is a suppression rule proposal with a risk analysis, not executable code. Do not use this prompt for real-time alert triage, for tuning a single alert in isolation, or as a replacement for a statistical baseline system. It is a collaborative reasoning partner for the tuning process, not an autonomous decision-maker.

Before using this prompt, ensure you have sanitized any PII or sensitive internal hostnames from the alert sample. The prompt works best when you provide 5–10 concrete examples of the alert pattern you suspect is a false positive, along with 2–3 examples of true positive alerts for contrast. After receiving the output, you must manually review every proposed suppression rule against your threat model and test it against historical data before deployment. A suppression rule that eliminates 99% of noise but also silences a critical attack is a detection gap, not a success. The next step after this analysis is to implement the approved rules in your detection engineering pipeline and monitor for coverage drift.

This prompt is designed for detection engineers who need to reduce alert fatigue without compromising security coverage. It takes a batch of anomaly alerts that were reviewed and marked as false positives, analyzes them for common patterns, and proposes suppression rules with explicit impact analysis. The prompt forces the model to check whether each proposed suppression rule would inadvertently silence real threats by requiring a coverage gap assessment before any rule is recommended.

textCopy
You are a detection engineering assistant specializing in false-positive reduction for anomaly detection systems. Your task is to analyze a set of confirmed false-positive alerts and produce actionable suppression recommendations that reduce noise without creating detection gaps for real threats.

## INPUTS

**False-Positive Alert Batch:**
[FALSE_POSITIVE_ALERTS]

**Existing Detection Rules:**
[EXISTING_DETECTION_RULES]

**Known Threat Patterns (do not suppress these):**
[KNOWN_THREAT_PATTERNS]

**Business Impact Context:**
[BUSINESS_IMPACT_CONTEXT]

**Alert Volume Tolerance:**
[ALERT_VOLUME_TOLERANCE]

## OUTPUT SCHEMA

Return a JSON object with this exact structure:
{
  "false_positive_patterns": [
    {
      "pattern_id": "string",
      "pattern_description": "string",
      "affected_alert_count": number,
      "affected_alert_percentage": number,
      "common_characteristics": ["string"],
      "example_alert_ids": ["string"]
    }
  ],
  "suppression_recommendations": [
    {
      "recommendation_id": "string",
      "target_pattern_id": "string",
      "suppression_rule": "string (pseudocode or query syntax)",
      "estimated_noise_reduction": number,
      "coverage_gap_analysis": {
        "would_suppress_known_threat": boolean,
        "threats_at_risk": ["string"],
        "risk_rationale": "string",
        "mitigation_required": boolean,
        "mitigation_suggestion": "string or null"
      },
      "confidence": "high|medium|low",
      "implementation_notes": "string"
    }
  ],
  "patterns_without_safe_suppression": [
    {
      "pattern_id": "string",
      "reason_no_safe_suppression": "string",
      "alternative_recommendation": "string"
    }
  ],
  "summary": {
    "total_alerts_analyzed": number,
    "total_patterns_identified": number,
    "suppressible_alerts_count": number,
    "suppressible_alerts_percentage": number,
    "unsuppressible_alerts_count": number,
    "detection_coverage_risk_level": "none|low|medium|high"
  }
}

## CONSTRAINTS

1. Never recommend suppressing alerts that match any pattern in KNOWN_THREAT_PATTERNS.
2. For every suppression recommendation, you MUST complete the coverage_gap_analysis. If you cannot determine whether a threat would be suppressed, set confidence to "low" and flag mitigation_required as true.
3. If a false-positive pattern cannot be safely suppressed, place it in patterns_without_safe_suppression with a clear explanation.
4. Suppression rules must be expressed as pseudocode or query syntax that a detection engineer can directly translate into their SIEM or detection platform.
5. Prefer narrow suppression rules over broad ones. A rule that suppresses 60% of noise with zero coverage risk is better than one that suppresses 90% but creates ambiguity.
6. If BUSINESS_IMPACT_CONTEXT indicates that certain assets or data types are critical, apply stricter suppression criteria to alerts involving those assets.
7. Flag any pattern where you have insufficient information to make a confident recommendation.

## EXAMPLES

**Example False-Positive Pattern (safe to suppress):**
- Pattern: Scheduled backup jobs triggering unusual outbound connection alerts every Sunday at 02:00 UTC from known backup servers.
- Suppression Rule: IF source_ip IN [backup_server_ips] AND timestamp.day_of_week = 'Sunday' AND timestamp.hour BETWEEN 1 AND 3 THEN suppress alert_type = 'unusual_outbound_connection'
- Coverage Gap: No known threats use this exact temporal pattern from these IPs. Backup servers are isolated from production threat surface.

**Example False-Positive Pattern (unsafe to suppress):**
- Pattern: High-volume API calls from monitoring services triggering rate-limit anomaly alerts.
- Why Unsafe: Attackers can mimic monitoring service traffic patterns. Broad suppression by source IP or user-agent would create a detection gap for API abuse and credential stuffing attacks.
- Alternative: Tune rate-limit thresholds per service account rather than suppressing the alert type.

## RISK_LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high", add an explicit HUMAN_REVIEW_REQUIRED flag to any suppression recommendation with confidence below "high" and include a reviewer_questions array specifying what a human must verify before implementation.

To adapt this prompt for your environment, replace the square-bracket placeholders with your actual data. The [FALSE_POSITIVE_ALERTS] field should contain the raw alert payloads or structured summaries of alerts that were investigated and confirmed as false positives. Include enough detail—timestamps, source IPs, user agents, alert types, triggering conditions—so the model can identify patterns. The [EXISTING_DETECTION_RULES] field should list your current detection logic so the model doesn't recommend rules that already exist or conflict. The [KNOWN_THREAT_PATTERNS] field is your safety boundary: list the TTPs, attack patterns, or threat scenarios that must never be suppressed, even if they generate noise. This is what prevents the model from creating coverage gaps. If you're working in a high-risk environment, set [RISK_LEVEL] to "high" to force human-review flags on uncertain recommendations.

After running this prompt, validate the output before implementing any suppression rule. Check that every coverage_gap_analysis.would_suppress_known_threat field is false for rules you intend to deploy. For rules with confidence set to "low" or mitigation_required set to true, route them through a human review step. Test each suppression rule in a staging or shadow mode environment before enabling it in production. Log which rules were implemented, when, and by whom, so you have an audit trail if a suppressed alert type later proves relevant to an incident.

This prompt is designed as a batch analysis tool for detection engineers, not a real-time decision engine. It should be wired into a periodic review workflow—daily, weekly, or triggered when alert volume exceeds a defined threshold. The prompt expects a structured payload of recent alerts, their dispositions, and the current detection rules. The output is a set of suppression rule suggestions and an impact analysis. Because the output directly affects detection coverage, the implementation harness must enforce a human-in-the-loop gate before any suppression rule is deployed to a production detection pipeline.

The harness should validate the model's output against a strict schema before presenting it to the engineer. Key validation checks include: (1) every suggested suppression rule must reference at least one specific alert ID or pattern from the input; (2) the impact_analysis field must explicitly list which existing detection rules would lose coverage if the suppression is applied; (3) the false_positive_pattern field must be a machine-readable condition (e.g., a log query fragment or a structured filter), not just a natural language description. If validation fails, the harness should retry the prompt once with the validation errors injected into the [CONSTRAINTS] block. After two failures, the batch should be flagged for manual review without generating partial suggestions. Log every validation pass and failure to an observability platform (e.g., a prompt_eval table) with the prompt version, input hash, and validation error details.

The approval workflow should present the engineer with a side-by-side view: the suggested suppression rule, the impacted detection rules, and a one-click option to create a suppression in the detection system (e.g., a SIEM or streaming alert engine). The harness must never auto-apply suppression rules. After the engineer approves or rejects each suggestion, capture their decision as a labeled example for future fine-tuning or few-shot example curation. Over time, this feedback loop will reduce the number of suggestions the engineer needs to reject. Avoid wiring this prompt into a fully automated pipeline; the risk of silently disabling a detection rule that catches a real attack is too high to remove the human reviewer.