AI vulnerability detection depends more on harness design than model choice

At a glance

What this is: This is a benchmark analysis of AI-assisted vulnerability detection, showing that deterministic code analysis plus model reasoning materially improves recall, precision stability, and cost per true positive.

Why it matters: It matters because security teams evaluating AI for AppSec need to govern not just model outputs, but the harness, coverage, and repeatability that determine whether detection is trustworthy enough to operationalise.

By the numbers:

• The benchmark shows a cost of $0.62 per true positive for Semgrep Multimodal, compared with $0.77 for the guided prompt.
• Claude Security performs with roughly the same precision and recall as the guided prompt, but at $72.55 per true positive.
• 90% of the endpoints in a repository when

👉 Read Semgrep's benchmark analysis of AI vulnerability detection and model harnessing

Context

AI vulnerability detection only becomes useful when teams can trust its coverage, not just its answers. A model that reasons well about a few visible findings still leaves blind spots if it cannot enumerate the right code paths in the first place, which is why primary keyword coverage and endpoint discovery are the real governance problem here.

That distinction matters for AppSec, IAM, and platform security teams building AI-assisted workflows. If the system cannot reliably locate relevant code, then its output is only partially actionable, and the operational question becomes how to combine deterministic analysis with model reasoning without losing repeatability or inflating review cost. For teams evaluating code intelligence tools, the architectural pattern is similar to the one discussed in the NHI Lifecycle Management Guide: the control plane matters as much as the policy decision.

Key questions

Q: How should security teams evaluate AI tools for code vulnerability discovery?

A: Use a fixed vulnerable corpus, repeat each test several times, and score the union of findings as well as the average single-pass result. That approach reveals variance, missed paths, and cost efficiency. A model that looks weak once may be useful when pooled, while a headline score can hide unreliable performance.

Q: Why do raw LLMs miss so many vulnerabilities in code review?

A: Raw LLMs are limited by probabilistic attention and incomplete repository search. They may reason well about code they notice, but they do not reliably enumerate every endpoint, sink, or reachable path. That creates blind spots that only become visible after incidents or pentests, which is why deterministic program analysis is needed to structure the review.

Q: What do security teams get wrong about AI scan pricing?

A: Teams often look at price per scan, but that ignores whether the scan finds actionable issues. A cheap scan that misses most vulnerabilities is expensive in operational terms because the risk remains in production. The better measure is cost per true positive, paired with enough recall to make remediation coverage meaningful.

Q: How can AppSec teams make AI findings consistent enough to use?

A: They should reduce variability by constraining what the model sees and by using repeatable candidate selection. Consistency comes from a stable harness, not from hoping the model behaves the same way every time. If the same code produces different results across runs, teams cannot build reliable triage, reporting, or remediation workflows.

Technical breakdown

Why raw model-based vulnerability search misses coverage

A frontier model can be strong at recognising whether an individual snippet looks exploitable, but that does not mean it can traverse a repository comprehensively. The problem is search, not reasoning. Large language models are probabilistic and attention-limited, so when they are asked to inspect a large codebase directly, they inspect the code they notice, not necessarily the code that matters. In AppSec terms, this creates coverage debt: the findings look plausible, yet the unseen attack surface remains unexamined. Deterministic program analysis is used to close that gap by enumerating endpoints, sinks, and candidate paths exactly before the model reasons about them.

Practical implication: treat model-only review as a supplement, not a control, unless deterministic code discovery is already in place.

How deterministic analysis improves AI-assisted detection

Deterministic analysis is the part of the system that does not guess. It identifies relevant code locations through exact program logic, then hands the model a narrowed slice of source to reason over. That division of labour is the architectural point of the article. The model still adds value, but only after the harness has constrained the search space to the places where vulnerabilities are most likely to exist. This is why the benchmark can show materially higher recall without a comparable drop in precision. The security value comes from combining exhaustive enumeration with model judgment, not from asking the model to substitute for static analysis.

Practical implication: require any AI detection workflow to prove it has deterministic coverage logic before it reaches developers.

Why cost per true positive is the operational metric that matters

Price per scan is a misleading measure in security operations because scans do not reduce risk unless they generate actionable findings. Cost per true positive measures what teams actually buy: a real vulnerability discovered and ready for remediation. That metric exposes the difference between cheap inference and expensive noise. A system can look economical at runtime while producing too few usable findings or too many false positives to sustain trust. In production AppSec, the right benchmark is whether each dollar spent retires meaningful risk across the codebase, repeatably and at scale.

Practical implication: budget AI AppSec tools against cost per actionable finding, not token spend or scan volume.

NHI Mgmt Group analysis

Coverage debt is the central failure mode in AI-assisted AppSec. The article shows that a model can produce sharp reasoning and still miss most of the repository if it does not first discover the right endpoints. That is a governance problem, not a model problem. For AppSec teams, the lesson is that visibility into what was examined is as important as the findings themselves, because unexamined code is ungoverned code.

