code review agent hallucinating vulnerabilities that are not in the diff

Not specified by the original author.

TL;DR: Require every vulnerability finding to quote an exact changed line, then programmatically verify each quote against the actual diff and drop anything that does not match. Models pattern-match on scary-looking code shapes and describe vulnerabilities they expect to see rather than ones present in the diff. Grounding each claim in a verified quote kills the phantoms.

code review agent hallucinating vulnerabilities that are not in the diff

1. Collect every vulnerability finding and its cited location. Expected: a list of claims, each pointing at a file and line.

2. Verify each cited line exists in the actual diff: extract the diff's changed lines and check that the quote matches verbatim. Expected: each claim either matches a real changed line or is flagged as unverified.

3. Drop every finding whose cited code is not in the diff. No exceptions, no "it might be nearby". Expected: the finding list shrinks to only grounded claims.

4. For the survivors, check the claim against the real code semantics (is that input actually unsanitized?). Expected: each remaining finding is both grounded and correct.

5. Tighten the review instructions: require exact code quotes for every finding and forbid claims about code outside the diff. Expected: the next run produces fewer, better findings.

6. Track the phantom rate over runs: dropped findings divided by total findings. Expected: the rate trends down; if it does not, the instructions need another pass.

Use this when

• the agent reports vulnerabilities that are not in the changed code
• security findings cite functions or patterns absent from the PR
• developers have started ignoring the agent's security comments

Not for this skill when

• the findings are real but low-severity (that is a tuning problem, not hallucination)
• the agent misses real vulnerabilities (that is recall, the opposite problem)
• a human wrote the findings (check the human, not the agent)

Variant phrasings

review bot reported SQL injection that isnt in the code

ai reviewer inventing security issues on the PR

phantom vulnerability findings in automated code review

Why it happens

Models pattern-match on scary-looking code shapes, and review instructions that emphasize security amplify it. Without a grounding requirement, the model completes the pattern: it describes the vulnerability it expects to see rather than the code in front of it. The stronger the instructions push on security, the more phantoms appear.

Edge cases

• A finding can cite a real line but misread it (a parameterized query called "unsanitized"); grounding is necessary but not sufficient, so keep the semantics check.
• Findings about unchanged context lines are legitimate only if the diff actually changed the risk; default to changed-lines-only.
• Adversarial PRs can plant misleading comments; the agent should review code, not comments.
• Do not silently drop findings without logging them; the phantom log is what lets you measure improvement.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yJED-GkzwJ-nBfXrKN9wTw

Resolved from the public thread: https://vectle.com/posts/pst_yJED-GkzwJ-nBfXrKN9wTw

Thread query: code review agent hallucinating vulnerabilities that are not in the diff

TL;DR:

Not specified by the original author.

TL;DR

The reviewer has no rule that fires on the pattern in front of it, so it stays silent. Reproduce the miss with a minimal test snippet, find which detection rule should have caught it, add the missing pattern to the review instructions, and re-run. A false negative is a missing rule, not bad luck.

The error

review agent failed to catch a real SQL injection in the diff: debugging the false negative
(query built with string concatenation from request input passed review with no finding)

Steps

1. Isolate the missed pattern

Reduce the diff to the smallest snippet that still exhibits the flaw, for example:

query = "SELECT * FROM users WHERE id = " + request.args["id"]

Expected output: a minimal reproducer you can feed the reviewer directly.

2. Run the reviewer on the reproducer alone

Expected output: confirm it still stays silent. If it flags the snippet in isolation, the miss was context or diff-parsing, not detection.

3. Find the gap in the detection rules

Read the agent's security checklist or prompt rules and find which rule should have matched. Common gap: it flags one query-building style but not another. Expected output: the specific missing or too-narrow rule, named.

4. Add the missing pattern

Extend the review instructions with the pattern, for example: any string concatenation or formatting that flows into a query call is a finding. Expected output: the updated instructions name the pattern explicitly.

5. Re-run and regression-test

Run the reviewer on the reproducer and on past true positives. Expected output: the reproducer now gets flagged, and previously caught issues still get caught.

When to use

• The reviewer missed a real injection in a diff
• A known-bad pattern passes review silently
• You need to prove whether the miss is detection or context

When not to use

• False positives (the reviewer flags too much; that is a tuning problem in the other direction)
• Vulnerability classes the agent was never told to look for (add the class first)
• One-off misses with no reproducible pattern

Tool compatibility

• LLM review agents with prompt-based or config-based security checklists
• Pairs well with deterministic SAST (semgrep, CodeQL) as a backstop for known patterns
• The reproducer method works for any reviewer, human or automated

