Security Incident vs. General Bug Classification Prompt

Engineering platforms that accept bug reports, support tickets, or feedback through a shared intake channel need a reliable way to separate security-sensitive reports from general bugs before they hit the wrong queue. A general bug report about a UI glitch and a vulnerability disclosure describing an authentication bypass require different handling, different SLAs, different access controls, and different downstream workflows. This prompt classifies incoming reports as either a security incident or a general bug, producing a structured routing decision with a severity signal and a confidentiality flag. Use it as a pre-processor before dispatching to your bug tracker, security incident response tool, or human triage queue. It is designed for text-based reports and works best when the input contains enough detail to distinguish accidental misbehavior from intentional exploitability.

The ideal input is a single, self-contained report with a clear description of observed behavior, expected behavior, and steps to reproduce. The prompt performs best when the reporter describes impact—data exposure, privilege escalation, denial of service, or integrity violations signal security relevance, while cosmetic issues, performance degradation without security implications, and feature requests signal general bugs. Reports that mention CVEs, attack patterns (XSS, SQLi, CSRF, path traversal), authentication bypass, or unauthorized data access are strong security signals. Reports focused on visual defects, confusing UX, slow load times without data risk, or missing functionality are general bug signals. The prompt also detects mixed signals—a performance bug that could enable a race condition, for example—and uses the confidentiality flag to restrict distribution when the report contains potentially exploitable details.

Do not use this prompt when the input is a raw stack trace without narrative context, an automated scanner output without human interpretation, or a multi-issue dump containing dozens of unrelated findings. It is not designed for real-time attack detection from log streams or SIEM alerts—those require different temporal reasoning and threat intelligence integration. Avoid relying on this prompt as the sole decision-maker for regulated incident reporting where legal or compliance obligations require deterministic, auditable classification rules. In those cases, use the prompt's structured output as a recommendation that a human reviews before the report enters a confidential security workflow. The prompt also should not replace a proper vulnerability disclosure program with defined scope, safe harbor language, and researcher communication templates—it is a routing aid, not a policy engine.

The following prompt template is designed to be dropped directly into your classification pipeline. It forces the model to reason about exploitability, impact, and security boundaries before committing to a label. The template uses square-bracket placeholders that you must replace with your actual report text, output schema, and any additional constraints before sending the request. Do not leave placeholders unresolved in production calls.

textCopy
Classify the following report as a security incident or a general bug.

A security incident involves potential unauthorized access, data exposure, privilege escalation, injection, authentication bypass, denial of service, or any behavior that could be intentionally exploited to compromise confidentiality, integrity, or availability.

A general bug is unintended behavior that does not present a plausible security impact, such as cosmetic issues, non-security performance problems, or functional defects without exploitability.

[REPORT]

[CONSTRAINTS]

Use the output schema exactly as specified.

[OUTPUT_SCHEMA]

Adapt this template by replacing [REPORT] with the full text of the bug report, vulnerability disclosure, or incident description. The [CONSTRAINTS] placeholder is where you inject additional rules, such as 'If uncertain, classify as a security incident and flag for human review' or 'Ignore severity ratings in the report; classify based on described behavior only.' The [OUTPUT_SCHEMA] placeholder must contain your exact expected JSON structure, including field names, types, and enum values. A typical schema includes classification (enum: security_incident or general_bug), confidence (float 0-1), and reasoning (string with specific evidence from the report). For high-stakes environments, add a requires_human_review boolean field that triggers when confidence is below your threshold or when the report contains indicators of active exploitation. Test this prompt against a golden dataset of 50-100 labeled reports before deployment, measuring both precision and recall on the security incident class, since false negatives here carry the highest risk.

This prompt is designed to sit at the ingress point of an engineering ticketing or alerting system, before any automated actions are taken. The implementation harness must treat the model's output as a routing signal, not a final decision. Wire the prompt into a pre-processing middleware that receives the raw report text, injects it into the [INPUT] placeholder along with your organization's [SECURITY_SIGNAL_DEFINITIONS], and parses the JSON response. The harness should validate that the output contains the required fields (classification, confidence_score, security_signals_detected, requires_immediate_escalation, reasoning) and that classification is strictly one of the allowed enum values: security_incident, general_bug, or ambiguous.

For production deployment, implement a validation layer that rejects malformed JSON or missing fields and triggers a single retry with a repair prompt that includes the raw output and the validation error. If the retry also fails, escalate the entire report to a human triage queue with the raw input and both failed attempts logged. When classification is security_incident or requires_immediate_escalation is true, the harness must route the report to a confidential security channel, bypassing any public-facing or general-access bug trackers. Log the full prompt, model response, and routing decision to an immutable audit store for post-incident review. For model choice, prefer a model with strong instruction-following and JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature to 0 to maximize classification consistency.

Before shipping, build an eval harness using a golden dataset of at least 50 labeled reports that includes confirmed security incidents, general bugs, and deliberately ambiguous edge cases. Measure precision and recall separately for the security_incident class, as false negatives here carry the highest risk. Set a minimum recall threshold of 0.95 for security incidents before enabling automated routing. Monitor production drift by sampling classified reports weekly and having a security engineer review a random subset, comparing human labels to model decisions. If confidence scores show systematic miscalibration (e.g., high confidence on incorrect classifications), adjust the [SECURITY_SIGNAL_DEFINITIONS] or add few-shot examples targeting the failure patterns. Never allow this prompt's output to directly trigger destructive actions, disclosure, or public posting without a human-in-the-loop checkpoint for all security_incident classifications.