A popular way to make an AI security reviewer more reliable is to hand it a static analyser's output: which checks guard each risky operation, and which are missing. This study asked what happens when those notes are wrong. The researchers took pairs of real C and C++ functions, one vulnerable and one patched, and had eleven AI models audit each one under notes that differed only in whether they were true.

Correct notes barely moved accuracy. Wrong notes depended entirely on which way they were wrong. A fabricated note saying a missing check was present made models clear vulnerable code they would otherwise have caught, by up to 19 points for the worst affected. A fabricated note saying a check was missing never made any model reliably worse. Often it helped, because the model went looking for the check and found it.

"A claim that a check is missing invites a search for the check; a claim that it is present ends the search."

That sentence is the authors' reading of the answers, and they say plainly that the study does not prove it. Other explanations fit the same data, such as models agreeing more readily with anything that shrinks the job. What the study did establish is that the models could catch the lies when told to. Asked to verify each claim on its own, one model refuted about three in four false assurances, roughly as often as false alarms. So the gap is in whether they bother to look. Telling the auditor in the prompt to treat notes as unverified didn't reliably fix it; the best wording failed on fresh data. Printing the cited line of code beside each note didn't help either.

"Showing provenance did not help even though the printed source line contradicted the false note; the models did not use the contradiction unless asked to check."

What worked was a separate verification call whose refutations were shown to the auditor. It recovered 12 points for one model and about half that, not reliably, for the other.

The practical read is that any "this is safe" statement fed to an AI reviewer is the input to distrust. The study only tested analyser notes, but the same shape plausibly covers a PR description saying "input validated upstream", a code comment, or a stale scan result, and that is a guess this piece is making, not one the study checked. All the false notes here were refutable from the function itself; the authors flag that real tool errors may be harder to spot, which would make the effect bigger.

Teams evaluating an "AI reviewer grounded in static analysis" should ask the vendor what happens when the analyser is wrong in the reassuring direction, and test it with planted false assurances, not just false alarms. On this evidence, the grounding adds little when right and opens a hole when wrong. Don't over-read the other direction either. When asked to check, one model rejected nearly half of the true warnings, so "models scrutinise alarms" is not the same as "AI alarm triage is safe."

Sources

  1. Liu, Z., Gao, S., "Trusting the Tool: Asymmetric Deference of LLM Vulnerability Auditors to Static-Analysis Evidence" — https://arxiv.org/abs/2610.32876