A pull request from someone you do not know is untrusted input, and an AI reviewer reads all of it: code, comments, descriptions, and file names. Any of that text can try to steer the reviewer. Limit what the review bot can do, keep secrets away from it, and do not let its verdict approve a merge.
How the attack works
OWASP defines indirect prompt injection as the model ingesting external content, such as web pages or files, that contains instructions which alter its behavior. A pull request is external content. A comment in a changed file can address the reviewer directly, for example by claiming the change was already audited.
OWASP also notes that the model can parse content even when humans cannot see it, which is why hidden text deserves attention. See hidden text and invisible characters in LLM inputs.
What an attacker wants
- A favorable review, so a malicious change looks safe and a distracted human approves it.
- Data. If the bot can read secrets or private repositories, it may be persuaded to reveal them in a comment.
- Actions. If the bot can push, label, merge, or run commands, an attacker tries to trigger those.
The third is the most dangerous, which ties to OWASP's excessive agency risk: damaging actions caused by too much functionality, permission, or autonomy.
Reduce the impact
Remove capabilities. A review bot that can only read the diff and post a comment has a small blast radius. Avoid giving it shell access, write access, or tokens for other systems.
Match privileges to the source. The UK NCSC suggests that when a model processes information from a party, its privileges should drop to those of that party. A review of an outside contributor's change should run with outside contributor level access.
Keep secrets out of reach. Do not run the reviewer in an environment that holds deployment credentials. If you use CI to trigger it, read the guidance on how fork pull requests are handled: pull_request_target vs pull_request.
Keep a human decision. Let the bot comment, not approve. If it must gate something, gate on deterministic checks such as tests and static analysis, and treat the model's opinion as advisory.
Log everything. Record the inputs and the outputs so unusual comments are visible later.
Design for the case where it fails
The NCSC recommends assuming the model can be manipulated and using deterministic safeguards to constrain what the system can do. If a successful injection would only produce a wrong comment, a human reviewer is still the backstop. If it would merge code, redesign.
Quick check
Can I just tell the reviewer to ignore instructions in the code?
You can, and it may help a little, but it is not a control. OWASP notes that no fully reliable prevention method is known. Limit capabilities instead.
Sources
- LLM01:2025 Prompt Injection (OWASP GenAI)
- LLM06:2025 Excessive Agency (OWASP GenAI)
- Prompt injection is not SQL injection (UK NCSC)
Last reviewed: 19 October 2026.
