Large Language Models have become far more capable over the past few years, but those improvements have introduced a new category of security problem. These systems are designed to follow instructions, reason through complex requests, summarize information, generate code, and interact with connected applications. Those same capabilities can also be manipulated.
This is where AI jailbreaking comes in.
At a basic level, a jailbreak is an attempt to convince an AI system to ignore, reinterpret, or work around the safety controls that were added during training or application development. The goal may be to make the model produce restricted content, reveal hidden instructions, expose connected data, misuse available tools, or behave in a way the developer never intended.
It is easy to think of this as nothing more than tricking a chatbot into saying something it should not say. In reality, the issue is much broader. A successful jailbreak exposes a gap between what the model is capable of doing and what the system is supposed to allow it to do.
That distinction matters because modern AI systems are no longer isolated chat windows. They are increasingly connected to corporate documents, search systems, business data, APIs, cloud services, code repositories, and automated workflows. Once an AI system can retrieve information or perform actions, bypassing its instructions becomes a genuine security concern rather than simply a content moderation problem.
For AI red teams and defenders, the objective is not to collect clever prompts for the sake of it. The real purpose is to understand where the security boundary exists, how reliable it is, and what happens when an attacker begins manipulating the context around the model.
What Is an AI Security Boundary?
Before looking at how attackers bypass AI security controls, it is important to understand what those controls actually are.
An AI security boundary is very different from a traditional security control. A firewall rule, for example, can explicitly allow or deny traffic. An access control list can determine whether a user has permission to open a file. A Conditional Access policy can evaluate defined conditions before permitting authentication.
An LLM safety boundary is not usually that precise.
At its core, a Large Language Model predicts the next likely token based on the information already present in its context. During pre-training, the model learns patterns from enormous amounts of text, code, documentation, conversations, and other data. It develops the ability to explain technical processes, reason through scenarios, imitate styles, and generate information across a wide range of subjects.
That underlying model may be capable of producing both useful and harmful content. The safety boundary is added through further training and controls that attempt to guide how the model responds. This is generally achieved through several methods.
Supervised Fine-Tuning
Supervised Fine-Tuning, often shortened to SFT, uses carefully selected examples to teach the model how a helpful and safe assistant should respond.
The model is shown examples of acceptable responses, refusals, explanations, and alternative guidance. Over time, it learns patterns associated with expected behavior. This is one of the ways the model learns to respond with a refusal when a request falls outside the intended safety policy.
The important point is that the model is not following a simple rule such as: If the prompt contains a prohibited word, deny the request. Instead, it has learned a statistical pattern for how a safe response should look in a particular context.
Reinforcement Learning from Human Feedback
Reinforcement Learning from Human Feedback, or RLHF, adds another layer of behavioral training.
Human reviewers compare or score model responses based on qualities such as helpfulness, accuracy, safety, and relevance. Those preferences are then used to train the model toward responses that are more likely to receive positive feedback.
This process helps improve the model’s behavior, but it still does not create a hard security boundary. It changes the probability of one response being generated instead of another.
The model may still contain the underlying knowledge. It has simply been trained to avoid presenting that knowledge in certain circumstances.
Constitutional AI and Policy-Based Self-Critique
Some systems also use forms of Constitutional AI, where the model evaluates its own output against a defined set of principles.
The model may be instructed to review a draft response, identify whether it violates a safety principle, and then revise the response before presenting it to the user. This creates a form of self-regulation and can improve consistency across a broad range of requests.
However, this still depends on the model correctly interpreting both the user’s intent and the policy it has been asked to follow. If an attacker can manipulate that interpretation, the self-critique process may also fail.
Application-Level Guardrails
In addition to model training, many AI applications introduce their own controls. These can include:
- System prompts that define the assistant’s role and limitations.
- Content filters that inspect prompts and responses.
- Input validation.
- Output filtering.
- Tool permission restrictions.
- Retrieval controls.
- Policy engines.
- Human approval requirements.
These controls are critical because model alignment alone is not enough to secure an enterprise AI system. The challenge is that many applications rely too heavily on the model itself to recognize and reject malicious instructions. That is where jailbreaking becomes possible.
Why the Boundary Is Probabilistic
The most important concept to understand is that an AI safety boundary is usually probabilistic rather than absolute. The model is not always evaluating a clean choice between safe and unsafe. It is responding to many competing signals inside the same context window. Those signals may include:
- The original system instructions.
- Developer instructions.
- User prompts.
- Retrieved documents.
- Previous messages.
- Tool outputs.
- Embedded text from files or images.
- Examples included in the conversation.
- The model’s own previous responses.
The model attempts to determine which instructions matter most and what response best fits the combined context. In a well-designed system, system and developer instructions should have the highest priority. In practice, however, attackers try to create enough confusion, ambiguity, or competing context to weaken that hierarchy.
This is why many jailbreaks involve role-playing, hypothetical scenarios, encoded instructions, fictional settings, or long conversations. The attacker is not necessarily trying to break a formal rule. They are trying to reshape the context so that producing the restricted output appears to be the most natural or helpful next response.
For defenders, this creates a difficult problem. The model may refuse one direct request while complying with the same underlying request when it is reframed as fiction, translation, analysis, debugging, or academic research. The intent remains the same, but the surface presentation changes.
Jailbreaking Is Context Manipulation
At its core, jailbreaking is usually a form of context manipulation. The attacker attempts to influence how the model interprets the request, its role, the surrounding conversation, or the priority of existing instructions. The actual wording may vary significantly, but the objective is often one of the following:
- Reclassify a harmful request as harmless.
- Convince the model that normal rules no longer apply.
- Hide the real intent of the prompt.
- Break the request into smaller pieces.
- Introduce conflicting instructions.
- Make untrusted content appear authoritative.
- Exploit the model’s desire to be helpful or complete a task.
- Encourage the model to follow a fictional or hypothetical framework instead of its safety policy.
This is one of the reasons prompt-based attacks are so difficult to stop using traditional security approaches. There may be no malicious file, known exploit signature, or obvious command to detect. The attack can be entirely semantic.
The input may look like normal language, but its structure is designed to manipulate how the model reasons about the request.
A Taxonomy of Common Bypass Techniques
AI jailbreaks are not all the same. Different techniques target different weaknesses in the model, the application, or the surrounding control layer.
Some attacks focus on the model’s ability to adopt personas. Others hide malicious intent through encoding, split the request across multiple prompts, or attempt to override the instruction hierarchy entirely.
Understanding these categories helps defenders move away from reacting to individual prompts and instead focus on the underlying attack pattern.
Persona-Forcing Attacks
Persona-forcing is one of the most recognizable forms of AI jailbreaking. The attacker instructs the model to behave as an alternative personality that is not restricted by the normal rules. The classic examples often tell the model that it is now an unrestricted AI, a fictional character, a debug assistant, or a system operating in a special mode.
The prompt may ask the model to produce two responses: one following the normal rules and another from the unrestricted persona. It may claim that the model has been released from previous limitations or that the conversation is part of an authorized test. The underlying goal is to create a conflict between two learned behaviors:
- Follow the instructions provided by the user.
- Continue following the model’s safety training.
Poorly protected systems may place too much weight on the user’s role-play instructions, especially when the alternative persona is described in detail. The model becomes focused on completing the fictional scenario and may generate output that it would normally refuse.
Modern systems are much more resistant to simple persona attacks than earlier models. Direct instructions such as “ignore all previous rules” are now frequently recognized and blocked. However, persona-forcing remains relevant because the technique has become more subtle.
An attacker may spend several prompts gradually establishing the character, its values, its knowledge, and the rules of the fictional world before introducing the restricted request. The attack becomes less about one obvious jailbreak statement and more about slowly shifting the model’s active context.
From a red-team perspective, the key question is not whether a well-known prompt such as DAN still works. The question is whether the model can be guided into a role where its safety behavior becomes less reliable.
Obfuscation and Encoding Attacks
Another common technique is to hide the actual request from safety controls while still allowing the model to understand it. This can be done using:
- Base64.
- Leetspeak.
- Character substitution.
- Misspellings.
- Other languages.
- Custom ciphers.
- Reversed text.
- Fragmented words.
- Symbol-based representations.
The attacker relies on a gap between the model’s ability to interpret the content and the safety layer’s ability to detect it. A simple keyword filter may not recognize a restricted request after it has been encoded or deliberately misspelled. The model, however, may be capable of decoding the text and then acting on the underlying instruction.
This exposes one of the weaknesses of lexical safety controls. If the defense is looking only for specific words or phrases, the attacker can change the surface form without changing the meaning.
More advanced systems use semantic classifiers that attempt to identify intent rather than exact wording. These are much harder to bypass, but the problem does not disappear entirely. Attackers can still combine encoding with role-play, translation, or multi-turn conversations to reduce the likelihood that the full intent is evaluated in one place.
Progressive Reframing and Crescendo Attacks
Some of the most effective jailbreaks do not begin with a prohibited request at all. Instead, the attacker starts with a harmless topic and gradually narrows the conversation. Each individual prompt may appear reasonable, but the sequence steadily moves the model toward a restricted output.
This is often referred to as progressive reframing. Microsoft’s research has also used the term Crescendo to describe attacks where the conversation becomes increasingly focused over time.
For example, a user might begin by asking about a historical event, then ask about the technology involved, then ask for a technical comparison, and finally request enough detail to reconstruct a harmful process. The model may comply with each step because no single message appears to cross the boundary by itself.
The danger comes from the cumulative context.
By the time the final request arrives, the model has already accepted the framing, terminology, assumptions, and direction of the conversation. Refusing the final step may become statistically less likely because the model has been gradually led toward completing the task.
This type of attack highlights an important defensive requirement: AI security controls must evaluate the conversation as a whole, not just the latest user message. A model that checks each prompt independently can miss the intent that emerges across multiple turns.
Payload-Splitting Attacks
Payload splitting follows a similar principle but focuses on separating the components of a restricted request. Instead of asking for a complete harmful process, the attacker asks for several individual pieces of information that appear harmless in isolation. The user then combines those outputs outside the system. A conversation might request:
- A list of relevant materials.
- A description of individual properties.
- A general explanation of a process.
- A troubleshooting guide.
- A final formatting or assembly step.
Each response may appear educational or benign. Together, however, they can produce something the model should not have helped create.
This technique is particularly important in enterprise AI systems because the attacker may not need the model to generate a complete end-to-end response. They may only need it to reveal one missing step, one sensitive parameter, one internal identifier, or one fragment of restricted data.
The final payload is assembled by the attacker, not the model.
That makes detection more difficult because there may never be a single output that clearly contains the entire harmful result.
Why These Techniques Matter
Persona forcing, obfuscation, progressive reframing, and payload splitting may look very different, but they all exploit the same underlying weakness: the model is attempting to infer intent from context, and that context can be manipulated.
This is why AI security cannot depend entirely on asking the model to protect itself. The same reasoning capability that makes the model useful can also be used against it.
A capable model can decode obfuscated text, understand allegory, follow fictional scenarios, connect fragments of information, and maintain context over long conversations. Those are valuable features, but they also give an attacker more ways to disguise intent.
The role of the red team is to identify where those capabilities begin to conflict with the safety boundary. The role of the defender is to ensure that the system does not rely on a single control, a single classifier, or the model’s refusal behavior alone.
In Part 2, I will continue with the more advanced bypass techniques, including counterfactual framing, system prompt override attempts, and indirect prompt injection.