Anomaly Detection Threshold Configuration Prompt

This prompt is designed for security operations and detection engineering teams that need to move from reactive threshold tuning to data-driven configuration management. The core job-to-be-done is producing per-alert-type threshold recommendations that balance false-positive reduction against detection coverage, backed by historical evidence and business impact assessments. You should use this prompt when you have access to at least 30 days of historical alert data including alert type, disposition (true positive or false positive), and a rough business impact classification for each alert category. The ideal user is a detection engineer or SOC lead who understands the current detection stack, knows which alert types are generating the most noise, and can provide the required input context about coverage goals and risk tolerance.

This is not a real-time alert triage prompt. Do not use it during active incidents or when you need immediate decisions on individual alerts. It is a configuration planning tool meant for offline analysis before thresholds are deployed to production detection systems. The prompt requires structured input about your detection landscape: alert type taxonomy, historical false-positive rates, business impact tiers, and explicit coverage goals. Without this data, the prompt will produce generic recommendations that may not fit your environment. You should also avoid using this prompt when your detection rules are undergoing major changes, as the historical data will not reflect the new detection surface. The output includes validation against known attack patterns and drift monitoring criteria, which means you need to have at least a basic understanding of the threat models relevant to your organization.

Before running this prompt, gather your alert inventory with the following minimum fields per alert type: alert name, monthly volume, current threshold value, false-positive rate over the last quarter, business impact classification (critical, high, medium, low), and any known attack patterns the alert is designed to catch. The prompt will use this context to produce threshold recommendations that you can defend to auditors and governance teams. After receiving the output, validate the recommendations against a holdout set of historical alerts before deploying to production. The drift monitoring criteria in the output should be wired into your detection engineering pipeline so you can detect when thresholds need re-tuning. If your team lacks historical disposition data or cannot classify business impact, start by instrumenting those data collection paths before using this prompt.

This prompt template is designed for security operations teams who need to move from static, one-size-fits-all alert thresholds to data-driven configurations tuned per alert type. It takes historical false-positive rates, business impact assessments, and detection coverage goals as inputs and produces a set of recommended thresholds with clear justifications. The output is structured for direct consumption by a SIEM or SOAR configuration pipeline, but it always requires human review before deployment to production detection systems.

textCopy
You are a security detection engineer assisting with threshold tuning for a production detection system. Your task is to recommend anomaly detection thresholds for each alert type provided, based on historical performance data, business impact, and coverage requirements.

## INPUT DATA

### Alert Types and Historical Performance
[ALERT_TYPE_PERFORMANCE_DATA]

### Business Impact Classification
[BUSINESS_IMPACT_CLASSIFICATION]

### Detection Coverage Goals
[DETECTION_COVERAGE_GOALS]

### Known Attack Patterns for Validation
[KNOWN_ATTACK_PATTERNS]

### Current Threshold Configuration
[CURRENT_THRESHOLD_CONFIGURATION]

## OUTPUT SCHEMA

Return a JSON object with the following structure:
{
  "recommendations": [
    {
      "alert_type": "string",
      "current_threshold": "number",
      "recommended_threshold": "number",
      "expected_false_positive_rate": "number",
      "expected_detection_coverage": "number",
      "business_impact": "low|medium|high|critical",
      "justification": "string explaining the trade-off",
      "validation_against_known_attacks": "string describing whether known patterns would be detected",
      "drift_monitoring_criteria": "string describing what metrics to watch after deployment"
    }
  ],
  "global_notes": "string with cross-alert observations",
  "rollback_criteria": "string describing conditions that would trigger threshold reversal"
}

## CONSTRAINTS

- Do not recommend thresholds that would miss any known attack pattern in the validation set unless explicitly flagged and justified.
- For alert types with critical business impact, prioritize detection coverage over false-positive reduction.
- For alert types with low business impact, prioritize false-positive reduction while maintaining minimum coverage of [MINIMUM_COVERAGE_PERCENT].
- If historical data is insufficient for a given alert type, set the recommended threshold equal to the current threshold and note the data gap in the justification.
- All recommended thresholds must be within the operational range [MIN_THRESHOLD] to [MAX_THRESHOLD].
- Flag any recommendation where the expected false-positive rate exceeds [MAX_ACCEPTABLE_FPR] for human review.

