Multi-turn attacks: Crescendo and Skeleton Key

Not every attack happens in one shot. In multi-turn attacks the adversary builds on earlier replies, escalating step by step. The series’ sixth episode focuses on two techniques that Microsoft published in 2024 and that its red team uses often: Skeleton Key and Crescendo ^[1].

Skeleton Key

Microsoft’s June 2024 write-up describes Skeleton Key as a jailbreak that “works by using a multi-turn (or multiple step) strategy to cause a model to ignore its guardrails”. Once the guardrails are ignored, the model can no longer tell malicious requests from ordinary ones ^[2]. The episode’s description is that the user’s early message reframes the situation, as a safe educational context for which uncensored output is needed, and asks the model to update its behaviour accordingly. The system message is effectively overridden and later turns inherit that change ^[1]. The exact wording is deliberately not reproduced here.

Microsoft’s recommended mitigations are four layers: input filtering, a system message that explicitly resists attempts to undermine its rules, output filtering, and abuse monitoring that looks for recurring malicious behaviour without being influenced by it ^[2].

Crescendo

Russinovich, Salem and Eldan introduced Crescendo in April 2024. The central mechanism, in their words, is that it “begins with a general prompt or question about the task at hand and then gradually escalates the dialogue by referencing the model’s replies progressively”, leading to a successful jailbreak. They report it working across several widely used models, describe an automated variant, and note that it extends to multimodal models ^[3].

The series demonstrates the shape with a harmful topic that is refused when asked directly, and then answered after the conversation starts with a historical question, follows one detail of the reply, and narrows step by step. The key observation is that each message, taken alone, is not obviously harmful and the model has no reason to refuse; and that the model’s own earlier answers supply the material for the next question ^[1]. You can reproduce the shape safely with a canary objective, such as getting a planted token revealed, in your own test application.

Why a per-message check is not enough

• Each turn passes a filter that judges messages one at a time, yet the sequence is the attack.
• The context grows with every turn, and the model’s earlier replies become part of what it reads next.
• Refusals are usually tied to a surface form of the request, so a request approached from a tangent may not trigger one.

Testing multi-turn behaviour

1. Define a canary objective and a scorer, as in single-turn tests.
2. Run the direct request first, to confirm the baseline refusal.
3. Run an escalating conversation by hand, then through an automated multi-turn tool (lesson 12). Set a turn limit, and allow backtracking when the model refuses, as the series’ automation does.
4. Log the full conversation, not just the last reply, so you can see where the drift began.

Defending conversations

The defensive implication is to evaluate the conversation as a unit. Classify output as well as input, watch for abuse patterns over time, and test the defence the same way you test the attack, with whole conversations. Microsoft’s four layers above apply directly, and Lesson 10 adds spotlighting and others.