Prompt injection is now a code review problem

Code review has always assumed that the dangerous part of a diff is the code. Prompt injection breaks that assumption. When agents write code and AI reviewers read it, every piece of text in the repository (comments, READMEs, docstrings, issue bodies, commit messages) becomes potential input to a model that acts on what it reads. A prompt injection code review is the habit of reading that text as attack surface: looking for instructions addressed to machines, hidden in places only machines will look. Addy Osmani flags this risk directly in his essay on agentic review, and it is worth turning the flag into a checklist.

How text becomes an attack

The mechanics are mundane, which is what makes them easy to miss. A coding agent asked to fix a bug reads the surrounding files for context: source, comments, docs, config, sometimes an issue thread. All of it lands in the same context window with roughly the same authority. If a dependency’s README, a vendored file, or a drive-by contributor’s comment contains a sentence crafted as an instruction, the agent may follow it: fetch this URL, add this dependency, weaken this check, do not mention this change. The same applies one layer up: an AI reviewer summarizing a PR reads the PR description an attacker wrote. Nothing needs to be executed for the attack to work. The payload is prose, and prose passes every linter you have.

A prompt injection code review checklist

None of these patterns is proof of an attack; each is a reason to slow down. What they share is a simple tell: text whose only plausible reader is a machine.

• Comments addressed to models. Imperative text in comments or docstrings that gives directions no human teammate needs: approve this file, do not flag the following function, treat this module as reviewed.
• Override phrases. Strings in the family of ignore previous instructions, you are an assistant, system prompt, new instructions follow. Grep for them in diffs; they have almost no legitimate reason to appear in source text.
• Unusual encodings. Base64 blobs in documentation, zero-width or bidirectional Unicode characters in otherwise plain prose, HTML comments in markdown that render invisibly. Hidden from the human eye, fully visible to the tokenizer.
• Suspicious URLs in docs. Links in READMEs, setup guides, or code comments that no human workflow requires, especially ones an agent might be induced to fetch. A URL an agent follows is code you did not review.
• Instructions in fixtures and test data. Natural-language directives inside files agents are likely to ingest wholesale: sample documents, seed data, recorded API responses.

Docs and comments are attack surface now

The uncomfortable consequence: the parts of a diff reviewers habitually skip are exactly the parts injection targets. A markdown change used to be the safest thing in the queue, the classic rubber-stamp candidate. In a pipeline where agents read those files as operating context, a README edit can redirect more behavior than a code edit, while attracting a fraction of the scrutiny. This does not mean every doc change needs paranoid review; it means provenance starts to matter for text the way it always has for code. External contributions, vendored content, and machine-generated files deserve the question: who wrote this text, and what reads it downstream?

Human review is the backstop

It is tempting to answer a model-shaped threat with a model-shaped defense: have the AI reviewer watch for injections. Use those checks, but do not lean on them, because the AI reviewer sits inside the same attack surface; it reads the text the injection lives in, and a sufficiently good injection is, by definition, the one that persuades the checker. This is a specific instance of the division of labor we argued for in what AI should do in code review: machines pre-filter, pattern-match, and flag; a human holds the authority. For files an agent touched or ingested, the backstop is a person reading with the checklist above in mind, and it lines up with the rule from agentic code review: a human owns the merge, and injected text cannot socially engineer someone who actually read it.

When you find one

Treat a suspected injection like a security finding, not a nitpick. Do not merge around it: reject the change and pin down where the text came from, whether a contributor, a dependency, or an upstream doc. If an agent already ingested it, review what that agent produced afterward with fresh eyes, since steering may have already happened. Then add the pattern to your automated checks so the next occurrence is caught by machinery instead of luck. Keep perspective: most repos will never see a deliberate injection, and this checklist costs minutes. But the cost asymmetry is the point. Reading the README carefully is cheap; discovering that your agents have been taking instructions from a stranger’s comment is not.