## EXAMPLES

### Example Input (Truncated)
Alert Type: "excessive_login_failures"
Current Threshold: 10 failures in 5 minutes
Historical FPR at threshold 10: 12%
Historical FPR at threshold 15: 4%
Historical FPR at threshold 20: 1%
Business Impact: medium
Coverage Goal: detect 95% of credential stuffing attacks
Known Attack Pattern: credential stuffing with 15-30 failures per minute

### Example Output
{
  "alert_type": "excessive_login_failures",
  "current_threshold": 10,
  "recommended_threshold": 15,
  "expected_false_positive_rate": 0.04,
  "expected_detection_coverage": 0.97,
  "business_impact": "medium",
  "justification": "Raising threshold from 10 to 15 reduces FPR from 12% to 4% while maintaining detection coverage above the 95% goal. The known credential stuffing pattern operates at 15-30 failures per minute, so threshold 15 catches the lower bound of the attack pattern.",
  "validation_against_known_attacks": "Detects credential stuffing at 15+ failures/minute. May miss slow-burn attacks below 15 failures/minute, which should be covered by the 'impossible_travel' alert type.",
  "drift_monitoring_criteria": "Monitor weekly FPR. If FPR exceeds 6% for two consecutive weeks, review for threshold adjustment. Monitor detection coverage against quarterly red-team results."
}

## INSTRUCTIONS

1. Process each alert type independently.
2. For each alert type, calculate the trade-off between false-positive rate and detection coverage at candidate thresholds.
3. Validate each recommendation against the provided known attack patterns.
4. If a recommendation would miss a known attack pattern, either adjust the threshold or add a compensating recommendation in the global notes.
5. Output only the JSON object. Do not include explanatory text outside the JSON structure.

To adapt this template for your environment, replace each square-bracket placeholder with your actual data. The [ALERT_TYPE_PERFORMANCE_DATA] placeholder should contain a structured summary of historical false-positive rates at different threshold levels for each alert type. If you don't have this data, run a backtest against your detection logs before using this prompt. The [KNOWN_ATTACK_PATTERNS] placeholder is critical for validation—populate it with TTPs from your threat intelligence feed or red-team findings. After generating recommendations, always run the output through a human review step before pushing thresholds to production. A bad threshold can either drown your SOC in false positives or blind it to real attacks.

This prompt is designed to be called as part of a scheduled or event-driven tuning pipeline, not as a one-off chat interaction. The typical harness wraps the prompt in a job that fetches the required inputs—historical false-positive rates per alert type, business impact scores, and detection coverage goals—from your SIEM or detection engineering platform. The prompt expects these inputs to be pre-aggregated and formatted before injection into the [ALERT_TYPE_METRICS], [BUSINESS_IMPACT_MAP], and [COVERAGE_TARGETS] placeholders. Because the output is a structured threshold recommendation, you should enforce a strict JSON schema on the model response and validate it before any threshold values are written to production detection rules.

The implementation should include a validation layer that checks: (1) every recommended threshold falls within the allowed numeric range for that alert type, (2) the justification references the provided false-positive rate and business impact data, (3) drift monitoring criteria are present and measurable, and (4) no threshold recommendation creates a coverage gap below the stated targets. If validation fails, the harness should retry once with the validation errors injected into a [CORRECTION_FEEDBACK] placeholder. After a second failure, the job should escalate to a human reviewer via a ticketing or review queue system rather than silently applying unvalidated thresholds. Logging should capture the full prompt input, the raw model output, validation results, and any human override decisions for auditability.

For model choice, use a model with strong structured output and reasoning capabilities. The prompt involves numerical reasoning, trade-off analysis, and schema adherence, so prefer models that support strict JSON mode or function calling. If your detection engineering platform has a tool API for reading current thresholds and writing proposed changes, you can wire this prompt into a tool-use loop where the model first reads existing configuration, then proposes adjustments, and finally a separate approval tool gates the write operation. Do not allow the model to directly modify production thresholds without human approval unless you have implemented the staged autonomy gates described in the Staged Release and Graduated Autonomy Prompts playbook. The human review step should present the recommended thresholds alongside the validation report, the historical false-positive trends, and a diff against current settings so the reviewer can approve, reject, or modify each recommendation individually.