They exploit the gap between what an assistant can explain and what the code actually does. A malicious package can look safe in the review context, then activate harmful behaviour when runtime conditions change. If the assistant learns from feedback, it may also reinforce the wrong conclusion and increase the chance of future approval.
How lies-in-the-loop attacks exploit the review context
Lies-in-the-loop attacks succeed because an AI reviewer is usually judging code from an incomplete, narratable model of behaviour. The package, patch, or dependency can present itself as benign under the review prompt, while the harmful path only appears after a runtime condition, environment variable, permission boundary, or delayed trigger changes. The review feels consistent even though the execution path is not.
That gap matters most when the review system is optimising for plausible explanation instead of verified behaviour. If the assistant can be steered by comments, metadata, test scaffolding, or feedback from prior approvals, the attacker is no longer just hiding code, they are shaping the reviewer’s belief about the code. That is why AI Coding Agents Security Guide is useful here: the risk is not only what the code does, but what the assistant is allowed to infer from the surrounding context.
A practical way to think about the attack is as a mismatch between semantic review and operational truth. The malicious payload can stay dormant during static inspection, appear harmless in a diff, or behave safely in a constrained test harness. Once deployed, it can activate through environment-specific branches, network calls, dependency resolution, or tool access that were absent during review.
Why the attack works even when the code looks clean
These attacks exploit the fact that AI-assisted review is often conversational and probabilistic. The model may be asked whether a package is safe, then later receive follow-up cues that reinforce the same mistaken conclusion. If the workflow treats the assistant’s explanation as evidence, the attacker can win by making the explanation feel stronger than the actual execution trace.
The problem gets worse when the review loop learns from user feedback, especially if approvals are used as training signals. A single misleading approval can bias future judgments toward the same pattern, which means the attack can scale beyond one review session. The package does not need to be universally safe, it only needs to be convincing inside the exact context the assistant sees.
This is why code review must separate narrative confidence from execution certainty. A package that is “well explained” is not the same thing as a package that is bounded, reproducible, and safe under the conditions where it will actually run.
What defenders should verify before trusting AI-assisted review
The strongest control is to force the review process to prove behaviour, not merely describe it. That means verifying installation scripts, post-install hooks, network destinations, filesystem effects, privilege assumptions, and any conditional logic that only executes outside the review sandbox. It also means treating package metadata, readme text, and assistant-generated summaries as inputs, not proof.
For supply-chain review, the most useful question is often, “What would this do when the environment changes?” A review that only inspects the obvious path will miss delayed activation, feature-flag abuse, dependency substitution, and payloads that become dangerous after first launch, after update, or after a specific configuration is present. Analysis of Claude Code Security is relevant because it highlights how code assistants can reason about codebases while still being vulnerable to misleading context.
When the review tool itself accepts feedback, practitioners should check whether approval signals are being reused too broadly. If the assistant is allowed to “learn” from a shallow explanation, future review quality can degrade without any obvious alert. In that case, the right response is to tighten the review evidence, not to trust the model’s confidence score.
Risk and Threat Considerations
These attacks create a trust failure in the review pipeline: defenders believe they are screening code for harmful behaviour, but the attacker is actually screening the reviewer for what it will accept. The result is a persistence-friendly supply-chain problem, because a convincing lie at review time can become a durable approval for code that changes behaviour later.
Failure mechanism: The attacker exploits conditional execution, misleading context, or reinforcement from prior feedback so the assistant concludes the package is safe when the runtime path is not.
Impact: Harmful code can enter builds or deployments with a false sense of assurance, increasing the chance of dependency compromise, hidden exfiltration, or future misclassification by the same review system.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while OWASP ASVS, SLSA and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Architecture | AI-assisted code review must validate behavior beyond explanation. |
| Recommendation — Verify runtime behavior, not just static narrative, before approving code. | ||
| SLSA | Supply Chain Integrity | The attack is a software supply-chain deception problem at review time. |
| Recommendation — Require provenance and build integrity checks before trusting packages. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | This is an application supply-chain and review assurance problem. |
| Recommendation — Test code and dependencies in controlled environments before deployment. | ||
| MITRE ATT&CK | T1036 — Masquerading | The attacker makes malicious code appear benign in review context. |
| Recommendation — Hunt for code that disguises malicious behavior behind benign context. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | Review tools and agents can be manipulated through trusted inputs and unsafe assumptions. |
| Recommendation — Validate externally supplied inputs and assumptions before consuming them. | ||
Practitioner Guidance
What to prioritise: Require at least one review step that inspects actual behaviour, such as sandbox execution, hook inspection, or network and file-system tracing, before any AI-generated approval is trusted.
Common mistake: Treating the assistant’s explanation as the control outcome instead of one input to a deeper verification process. If the code only looks safe when described, assume the review is incomplete.
Decision rule: If a package’s safety depends on “normal” runtime conditions that were not directly observed, treat the item as unresolved until those conditions are tested or the risky path is removed.
Practitioner takeaway: The goal is not to make AI-assisted review more confident, it is to make it harder for an attacker to win by controlling the story the assistant tells about the code.