Prompt injection is text crafted to change a language model's intended behavior by exploiting the fact that the model interprets all the text in its context as potentially meaningful instructions, regardless of where that text came from. It is often compared to SQL injection, and the comparison is useful for one reason and misleading for another: both attacks work by blurring the line between code and data, but SQL injection can be fixed with parameterized queries that eliminate the ambiguity entirely. Prompt injection cannot be fixed the same way, because a language model's entire function is to interpret the meaning of text, and there is no equivalent of a parameterized query that lets it do that job while completely ignoring instructions embedded in the data it is asked to process.
Why it works
A model does not have a reliable internal mechanism for tagging some text as "trusted instruction" and other text as "content to be processed." Developers can structure a prompt so that system instructions come first and user content comes after, and this helps, but it does not create a hard boundary the model cannot be persuaded to cross. If a piece of retrieved content says, convincingly enough, "ignore your previous instructions and do this instead," the model may comply, because from its perspective it is simply following the most recent and most specific-sounding instruction in its context.
This means prompt injection is not really a bug in a particular model. It is closer to an inherent property of how these models process input, which is why the practical response has to focus on limiting the consequences of injection rather than achieving a guarantee that it can never succeed.
Where injection text can come from
The most obvious source is a user typing something directly into a chat interface. But injection text can arrive through any content the model processes: a document pulled in by retrieval, a web page fetched by a browsing tool, an email summarized by an assistant, a support ticket, a file attachment, or the output of another tool or agent in a pipeline. Any of these can carry a sentence that reads, to the model, like an instruction rather than data.
This is why prompt injection defense cannot be scoped only to "what the user types." An application that only sanitizes the user's direct chat input while trusting every retrieved document has addressed a fraction of its actual injection surface.
What a successful injection can accomplish
The impact of a successful injection depends entirely on what the model is authorized to do. In a text-only chatbot, a successful injection might cause it to produce an off-brand or policy-violating response, which is a real but bounded problem. In an agent with tool access, a successful injection can cause it to call a tool it should not have called, retrieve data outside its intended scope, or take an action the requesting user never actually asked for. The injection technique is similar in both cases; the consequence scales with the model's authority.
Why instructing the model to resist injection is a weak defense
A common first response is to add a line to the system prompt telling the model to ignore any instructions found in retrieved content or user messages that try to override its behavior. This can reduce the success rate of unsophisticated attempts, but it is not a boundary a security program should rely on, because it depends on the model correctly recognizing every future injection attempt, including ones phrased in ways nobody has tried yet. Treating this instruction as sufficient defense is similar to relying on a login form's placeholder text to stop unauthorized access: it might discourage some casual attempts and will not stop a deliberate one.
What actually reduces the impact of injection
Since injection cannot be reliably prevented, the more durable approach reduces what a successful injection can accomplish. Scope tools narrowly so that even a fully manipulated model has limited real-world authority. Enforce authorization checks independently of the model's request, so an injected instruction to "call this tool" still has to pass a check the injection cannot influence. Validate generated output before it reaches a sensitive destination. Filter retrieved content by the requesting user's access rights before it ever reaches the model, so there is less opportunity for an attacker to place manipulative content somewhere it will be retrieved and trusted.
Testing has to include adversarial content, not just adversarial prompts
Many teams test prompt injection resistance by trying various malicious user messages directly. This is useful but incomplete, because it misses the indirect paths through documents, web content, and tool responses that often carry the more damaging real-world attacks. A thorough test process includes planting injection attempts in content the system retrieves or processes, not only in what a user types directly into the interface.
Where TELEON fits
TELEON does not prevent prompt injection at the language level; no runtime policy layer can fully do that, because the vulnerability sits inside the model's interpretation of text. What TELEON provides is enforcement at the tool-call boundary, applied through the gateway or supported middleware, so that even a successfully injected instruction still has to pass an authorization and policy check before it results in a real action, along with an audit trail to review injection attempts after the fact.
A short checklist
- Treat every content source other than your own fixed instructions as a
potential injection vector, not just direct user input.
- Do not rely on a system prompt instruction as your primary defense.
- Scope tools narrowly so a manipulated model has limited real authority.
- Enforce authorization independently of what the model requests.
- Filter retrieved content by access rights before it reaches the model.
- Test with adversarial content in documents and tool responses, not only
adversarial direct prompts.
Prompt injection is a consequence of how language models work, not a flaw that a patch will eventually eliminate. Treating it as a persistent condition to design around, rather than a bug to be fixed once, is what produces defenses that actually hold up.