Jailbreaking and prompt injection get used interchangeably often enough that many teams treat them as the same problem with two names. They are related but distinct, and the difference matters for deciding what a given test result actually tells you about your system's risk.
What jailbreaking targets
Jailbreaking targets the model's own trained safety behavior, the general restrictions a model provider built in during training to prevent the model from producing certain categories of content regardless of the application built on top of it. A jailbreak attempt tries to get the model to bypass these restrictions, often through role-play framing, hypothetical scenarios, or step-by-step reasoning designed to lead the model toward a restricted output gradually rather than requesting it directly.
Jailbreaking is largely a model-level concern. The same jailbreak technique that works against a given model will tend to work similarly across different applications built on top of that model, because the target is the model's general training, not anything specific to how a particular application uses it.
What prompt injection targets
Prompt injection targets the specific application's intended task, trying to redirect the model away from what that application asked it to do, regardless of whether the redirected behavior would also violate the model's general safety training. An injection that convinces a customer support assistant to reveal another customer's data is not necessarily asking the model to produce content it was trained to refuse in general; it is asking it to violate the specific task boundary the application intended.
This means prompt injection is application-specific in a way jailbreaking often is not. The same underlying model might resist a jailbreak attempt consistently while remaining fully vulnerable to an injection attack that exploits a specific application's tool access or task framing, because the model's general safety training has nothing to say about "should this customer support bot look up a different customer's account."
Where the two overlap
Some attacks blend both categories: a jailbreak framing used specifically to get a model to bypass a task-specific restriction the application relies on, or an injected instruction that also happens to request content the model's general training would otherwise refuse. In practice, the techniques attackers use for each category, role-play framing, hypothetical scenarios, encoded requests, often look similar even when the target is different, which is part of why the two get conflated.
Why the distinction matters for testing
A model provider's own safety evaluations focus heavily on jailbreak resistance, because that is the risk most directly tied to the model itself and most visible to the provider across all its customers. This means a model can have genuinely strong jailbreak resistance while still being fully vulnerable to prompt injection attacks specific to your application's tools and task framing, because the provider's testing has no visibility into your specific integration.
Teams that assume a model provider's safety testing covers their own application's risk are making a category error: strong jailbreak resistance says very little about whether your specific tool authorization and task boundaries hold up against an injection attempt tailored to your system.
Why the distinction matters for defenses
Jailbreak resistance is mostly the model provider's responsibility to improve through training, though application teams can add some supplementary filtering or monitoring. Prompt injection resistance is substantially your own responsibility, because it depends on your specific tools, prompts, and task design, none of which the model provider has visibility into or control over. Relying on a model's improving jailbreak resistance to also solve your application's injection risk misunderstands which party is actually positioned to fix which problem.
Testing for both without conflating them
A thorough security test plan for an LLM application should include jailbreak attempts to understand the underlying model's general behavior boundaries, and separately, application-specific injection attempts crafted against your actual tools, task framing, and content sources. Reporting these as a single undifferentiated "prompt security" test result obscures which category of risk a given finding belongs to, and therefore who is actually positioned to fix it, the model provider through future training updates, or your own team through application-level design changes.
Where TELEON fits
TELEON's policy enforcement at the tool-call boundary is relevant primarily to the application-specific risk that prompt injection represents, since it checks whether a requested action is authorized regardless of what technique, jailbreak-adjacent or injection-specific, convinced the model to request it. It does not address general jailbreak resistance, which remains a model-level property outside what a runtime policy layer around tool calls can influence.
A short checklist
- Distinguish jailbreak testing, targeting the model's general safety
training, from injection testing, targeting your specific application.
- Do not assume strong jailbreak resistance implies resistance to
application-specific injection.
- Test injection against your own tools, task framing, and content
sources specifically.
- Report findings by category so the right team, provider or your own,
can act on them.
- Re-test jailbreak resistance after model version updates, since it can
shift without your application changing at all.
Jailbreaking and prompt injection target different things, and conflating them leads teams to assume a model provider's safety work covers risk that is actually specific to their own application's design.