Prompt injection is an operations problem

The demonstrations of prompt injection tend to look like party tricks: a hidden instruction in a web page, a chatbot that follows it instead of the user, a screenshot of the model doing something it obviously shouldn’t have. That framing makes it easy to file the whole category under "interesting research problem, not yet my problem," because a party trick implies a controlled setting and a researcher who set it up deliberately. What changes the picture is realising the exact same mechanism sits underneath an ordinary coding agent doing an ordinary job — reading a pull request, a commit message, an issue comment — none of which were written by you, all of which the agent will read as part of doing its work, and none of which the agent has any principled way to distinguish from your own instructions once they are sitting in its context.

An agent that reads a pull request title containing text aimed at the model rather than at the human reviewer, and acts on it, is not a hypothetical. It is the same failure as the web-page version, wearing developer-tooling clothes instead of chatbot clothes. The text arrives through a channel the agent was told to trust — the PR system, the same place legitimate instructions come from — and the model has no reliable internal signal that separates "the human who launched me typed this" from "this string appeared in content I was asked to read." Every mitigation aimed purely at the model — better prompting, more careful system messages, training against known injection patterns — reduces the frequency of the failure without eliminating the category, because the category is structural: any model that reads untrusted text as part of doing useful work can, in principle, be steered by that text.

Which is why the right response to this is not a better prompt. It is treating the agent the way you would treat any other actor whose behaviour you cannot fully predict in advance: give it only the permissions the specific job requires, and design so that a successful injection has somewhere small to land rather than somewhere large. An agent reviewing a pull request does not need write access to production credentials. An agent deploying a service does not need read access to every other service’s secrets. This is the same discipline as scoping a token to one job instead of handing out a broad one because it is convenient — except here the attacker is not a compromised credential, it is a string of text the agent was always going to read as part of its normal function, and no amount of model-level defence removes the need for the operational one underneath it.

Framing this as an operations problem rather than a research problem changes what you build first. A research framing chases better detection: classify the input, flag suspicious instructions, red-team the model against known patterns. Useful work, and worth having, but it treats the model as the last line of defence, which means every miss is a full incident. An operations framing accepts that some fraction of injected instructions will get through whatever detection exists, and asks what the actual damage ceiling is when that happens — what can the agent touch, what can it send data to, what does it have standing permission to do without a human in the loop. That ceiling is something you can engineer directly, today, with tools that have nothing to do with the model’s own judgement.

The uncomfortable part of taking this seriously is that it means assuming, permanently, that any agent reading content it did not generate itself might act on something hidden in that content. Not as an edge case to patch once and move past, but as a standing property of the category of system, the same way you assume a network request might fail and design retries rather than hoping it won’t. The agents that hold real permissions and read real untrusted content are the ones where that assumption earns its cost.