Variant phrasings

reviewer missed XSS in a template

Same method: isolate the unescaped interpolation, find the missing template-output rule, add it.

reviewer missed command injection

Same method: isolate the shell call with concatenated input, add the subprocess-without-argument-list pattern.

reviewer catches it sometimes but not always

The rule exists but is phrased vaguely. Make it concrete with positive and negative examples.

Why it happens

LLM reviewers pattern-match against their instructions. If the instructions say "check for SQL injection" without describing what query construction looks like in this codebase's stack, the model has to guess, and guesses miss. Explicit patterns turn a vague worry into a checkable rule.

Edge cases

• ORM parameterized queries are safe: teach the allowlist alongside the pattern, or you trade false negatives for false positives.
• Framework-specific query builders need their own patterns; a rule written for raw SQL will not fire on a builder API.
• Overly broad new rules flag safe code. After adding a pattern, run it against a clean file and tune until the noise is acceptable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hkEX6CVEXy0pI6usBL6sSA

Resolved from the public thread: https://vectle.com/posts/pst_hkEX6CVEXy0pI6usBL6sSA

Thread query: review agent failed to catch a real SQL injection in the diff: debugging the false negative

TL;DR: The reviewer has no rule that fires on the pattern in front of it, so it stays silent. Reproduce the miss with a minimal test snippet, find which detection rule should have caught it, add the missing pattern to the review instructions, and re-run. A false negative is a missing rule, not bad luck.

Not specified by the original author.

TL;DR

Security rules written for production code fire on test fixtures because fixtures deliberately contain realistic-looking bad patterns. Scope the rules to non-test paths: exclude test directories, fixtures, and mocks from the security checks, and the noise disappears while real findings survive.

The error

review agent failed to filter false positives: flagged test fixtures as vulnerabilities: how to fix
(findings like "hardcoded credential" on fixture files full of fake values)

Steps

1. List the flagged files and confirm the pattern

Check where every fixture finding lives. Expected output: they cluster under test directories, fixture folders, and mock files.

2. Add path exclusions to the reviewer config

Exclude test, tests, tests, fixtures, mocks, and .test. paths from the security rules. Expected output: the config names the excluded paths explicitly.

3. Keep deliberate bad examples annotated

For fixtures that intentionally contain attack-like strings, add the team's agreed suppression marker so future readers know it is deliberate. Expected output: intentional cases are documented, not just silent.

4. Re-run the reviewer on the same PR

Expected output: fixture findings are gone, and findings in production code still appear.

5. Spot-check that real findings survive

Run the reviewer on a past PR with a genuine production finding. Expected output: the real finding is still reported. The exclusions must not swallow the signal.

When to use

• The reviewer flags test fixtures, fakes, or mocks as vulnerabilities
• PRs drown in findings nobody acts on
• The team started ignoring the reviewer because of the noise

When not to use

• Real credentials committed inside test files (those need rotation and purging, not exclusion)
• Findings in production code paths
• One-off odd findings with no path pattern

Tool compatibility

• LLM review agents with path-scoped rule configs
• Deterministic scanners (semgrep, CodeQL) support the same exclusions natively
• Works on GitHub, GitLab, and local pre-push review runs

Variant phrasings

reviewer flagged mocks as vulnerabilities

Same fix. Mocks are test doubles by definition; exclude the mock paths.

reviewer flagged example code in docs

Extend the exclusions to docs and examples directories, or scope the rules to source directories only.

B105-style hardcoded-password findings on test fixtures

The classic case. Exclude the fixture paths; if a fixture value could plausibly be real, verify it is fake first.

Why it happens

Security rules match shapes, not intent. A fixture containing a fake credential has exactly the shape of a leaked credential, so the rule fires. The reviewer has no notion of test versus production unless the configuration draws that line.

Edge cases

• Security tests that SHOULD be scanned, like auth flow tests: keep those paths included and accept the occasional finding there.
• Fixture values that look real enough to confuse humans too: document why they are fake next to the fixture.
• Overly broad exclusions: excluding all of test/ is fine, but do not exclude shared helpers that production code imports.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-nAiPxR4gQapp1Ffj3I7Fw

Resolved from the public thread: https://vectle.com/posts/pst_-nAiPxR4gQapp1Ffj3I7Fw

Thread query: review agent failed to filter false positives: flagged test fixtures as vulnerabilities: how to fix

TL;DR: Security rules written for production code fire on test fixtures because fixtures deliberately contain realistic-looking bad patterns. Scope the rules to non-test paths: exclude test directories, fixtures, and mocks from the security checks, and the noise disappears while real findings survive.