Multi-Model Validation

False positives are the most common complaint with automated security scanners. A report full of noise erodes trust, wastes engineering time, and trains teams to ignore findings. PreBreach addresses this with a dual-model validation pipeline that independently verifies every finding before it reaches your report.

Why Multi-Model Validation Matters

A single AI model, no matter how capable, has inherent biases in its reasoning patterns. It may consistently overweight certain signals or underweight others, leading to systematic errors that are invisible from within the model's own evaluation.

By introducing a second, architecturally distinct model, PreBreach creates an adversarial check. Each model brings different training data, different reasoning approaches, and different failure modes. When both models independently agree that a finding is real, the probability of a false positive drops dramatically.

The result: PreBreach maintains a false positive rate of less than 5% across all scan types and target architectures.

How the Pipeline Works

After the AI agents complete their analysis, every candidate finding enters the validation pipeline. The process follows four stages.

Stage 1: Finding Normalization

Raw findings from all agents are deduplicated and normalized into a consistent schema. Each finding includes the vulnerability description, affected endpoint, evidence payloads, and the originating agent's confidence assessment.

Stage 2: Independent Assessment

Two models evaluate each finding independently and without knowledge of the other's assessment:

• Claude Opus -- Anthropic's most capable reasoning model. Evaluates the finding's evidence chain, assesses exploitability, and determines whether the observed behavior constitutes a genuine vulnerability.
• GPT -- OpenAI's model performs the same evaluation using its own reasoning. The prompt structure is equivalent but the model's internal weights and training produce an independent judgment.

Neither model sees the other's output. This isolation is critical to preventing confirmation bias.

Stage 3: Consensus Voting

The two independent assessments are compared using a simple voting system:

• Confirmed (2/2) -- Both models independently agree the finding is a true positive. This is the highest confidence classification and the finding is included in the report with a confirmed badge.
• Needs Review (1/2) -- The models disagree. One flagged the finding as real while the other classified it as a false positive. The finding is included in the report but marked for manual review. These split decisions account for edge cases where additional human judgment adds value.
• Rejected (0/2) -- Both models agree the finding is a false positive. The finding is excluded from the report by default. You can still view rejected findings by toggling the filter in the interactive HTML report.

Stage 4: Proof-of-Concept Execution

For confirmed and needs_review findings, PreBreach executes proof-of-concept (PoC) validation where possible. This means the platform attempts to reproduce the vulnerability in a controlled manner to collect concrete evidence.

PoC execution serves two purposes:

1. Evidence generation -- Captures the actual HTTP request/response pairs, error messages, or behavioral changes that demonstrate the vulnerability.
2. Confidence reinforcement -- A successfully executed PoC raises the finding's confidence score. A failed PoC may lower it or reclassify the finding.

Screenshot Capture

For vulnerabilities with a visual component, such as cross-site scripting, UI redressing, or content injection, the validation pipeline captures browser screenshots as part of the evidence package. Screenshots are taken using a headless browser that renders the page in its exploited state.

Screenshots provide:

• Visual proof for stakeholders who may not be able to interpret raw HTTP evidence.
• Audit artifacts that can be attached to compliance reports or shared with clients on Agency plans.
• Reproduction context showing exactly what an attacker would see.

Confidence Score Impact

The validation consensus directly influences the confidence score assigned to each finding:

• Confirmed findings receive a confidence boost, typically landing in the 85-100 range.
• Needs review findings retain a moderate confidence score, usually between 50 and 75, reflecting the model disagreement.
• Rejected findings are assigned low confidence scores and hidden from the default report view.

False Positive Rate

PreBreach targets and maintains a false positive rate of less than 5% across all scans. This rate is measured against manual verification of a statistically significant sample of findings across diverse target types.

The dual-model architecture is the primary driver of this low rate. Traditional single-model or rule-based scanners commonly produce false positive rates of 20-40%, requiring significant manual triage effort. By requiring consensus between two independent models and backing that consensus with PoC execution, PreBreach eliminates the vast majority of false signals before they reach your team.

Interpreting Validation Results

When reviewing your report, use validation consensus as a triage accelerator:

• Confirmed findings -- Treat these as actionable. Begin remediation without additional verification.
• Needs review findings -- Allocate time for manual inspection. Review the evidence, attempt reproduction, and make a judgment call. These findings are often real but in ambiguous contexts.
• Rejected findings -- These are hidden by default for a reason. Only review them if you suspect the models may have missed something specific to your application's logic.

Next Steps

• Understanding Findings -- Learn how severity, CVSS scores, and remediation guidance work together.
• Reports Overview -- Explore report formats, the grading system, and how to export results.