Deterministic enumeration is the control that makes model reasoning operationally defensible. When static analysis identifies all candidate paths and the model only reasons over those slices, the security workflow becomes repeatable enough to audit and tune. That is the real architectural distinction between a demo and a control. For practitioners, this aligns closely with NIST CSF control expectations around repeatable identify, protect, and detect functions.

Deterministic coverage gap: the specific failure mode here is the assumption that a model can reliably find what it was never shown. The benchmark demonstrates that the harness, not the prompt, determines whether hidden vulnerabilities remain outside review. That has direct implications for AI governance in code security, where operational trust depends on traceable search boundaries and consistent outputs.

AI security tooling will increasingly be judged by workflow economics, not model brand. The cost per true positive gap in the article is large enough to change buying decisions and review throughput. As models improve, teams that keep the architecture fixed may see better results at the margin, but the durable advantage comes from the surrounding program analysis, filtering, and orchestration. Practitioners should evaluate the whole detection system, not the model claim.

AppSec teams should expect AI to become a layered control, not a standalone scanner. The most credible pattern in this article is a combined system where deterministic discovery, model reasoning, and result reconciliation each do a different job. That means security leadership should ask who owns coverage, who tunes the harness, and how missed endpoints are measured over time. For governance, that is the difference between experimentation and control.

What this signals

Coverage visibility will become the deciding control in AI-assisted security workflows. As model capability improves, the differentiator shifts from what the model can infer to what the harness can reliably expose. Teams should expect procurement, assurance, and red-team exercises to ask for proof of endpoint enumeration, not just output quality.

Deterministic search plus model reasoning is emerging as the practical pattern for governed AI detection. That maps cleanly to broader control thinking in NIST Cybersecurity Framework 2.0, where repeatability and traceability matter as much as detection claims. For security programmes, the operational signal is whether missed code regions are measurable and owned.

If AI is being used to assist code security, the governance model should treat the harness as part of the control surface. The next stage is not more prompting skill, but better orchestration, sampling, and verification around the model so that review coverage can be defended to engineering and audit stakeholders.

For practitioners

• Test coverage before trust: Require evidence that the detection workflow enumerates endpoints and sinks deterministically before any model output is accepted into triage. If the system cannot show what it examined, the findings should be treated as partial coverage, not a control.
• Benchmark on actionable findings: Measure tools using cost per true positive, precision, and recall on code your team actually owns, then compare those results against developer review capacity. This is the metric that reveals whether the system reduces risk or only generates noise.
• Separate search from reasoning: Design the workflow so static analysis selects candidate code regions and the model reasons only within those slices. That separation keeps the model focused on exploitation judgment instead of wasting tokens rediscovering where to look.
• Track missed endpoints as a governance signal: Keep a recurring sample of repository paths that were not inspected and review them as an operational metric. Missed endpoints are not a tuning issue alone; they indicate whether the harness is covering the attack surface you think it is.

Key takeaways

• AI vulnerability detection fails when the system cannot reliably find the code that matters, even if the model reasons well about visible findings.
• Semgrep’s benchmark shows that harness design changes recall and cost enough to alter operational decisions, not just model preference.
• Security teams should judge AI AppSec tools by deterministic coverage, repeatability, and cost per true positive, because those are the controls that determine whether the workflow is trustworthy.

Key terms

• Coverage debt: Coverage debt is the gap between the assets a security platform should see and the assets it actually covers at a point in time. It grows when deployment, maintenance, or configuration work cannot keep pace with cloud churn, leaving risk visible only after the gap has already formed.
• Cost per true positive: Cost per true positive measures how much it costs to produce one real, actionable finding. It is a better operational metric than scan price because it combines economic efficiency with detection quality, which is what matters when a security team has to decide whether a workflow is worth running at scale.
• Deterministic program analysis: Deterministic program analysis is code analysis that identifies relevant paths, sinks, and candidate locations through exact rules rather than probabilistic guessing. In a mixed AI workflow, it acts as the coverage engine, feeding the model the code slices it should reason about instead of asking the model to search the whole repository.
• Harness: The harness is the layer of instructions, policies, and approval logic wrapped around an AI agent. It is where organisations try to constrain behaviour, but it only works if the rules are explicit, current, and enforced outside the model itself.

What's in the full article

Semgrep's full article covers the operational detail this post intentionally leaves for the source:

• Benchmark methodology across open-source repositories with established ground truth
• Per-model comparison tables for Opus 4.8 and GPT 5.5 under different prompting and harness conditions
• How candidate generation, program slices, and incremental analysis are orchestrated in practice
• The earlier architecture discussion that explains why deterministic analysis changes coverage

👉 Semgrep's full post includes the benchmark table, methodology, and architecture details behind the recall gains

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners building resilient identity controls. It helps security teams connect identity governance to broader operational risk across programmes.