Prompt injection is often described as a trick: someone hides an instruction in a web page or a document, and the model follows it. That description is accurate but it encourages the wrong response. If the problem is a clever sentence, the fix seems to be a cleverer system prompt. In practice, no wording reliably prevents a capable model from being influenced by text it has been asked to read.
The more useful framing is architectural. A language model does not distinguish firmly between the instructions it was given and the content it is processing. Any system that combines three things is therefore exposed: access to untrusted content, access to sensitive data, and the ability to take actions or send information outward. Remove any one of the three and the risk changes character. Keep all three and the system's safety depends on the model never being persuaded, which is not a property anyone can guarantee.
Where untrusted content enters
Teams tend to underestimate how many entry points exist. Retrieved documents, emails, support tickets, calendar invitations, web search results, file names, spreadsheet cells and the outputs of other tools can all carry text that the model will read. In agentic systems the problem compounds, because the output of one step becomes the input to the next. Threat researchers reported indirect injection observed in the wild throughout 2026, targeting agents that browse and act on behalf of users.
Defences that hold
- Separate reading from acting. A component that processes untrusted content should not hold the permissions to act on its conclusions. Its output can be passed, as data, to a more constrained step.
- Scope tools to the task. If an agent summarising inbound email has no tool that can send email or reach the internet, an injected instruction to exfiltrate data has nowhere to go.
- Confirm outside the model. Consequential actions should require approval through an interface the model cannot write to, showing the person exactly what will happen.
- Constrain outputs. Structured outputs, allow-listed destinations and blocked rendering of arbitrary links and images close common exfiltration routes.
- Test adversarially and keep testing. Injection testing belongs in the evaluation suite that runs on every change, not in a one-off review before launch.
What detection can and cannot do
Classifiers that look for injected instructions are useful as one layer, and they improve over time. They should be treated as a way to reduce the volume of attempts that reach the model, not as a boundary. An attacker only has to succeed once, and the design should assume that some attempts will pass.
A practical test
For any AI system that reads external content, ask a simple question: if the model were fully persuaded by the worst text it could encounter, what is the most damaging thing it could do with the tools and data it has? If the answer is unacceptable, the architecture needs to change. If the answer is tolerable, the remaining work is monitoring and response. That question, asked early, is usually cheaper than any amount of prompt refinement asked late.