A jailbreak is a prompt designed to get a model to do something its training says it should refuse. Not by breaking into anything — by arguing. Roleplay framings, hypothetical wrappers, invented authority, instructions split across turns so no single message looks alarming: the technique changes constantly, but the shape is always the same. Persuade the model that the rule does not apply here.
It is worth separating from prompt injection, which the two are often confused. In a jailbreak, the user is the adversary, deliberately working on a model they control. In prompt injection, the user is the victim and the attack is hidden in content the model reads. Different threat, different defence.
Why it matters at your desk. Mostly it tells you how much weight a safety claim can carry. A vendor saying their model "won't produce X" is describing a tendency, not a guarantee — published jailbreaks get patched, new ones appear, and the cycle continues. If you are a lawyer or clinician putting a model between you and a client, assume the refusal behaviour is a strong default rather than a hard boundary, and keep the controls that do not depend on the model's cooperation: scoped permissions, human review, audit logs.
The related risk is what a jailbreak exposes rather than what it generates. Coaxing out a system prompt reveals how a product is built, and incidents like the Fable 5 system-prompt leak and the Grok private-chat exposure are reminders that anything placed in a model's context is one clever prompt away from being read back.
What to watch for: treat "it refused when we tested it" as evidence about the median case, not the adversarial one.