Why do generic AI code-review prompts miss real exploitability?

Why pattern matching is not the same as exploitability

A code-review prompt can flag suspicious constructs, but exploitability is not a static property of a snippet. It depends on whether the weakness is reachable, what preconditions exist, what the surrounding control flow does, and whether other layers already constrain the behavior. In practice, the difference between “looks risky” and “is exploitable” is often the architecture around the code, not the code alone.

That is why prompt-only review tends to overcall obvious anti-patterns and undercall issues that require state, trust, or deployment knowledge. A function may appear unsafe in isolation yet be unreachable, gated by authorization, or constrained by input provenance. The reverse is also true: a harmless-looking call can become exploitable when it sits behind a permissive integration, a weak trust boundary, or an unexpected execution path.

Generic prompts also struggle with framework behaviour. Security-relevant behavior is often created by defaults, middleware, serializers, deserializers, SDKs, templates, or policy layers that the model does not fully infer from local code. When the exploit path emerges from how components combine, the right question is not “does this line look dangerous?” but “what does the surrounding runtime make possible?”

What context changes the verdict

Exploitability usually turns on a small set of contextual questions: can an attacker reach the code path, can they shape the input, can they influence the trust boundary, and can they turn the resulting behavior into impact. Those questions are architectural as much as syntactic. The same issue can be a low-value finding in one deployment and a high-value exploit primitive in another.

Deployment context matters because the same code can sit behind different permissions, network exposure, feature flags, tenancy boundaries, or compensating controls. A generic prompt has no reliable view of those conditions unless they are explicitly provided. Without that context, it cannot distinguish a theoretical weakness from one that is operationally reachable.

Framework behavior matters for the same reason. Libraries often normalize, escape, reject, redirect, or scope data in ways that neutralize a pattern the prompt would otherwise flag. When review ignores those mechanics, it confuses presence of a risky API or construct with actual exploitability.

Why better review needs threat model reasoning

Good exploitability analysis starts from the attacker path, not the code smell. The review needs to ask what the attacker can control, what the application assumes, and where those assumptions break. That includes data provenance, privilege level, object boundaries, session state, and whether a downstream component amplifies the input into something harmful.

That is also why generic prompts are weak at prioritization. They cannot reliably tell you whether the issue is directly exploitable, only exploitable under special conditions, or effectively mitigated by the current design. A competent reviewer has to reason from the system’s trust model and the specific deployment path, then decide whether the issue belongs in a fix queue, a redesign, or a note for future hardening.

In practice, this is the same reason exploit intelligence beats static pattern matching. Public vulnerability databases and exploitation signals help confirm whether a weakness class has become operationally meaningful, but they still have to be mapped back to the application’s actual exposure and controls. NIST National Vulnerability Database, FIRST EPSS, and the CISA Known Exploited Vulnerabilities Catalog all reinforce the same point: exploitability is contextual, and prioritization improves when you combine technical weakness with evidence of real-world abuse.

Practitioner Guidance

What to verify: Before trusting an AI review finding, verify reachability, preconditions, trust boundary crossing, and whether framework or platform behavior already blocks the path. If the model cannot explain how an attacker gets from input to impact, treat the finding as incomplete rather than actionable.

Decision rule: If a weakness is only visible by syntax, but not by an end-to-end attack path, classify it as a candidate issue, not an exploit verdict. If the path can be described in the deployed environment, escalate it as a real security finding and validate it with runtime-specific evidence.

What good looks like: The best review output ties each issue to an attacker-relevant sequence, named assumptions, and the control that makes it safe or unsafe. That produces fewer false positives, but more importantly it exposes the cases where an apparently minor code pattern is actually the start of a viable exploit chain.

Practitioner takeaway: Treat ai code review as a triage aid, not an exploitability oracle; the final judgment must come from the application’s trust model, runtime behavior, and deployment exposure.

Related resources from NHI Mgmt Group

• Why do late-stage code scans miss the real security problem in the AI SDLC?
• Why do AI-assisted code review tools often miss the issues engineers care about most?
• Why can AI code review still miss important security and design issues?
• Why does a one-time vendor review often miss the real risk of SaaS and AI tools?