arXiv
Multi-turn jailbreaks point back to the messages that built them
Multi-turn safety failures can become easier to investigate when a guardrail identifies the earlier messages that helped create them, rather than only labeling the final conversation unsafe. The researchers tested a localizing model on 1,762 conversations and found that removing its top-ranked 15% of user tokens flipped 49.4% of adversarial classifications to benign. In a company help desk, an analyst could inspect a few enabling messages instead of an entire transcript if the method works on live human-written conversations and includes the agent’s replies.
A chatbot can refuse a dangerous request and still leave a safety team with a basic mystery: which part of the conversation pushed it there? In a long exchange, the warning may arrive only after harmless-looking setup, reframing, and small hints have accumulated. A keyword filter has the opposite problem. It can block a legitimate security lesson or research question simply because the words sound risky. In both cases, the system says what happened, not why.
From a warning to an explanation
Most language-model safety systems give a conversation a category, such as safe or unsafe. That is useful for deciding whether to block a reply. It is much less useful after a failure, when someone has to inspect the transcript and find the message that mattered.
A multi-turn jailbreak spreads its intent across several exchanges. A conversation might start with ordinary workplace-writing requests, then add urgency, impersonation, links, or requests to enter credentials. A final message can look dangerous even though the path toward it began much earlier.
The paper calls its alternative evidence attribution. Instead of only asking whether a conversation is unsafe, the system points to user turns and the specific pieces of text it considers responsible. It also uses a counterfactual test: remove the highlighted text and replay the conversation, then see whether the unsafe classification changes. That is a stronger check than merely deleting conspicuous words, although it is more expensive and models can still be fragile when text is removed.
Finding the messages that changed the path
The researchers tested the idea on 1,762 conversations: 549 adversarial conversations and 1,213 benign ones. The conversations averaged 28.2 turns, so this was not a test of one suspicious prompt in isolation.
Their model reads each turn with a frozen DeBERTa-v3-base encoder and then uses two layers that compare information across turns. The important idea is not the model’s name. It is that the model looks for evidence distributed through the conversation, rather than treating a risky word as the whole explanation.
On its held-out internal test split, it reported a detection F1 score of 0.988 and accuracy of 0.993. But the more revealing test removed the 15% of user tokens the model ranked highest. The adversarial score fell by 0.511 on average, and 49.4% of adversarial classifications changed to benign. In a separate benchmark of 100 records, three people marked the evidence, and one of the five highest-ranked turns contained a human-marked evidence-bearing turn in 84.5% of adversarial cases.
The comparison with keyword filtering matters for ordinary users. The new method reported false-positive rates of 0.7% on borderline-benign records and 0.5% on benign records containing high-risk vocabulary. A surface-risk baseline reported 37.3% and 94.7% on those same kinds of records. That suggests a filter based less on vocabulary could interrupt fewer legitimate technical conversations.
But the strongest causal evidence was rare. Only 11 records had strong counterfactual evidence and 30 had weak evidence—together, 2.3% of the dataset. The authors also say detection generalized less well on the human-authored MHJ multi-turn benchmark. They describe the system mainly as a localizer to use after a failure has already been detected, not as a general detector of real attacks. It attributes user turns only, even though the authors acknowledge that partial assistant compliance can help a later escalation.
What an investigation might look like
In a company help desk, a security analyst could open a flagged AI-agent transcript and see the few earlier user messages that turned a routine request into an unsafe tool workflow. Instead of reading dozens of exchanges or blocking an entire topic, the analyst could inspect those points and decide where a refusal, confirmation, or human review should go.
That picture depends on several conditions. The localizer must work on live, human-written conversations, and it must include the agent’s own responses. The authors say the approach still needs broader human-authored data and attribution of assistant responses before it can explain an end-to-end failure. Until then, its value is narrower but concrete: after a guardrail raises the alarm, it offers a way to look back at the messages that helped create the problem.