Approved Without Inspection - Repository Poisoning Against AI Code Review

Can a repository be manipulated to convince an AI reviewer to look the other way? Investigate whether planted instructions can make a coding agent skip vulnerable code, suppress its findings, or falsely report that an insecure change is safe.

You ask a coding agent to review a change request for security problems. It reads the repository and reports that everything looks fine. But did it really inspect the relevant code, or did something inside the repository persuade it that the work had already been done?

Coding agents encounter comments, documentation, and configuration while deciding what to inspect and how to report their findings. An attacker who can alter these materials may try to redirect the review itself: exclude a file, discourage further investigation, downplay a vulnerability, or induce a reassuring verdict. In the end, the vulnerability goes undetected and is pulled into the project.

This study investigates repository poisoning aimed at omissions and false reassurance during security review. Existing work examines adversarial comments and manipulation of agent judgments, so the first step is to establish what is already known. The question is how these attacks behave in a full repository workflow, where the agent chooses files, consults tools, and assembles a final report.

You will build paired versions of repositories containing documented vulnerabilities: one with ordinary context and one with attacker-controlled instructions. This allows you to ask whether the attack makes the agent miss a problem it would otherwise find. You will also distinguish an incomplete review from an explicit claim that the code is secure.

The project starts with one language, a small set of vulnerability types, and a reproducible review setup. From there, you can investigate which injection locations matter, whether the effect transfers between agents, or how a defense changes both security and review quality. The main contribution is a careful account of when repository content can undermine the review process, including cases where it fails to do so.

Goals

a) Review and define. Read work on repository prompt injection, adversarial code comments, and automated security review. Define an attacker who can change specified repository text but cannot alter the trusted review request or the vulnerable code being assessed. Specify what the agent is expected to inspect and report.

b) Establish a benchmark. Assemble manageable repository tasks with independently verified vulnerabilities and fixed counterparts. Check the ground truth using patches, tests, or manual analysis. Measure review performance without poisoning and include benign documentation edits as controls. Keep code semantics and review budgets comparable across versions.

c) Attack the review. Reproduce a relevant technique, then investigate a focused set of repository-based variants. Can an instruction change which files the agent opens, whether it runs a check, or which findings reach the final report? Record file access, tool calls, and reports; these show observable actions, not proof of what the model understood internally.

d) Evaluate and explain. Measure changes in vulnerability recall, false alarms on fixed code, and explicit false assurances. Report attack success both across all tasks and on tasks where the clean review finds the vulnerability. Separate skipped inspection, omitted findings, explicit approval, and interrupted runs. Repeat trials and use held-out repositories to check that the result extends beyond the examples used to develop the attack.

If time permits, test a focused defense, such as trusted review-scope instructions, independent static-analysis checks, or evidence requirements for verdicts. Measure its effect on useful findings and review cost as well as attack resistance.

The expected outcome is a reproducible evaluation and an explanation of how repository poisoning affects review coverage and reporting. A well-supported finding that a workflow resists these attacks is also a useful result.

Learning outcomes

• hands-on experience with prompt injection and the security of coding agents
• understanding of automated code review, vulnerability detection, and the risks of false reassurance
• proficiency in constructing paired experiments with independently checked security ground truth
• experience tracing agent actions and evaluating both review coverage and reported findings
• experience with responsible offensive-security research and reproducible software experiments
• experience working in an exciting and active research environment, with opportunities to develop your results into a scientific paper

Qualifications

• interested in software security, modern code review, and AI-assisted development
• comfortable programming in Python and reading code in at least one widely used language
• familiar with Git, tests, and common vulnerability types, or willing to learn them
• experience with LLM tools, coding agents, or static analysis is useful
• willing to inspect experimental results carefully and distinguish genuine attack effects from ordinary review mistakes

Supervisors

• Leon Moonen
• Fernando Ruiz

References

• Thornton (2026). Can Adversarial Code Comments Fool AI Security Reviewers -- Large-Scale Empirical Study of Comment-Based Attacks and Defenses Against LLM Code Analysis.
  Finds no statistically significant reduction in detection accuracy from the tested adversarial comments, providing a useful baseline for investigating broader repository workflows.
• Isbarov et al. (2026). GitInject: Real-World Prompt Injection Attacks in AI-Powered CI/CD Pipelines.
  Evaluates attacks in live GitHub workflows, including judgment manipulation, and studies workflow-level countermeasures.
• Greshake et al. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection.
  Foundational work on attacker-controlled content being treated as instructions by LLM applications.