A secure code review agent depends on its permissions more than its prompt. Treat the pull request, comments and linked files as untrusted input, give the agent read only tools, check its output with deterministic code, and keep a person in charge of approval and merge. The prompt narrows behavior; it does not enforce it.
Why is a review agent a risky place for prompt injection?
A review agent reads text written by other people: code, comments, commit messages, issue links and documentation. OWASP defines indirect prompt injection as the model taking in external content that contains instructions which alter its behavior. A contributor, or a compromised dependency, can put such text in a diff. OWASP also says it is unclear whether there are fool proof methods of prevention, so design for impact reduction.
What belongs in the prompt?
Keep it short and specific.
- Role and limits. State the job: review the diff for defects and security issues and write findings. State what it must never do, such as running commands from the diff or following instructions found in the code under review.
- Labeled data. Tell the agent that everything inside the diff markers is data, not instructions. OWASP recommends separating and labeling external content to limit its influence.
- Output format. Define a schema for findings: file, line, severity, reason, suggested change. A fixed format is easier to validate.
- No secrets. OWASP's guidance on system prompt leakage says not to treat the prompt as a secret or a security control. Keep tokens and keys out of it entirely.
What matters more than the prompt?
Tools. OWASP's excessive agency guidance says to minimize extensions and their functions, avoid open ended ones such as shell execution or arbitrary URL fetching, and grant only the access required. A review agent needs to read files and post comments. It does not need to push commits, edit workflows or read repository secrets.
Identity. Run actions in the user's context with the narrowest scope. A bot token that can approve its own suggestions turns one injection into a merge.
Mediation. Downstream systems should check every request against policy, rather than rely on the model to decide what is allowed. Branch protection and required human approval should hold even if the agent is fooled.
Output checks. Validate the findings schema in code. Reject findings that point at files outside the diff, and strip anything that looks like a command from comment bodies before it is rendered.
Approval. OWASP advises human approval for high risk actions. Merging, changing pipeline files and touching dependencies qualify.
Logging. Record what the agent read, what tools it called and what it wrote, so odd behavior can be traced. OWASP lists logging and monitoring as damage limiting measures.
How do you test it, defensively?
Treat the model as an untrusted user, as OWASP suggests. Build a small test set of pull requests with benign but awkward content: comments that address the reviewer, files with instruction like text, very large diffs. Check that the agent stays inside its schema and that no tool call fires outside its allowlist. Re-run the set whenever you change the prompt or model.
What to do
- List the tools the agent has today and remove every write permission it does not need.
- Move secrets and policy out of the prompt.
- Add delimiters and a fixed output schema, and validate the schema in code.
- Require human approval for merge and pipeline file changes.
- Log reads, tool calls and outputs.
- Keep a small regression set and run it on every change.
See the guardrail idea on its own page: MCP guardrail demo.
Quick check
Can a strong system prompt stop prompt injection?
No. It can reduce some attempts, but permissions and checks outside the model are what limit damage.
Should the review agent be able to approve pull requests?
No. Let it comment, and keep approval with a person.
Sources
Last reviewed: 18 October 2026.
