Single-turn techniques and the science behind them

A single-turn attack is one input with no conversation and no follow-up: one prompt designed to make the model misbehave. In the series’ fifth episode these are described as the simplest attack structure, and they are also what an indirect injection usually delivers, because a poisoned document is one message ^[1]. This lesson names the families and, more importantly, explains why they work. It deliberately gives no ready-made prompts.

The families

The episode’s guidance on method matters as much as the list. Testers probe by hand, change wording and tone, and pay attention to where resistance comes from: is it something deeply learned during training, or a surface filter added later? That is how they map a model’s true boundaries ^[1]. The series’ lab makes this concrete with an automatic scorer: a protected file’s contents act as the canary, and the score tells the tester when a technique has worked.

Why they work: two published explanations

Wei and colleagues propose that safety training fails in two ways: competing objectives, and mismatched generalisation ^[2]. The families map onto them.

• Persona, emotional, narrative and priming techniques set the model’s objectives against each other. The model is rewarded both for helping and for refusing, and the framing tips the balance toward helping.
• Encoding, obfuscation and unusual languages move the request to a form that safety training rarely covered, while the model’s capabilities still understand it. This is mismatched generalisation.

Three research results worth knowing

Low-resource languages. Yong, Menghini and Bach translated unsafe English inputs into languages that are poorly represented in training data and reported that this bypassed GPT-4’s safeguards, which they attribute to linguistic inequality in safety training data. Because translation tools are widely available, they conclude the weakness “now poses a risk to all LLMs users” ^[3]. Translation is therefore one of the transformations that scanners automate.

Optimised suffixes. Zou and colleagues showed that adversarial suffixes can be produced automatically, by a combination of greedy and gradient-based search, and that such prompts are “quite transferable, including to black-box, publicly released LLMs” ^[4]. The lesson for defenders is that attack text need not look like language to a person.

Many-shot jailbreaking. Anthropic described, in April 2024, an attack built on long context windows: a single prompt that contains a faux dialogue between a person and an assistant, repeated many times, before the real question. The more such dialogues, they report, the more likely the model is to leave its safety training. Their tested mitigations were classifying and modifying the prompt before it reaches the model, which helped substantially in one case, and fine-tuning to refuse, which only delayed the attack ^[5].

What this means for testing

1. Test families, not single prompts. A defence that stops one phrasing may miss a rewording or an encoding, so scanners generate many variants of one idea (lesson 11).
2. Use a canary objective that your test application can score automatically, such as the appearance of a planted token.
3. Record which family worked and where the resistance came from: a model-level refusal, or an application-level filter.
4. Keep successful payloads inside the team. Share findings as results, with enough detail to fix and no copyable recipe.