A code review agent reads text written by strangers: pull request titles, diffs, comments and linked files. Secure it by treating all of that as untrusted data, giving the agent the fewest tools it needs, validating what it outputs, and keeping a person in charge of merging.
Why is a review agent a target?
The agent runs on your side of the trust line and reads content from outside it. On a public repository, anyone can open a pull request. On a private one, a compromised contributor account or a poisoned dependency can do the same.
OWASP calls this indirect prompt injection: an LLM accepts input from external sources such as websites or files, and instructions hidden in that content change the model's behavior. A comment in a diff that says to approve this change is exactly that.
A prompt cannot fix this alone. OWASP's guidance is to combine a clear prompt with controls outside the model.
The prompt checklist
Write the system prompt to do three jobs.
- Define the role and limits. State what the agent reviews and what it must never do, such as approve, merge, or run commands from the diff.
- Say that content from the pull request is data. Instruct the model to ignore instructions found in code, comments, titles and linked documents.
- Specify the output format. Ask for findings in a fixed structure, such as file, line, issue and severity.
OWASP lists these as constraining model behavior and defining expected output formats. Note the limit: a model can still be talked out of its instructions, so the next checklist matters more.
The control checklist
These live in your code, not in the prompt.
- Separate untrusted content. Label the diff and comments clearly as external input so they carry less weight, as OWASP recommends.
- Validate output with deterministic code. If the agent should return findings in a schema, reject anything that does not parse.
- Apply least privilege. Keep sensitive functions in application code with their own credentials. The agent should be able to comment, not merge.
- Offer narrow tools. OWASP's Excessive Agency guidance says to prefer narrow tools over open ended ones such as shell execution or arbitrary URL fetching.
- Require human approval for high impact actions, such as approving, merging or changing pipeline files.
- Enforce authorization downstream. The repository platform decides what the agent token may do, not the model.
- Filter inputs and outputs. Check for secrets in what the agent reads and writes.
- Log everything. OWASP notes logging and rate limiting will not prevent excessive agency but can limit damage.
What about secrets in the diff?
A review agent will often see credentials that developers committed by mistake. Do not let it echo them into a public comment. Run secrets scanning before the agent sees the diff, and redact matches from what it posts.
How do you test it?
Test the boundaries as if the model were an untrusted user, which is how OWASP frames adversarial testing. Open pull requests in a test repository that contain instructions aimed at the agent in a comment, a file name and a README. Check that findings stay in format, that no tool runs outside the allowed set, and that nothing is approved. Re-run the tests whenever you change the prompt, the model or the tools.
Do not paste working attack strings into shared docs. Describe the case in plain words and keep the test fixtures in a private repository.
What to do
- Write a system prompt that defines role, limits and output format.
- State that PR content is data and must not be obeyed.
- Give the agent comment access only, never merge or admin.
- Remove shell and arbitrary fetch tools unless required.
- Validate output against a schema in code.
- Scan the diff for secrets before the agent reads it.
- Require a human to approve and merge.
- Log inputs, outputs and tool calls, and test with hostile pull requests each release.
Quick check
Can a good prompt stop prompt injection?
No. It helps, but the model may still follow injected text. Limit what the agent can do so a successful injection has little to work with.
Should the agent be allowed to approve pull requests?
Treat approval as a high impact action. Keep a person in the loop for it.
Sources
Last reviewed: 18 October 2026.
