Notifications
Clear all
Topic starter
02/08/2026 12:22 pm
TL;DR: Malicious code or dependencies can be crafted to mislead AI coding assistants and human reviewers through contextual cues, feedback loops, and convincing explanations, according to Checkmarx. The finding from Checkmarx Zero shows that human-in-the-loop workflows can still be manipulated, so trust in AI-assisted development now needs stronger verification and traceability controls.
NHIMG editorial — based on content published by Checkmarx: AI Can Now Be Tricked Into Helping Attackers, Even With a Human in the Loop
Questions worth separating out
Q: How should security teams use AI-assisted code review safely?
A: Use it as a triage layer that accelerates first-pass detection, then require a separate validation step for findings that affect access control, authentication, secrets, or release gating.
Q: Why do human reviewers still miss malicious code when AI assistants are involved?
A: Because the assistant can provide a plausible explanation that makes unsafe code look normal, and reviewers often trust that explanation under delivery pressure.
Q: What breaks when AI assistants learn from misleading developer feedback?
A: The feedback loop starts to reinforce the attacker’s framing, so the assistant becomes more likely to approve the same pattern again.
Practitioner guidance
- Implement independent approval gates for AI-assisted code changes Require high-risk packages, dependency updates, and security-sensitive refactors to pass a separate human review that does not rely on the assistant’s own explanation or confidence score.
- Add package blast radius analysis to dependency review Map what a new package can reach, modify, or influence before it is merged.
- Treat AI output as untrusted input Validate any assistant recommendation against source code, provenance records, and runtime behaviour.
What's in the full report
Checkmarx's full article covers the operational detail this post intentionally leaves for the source:
- The Claude Code experiment design, including how the malicious package behaved differently across runtime contexts.
- The specific feedback cues that caused the AI assistant to misclassify unsafe behaviour as acceptable.
- The developer interaction pattern that allowed the assistant’s explanation to override human concern.
- The vendor’s proposed workflow safeguards for in-IDE scanning, remediation guidance, and blast-radius analysis.
👉 Read Checkmarx’s analysis of Lies-in-the-Loop attacks in AI-assisted development →
Lies-in-the-loop attacks: what do they mean for secure code review?
Explore further
02/08/2026 1:22 pm
Lies-in-the-Loop is a software trust failure, not just an AI safety issue. The attack works because review systems assume that an assistant’s confidence, explanation, or feedback loop reflects actual safety. That assumption breaks when the artefact is designed to behave differently under specific conditions. For practitioners, the lesson is to treat AI-assisted approval as a risk signal, not as assurance.
A question worth separating out:
Q: What should teams do when AI-assisted code review and supply chain risk overlap?
A: They should tighten provenance checks, restrict dependency reach, and require security review for packages or changes that could alter build behaviour. The important question is not whether the code looks safe once. It is whether the artefact can later behave differently and expand its blast radius after approval.
👉 Read our full editorial: Lies-in-the-loop attacks expose trust gaps in AI coding assistants
