What breaks when AI-based vulnerability detection has low recall?

Why This Matters for Security Teams

Low recall is a coverage problem, not just a model-quality problem. In vulnerability management, a detector that finds only a narrow slice of real issues can still produce attractive precision metrics while leaving large parts of the attack surface unexamined. That matters because security leaders often use AI-assisted triage to prioritise code review, backlog remediation, and exposure reduction. If the model misses vulnerable patterns, the organisation may mistake a partial signal for meaningful assurance.

This is especially important when teams treat AI output as a replacement for scanning depth, human review, or compensating controls. The operational risk is not only missed findings, but also distorted decision-making: teams may defer manual testing, down-rank risky services, or over-trust a green dashboard. The NIST Cybersecurity Framework 2.0 remains useful here because it frames detection as part of a broader risk programme, not a single tool outcome.

In practice, many security teams encounter the coverage gap only after a vulnerable release has already shipped, rather than through intentional validation of what the model failed to see.

How It Works in Practice

AI-based vulnerability detection typically classifies code, dependencies, or infrastructure configurations into likely-safe and likely-risky buckets. When recall is low, the system is missing too many true vulnerabilities in the negative bucket. That can happen because training data under-represents certain languages, framework patterns, or attacker techniques, or because the model is tuned too aggressively toward high-confidence alerts.

Practitioners should evaluate the system as part of a detection pipeline, not as a standalone decision engine. Useful checks include:

• measuring recall by vulnerability class, file type, and repository segment;
• comparing model output with ground truth from red team exercises, manual review, and exploit validation;
• tracking false negatives separately from precision so the missed-finding rate stays visible;
• using the model to prioritise human attention, not to suppress broader scanning or threat modelling.

Control thinking from CIS Controls v8 supports this approach because secure configuration, continuous vulnerability management, and auditability all depend on seeing more than the highest-confidence subset. AI detections should also be cross-checked against CISA cyber threat advisories and current exploit trends so the model is not judged only on historical patterns.

Where possible, teams should calibrate thresholds per environment. A customer-facing application with internet exposure may need a different miss tolerance than an internal proof of concept, but the principle is the same: low recall shifts risk from visible triage into invisible exposure. These controls tend to break down when a model is fed sparse telemetry from legacy applications, because the underlying code patterns are too inconsistent for stable detection.

Common Variations and Edge Cases

Tighter alert thresholds often improve confidence per finding but reduce coverage, requiring organisations to balance analyst workload against the risk of silent misses. That tradeoff becomes more acute when AI is used in fast-moving DevSecOps pipelines, where teams want speed but also need defensible assurance.

There is no universal standard for the acceptable recall target in vulnerability detection yet. Best practice is evolving toward environment-specific thresholds, with higher expectations for critical assets, regulated systems, and internet-facing services. In those cases, low recall is more damaging because missed vulnerabilities can feed directly into exploit chains, compliance findings, or incident response overhead.

Edge cases also matter. LLM-assisted code review can look strong on common insecure patterns but fail on novel framework usage, custom libraries, or multi-file logic flaws. In AI-supported security operations, the same issue appears when the model over-focuses on obvious indicators and misses weak signals that only become meaningful in context. The ENISA Threat Landscape is a useful reference for understanding how real attacker behaviour often diverges from the patterns a detector has seen most often.

For that reason, recall should be treated as a governance metric, not just a technical benchmark, with explicit sign-off on what proportion of risk the organisation is willing to leave to manual review.

Related resources from NHI Mgmt Group

• What breaks when AI workload security relies only on signature-based runtime detection?
• What breaks when an AI security agent only optimises for vulnerability recall?
• What is the difference between network detection and identity-based discovery for AI agents?
• What breaks when a vulnerability is judged hard to exploit but AI can chain exploitation automatically?