Prompt engineering, structuring instructions carefully, separating trusted and untrusted content with clear delimiters, explicitly warning the model about manipulation attempts, can measurably reduce how often prompt injection succeeds. It cannot eliminate the risk, and understanding why is useful for deciding how much weight to put on it relative to other defenses.
What prompt engineering can realistically do
Clear structural separation between system instructions and user or retrieved content, using explicit delimiters and consistent formatting, makes it somewhat harder for injected text to be mistaken for an authoritative instruction. Explicitly telling the model that content within a certain section is untrusted and should be treated as data rather than instructions can reduce the success rate of straightforward injection attempts. Techniques like asking the model to reason about whether a request seems consistent with its intended task before acting can catch some obviously mismatched instructions.
These techniques are worth doing. They measurably lower the rate at which naive or moderately sophisticated injection attempts succeed, which reduces the volume of incidents a system has to handle downstream.
Why it cannot be a complete defense
None of these techniques change the fundamental fact that the model is still interpreting all of the text in its context using the same underlying process, regardless of how it is labeled or delimited. A sufficiently well-crafted injection can still exploit the model's interpretation, because the defense is itself expressed in the same medium, natural language, that the attack uses. There is no formal guarantee, the way there is with parameterized queries in SQL, that a given structural technique closes off every possible manipulation.
This means prompt engineering defenses degrade against more sophisticated or novel attacks, and they degrade unpredictably, since a phrasing that was not anticipated during testing may bypass a defense that worked reliably against every phrasing the team did test.
The asymmetry between attacker and defender effort
An attacker only needs one successful phrasing to cause an incident. A defender has to anticipate a very wide range of possible phrasings to have confidence their prompt engineering defenses hold broadly. This asymmetry means prompt engineering, however carefully done, tends to raise the bar for a casual or unsophisticated attacker while remaining vulnerable to a motivated one who is willing to iterate.
This is not a reason to skip prompt engineering. It is a reason not to treat it as sufficient on its own, given how the effort required to defeat it is much lower than the effort required to make it airtight.
Model updates can silently change how well it works
Prompt engineering defenses are often tuned and tested against a specific model version. When a model provider updates the underlying model, the same prompt structure may behave differently, sometimes better, sometimes worse, against the same injection attempts. This means prompt engineering defenses require ongoing re-testing whenever the underlying model changes, not a one-time validation that a team can consider permanently settled.
Where prompt engineering fits relative to other controls
Prompt engineering works best as a first layer that reduces the volume of successful injections reaching further into the system, paired with controls that limit the consequences of the injections it does not catch: narrow tool scopes, independent authorization checks, and output validation. This layered approach means a novel phrasing that defeats the prompt-level defense still runs into a second and third layer that does not depend on the model correctly resisting manipulation.
Relying on prompt engineering alone, without these downstream layers, means every future injection technique that defeats the current prompt structure has an unobstructed path to whatever the model is authorized to do.
A practical way to think about the investment
Spend real effort on prompt structure and explicit content labeling, because it is a relatively cheap improvement that measurably reduces incident volume. Do not spend disproportionate effort trying to perfect it to the point of treating it as a complete solution, since that effort has diminishing returns and distracts from building the enforcement layers that actually bound worst-case impact regardless of how the injection succeeded.
Where TELEON fits
TELEON operates downstream of whatever prompt engineering defenses are in place, enforcing policy at the tool-call boundary regardless of whether an injection attempt was caught by the prompt structure or slipped past it. This means a novel injection phrasing that defeats prompt-level defenses still has to pass an independent authorization check before it results in a real action, applied through the gateway or supported middleware.
A short checklist
- Use clear structural separation and explicit labeling between
instructions and untrusted content.
- Do not treat prompt engineering as a complete defense against
injection.
- Re-test prompt-level defenses whenever the underlying model version
changes.
- Pair prompt engineering with tool scoping, independent authorization,
and output validation.
- Measure prompt engineering's value by reduced incident volume, not by
an assumption of complete prevention.
Prompt engineering meaningfully reduces how often prompt injection succeeds against straightforward attempts. It does not remove the need for enforcement layers that limit what a successful injection can accomplish, because no amount of careful wording changes the fact that the model is still interpreting untrusted text using the same process an attacker is trying to exploit.