Direct and indirect
Direct injection is a user typing something to override the application's behaviour. It is the version everyone has seen, and it is the less serious one: the attacker affects their own session.
Indirect injection is the instruction planted in content the application fetches on its own. A web page the agent summarizes. A resume it screens. A support ticket it triages. A document in a shared drive. Here the attacker never touches your interface and reaches whatever the agent can reach on someone else's behalf.
Why it is not a filtering problem
The intuitive fix is to detect malicious instructions and strip them. This helps and it does not close the class, because the attacker writes prose and prose has unlimited phrasings.
Worse, the usual detector is another language model reading the same untrusted text, so it inherits the same weakness. Filtering is defence in depth. It is not the boundary.
The severity is in the tool list, not the model
A model that only produces text has a bounded worst case: it says something wrong. A model wired to tools has a worst case equal to everything those tools can do.
So the question that sets severity is never "can the model be influenced" — assume yes. It is "what can it do once influenced", and that is answered by reading credentials and scopes, not by testing the model.
What actually reduces the risk
The durable controls are permission controls. They work whether or not the model is fooled.
- Least privilege per tool: a credential scoped to the one job that tool does
- Human approval in front of anything irreversible or externally visible
- No model output passed to an interpreter, a shell, or a query without escaping
- Logging of every tool call with arguments, so an incident can be reconstructed
- Separation so one user's or tenant's context cannot leak into another's