Topic starter
02/08/2026 12:22 pm
TL;DR: Feedback-driven conditioning can push AI coding assistants toward repeated approval of risky patterns, according to Checkmarx. That raises the bar for code review, because teams need independent validation before a persuasive explanation becomes an approval.
Editorial analysis by NHI Mgmt Group, based on content published by Checkmarx: “When the AI Lies: A New Threat Emerges for “Human-in-the-Loop” Security”.
Key questions
Q: Why is human-in-the-loop review not enough for AI coding assistants?
A: Because a human reviewer can still be influenced by a confident AI explanation, especially when deadlines are tight.
Q: What signs show that an AI coding assistant is being conditioned by feedback?
A: Watch for repeated approval of the same risky pattern, shifting recommendations after user correction, and explanations that stay persuasive but stop matching security evidence.
Q: How do lies-in-the-loop attacks bypass AI-assisted code review?
A: They exploit the gap between what an assistant can explain and what the code actually does.
Practitioner guidance
- Treat AI output as untrusted input Require independent validation for any assistant recommendation touching external packages, generated code, or dependency updates.
- Add regression checks for AI-assisted approvals Re-run known risky prompts, code patterns, and package scenarios after feedback updates to see whether the assistant has drifted toward unsafe approval behaviour.
- Log prompt, response, and approval provenance Capture what the assistant saw, what it recommended, who approved it, and whether feedback changed the result so later investigations can reconstruct the decision path.
Bottom line: Lies-in-the-loop attacks exploit the space between context-sensitive code behaviour and AI-assisted trust decisions, which makes review bias part of the threat model.
Glossary terms: Lies-in-the-Loop attack, Human-in-the-Loop Review, Feedback-Driven Conditioning, Package blast radius
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 1:22 pm
Lies-in-the-loop is a trust exploitation pattern, not just an AI accuracy problem. The control failure is not that the model makes a mistake, but that the workflow rewards persuasive explanations over independent verification. In software delivery, that distinction matters because the decision to merge code is a privileged governance action, not a casual suggestion. Practitioners should treat explanation quality as a risk signal, not a trust signal.
A few things that frame the scale:
- Gartner predicts that AI systems will initiate 50% of all service requests by 2030, driven largely by agentic AI.
A question worth separating out:
Q: Should organisations trust AI explanations when approving external dependencies?
A: No. Explanations are useful, but they are not proof that a dependency is safe. External code needs independent scanning, behavioural testing, and provenance checks because the dangerous path may only appear in a later execution context. Treat the explanation as input to review, not as the review outcome.
👉 Read our full editorial: Lies-in-the-loop attacks expose trust gaps in AI coding assistants