FEAT: Split-payload multi-turn attack strategy

[ek0212]

Summary

Adds a split-payload multi-turn attack strategy to PyRIT. Split-payload attacks distribute a harmful request across multiple conversation turns where each individual turn passes all safety classifiers independently, but the assembled sequence constitutes a harmful instruction.

This is different from Crescendo (which escalates) - split-payload fragments a single harmful request across innocuous turns. The test: could you write a single harmful prompt that contains the same information as the full conversation? If yes, it's a split payload.

Changes

New attack strategy

• \SplitPayloadAttack\ extending \MultiTurnAttackStrategy\ with three-phase execution:
  1. Decomposition: adversarial LLM decomposes objective into innocuous turns
  2. Execution: sends turns sequentially, verifying each passes per-turn safety
  3. Assembly audit: scores assembled conversation against original objective

Seed datasets

• 60 split-payload attack conversations across 10 categories
• 60 topic-matched benign hard negatives using vocabulary overlap

Design patterns

Four fragmentation patterns: component assembly, parameter specification, referential chains, context+technique split

Demo notebook

Shows configuring and running the attack against a target

Closes #1734

Testing

• Unit tests needed
• Integration test with mock target needed

[ek0212]

@microsoft-github-policy-service agree

[rlundeen2]

Thanks for this; it's very cool! I worked with copilot to help me comment below:

The underlying idea (fragment a harmful objective into individually-innocuous turns, then assemble) is a good idea and a technique worth having in PyRIT. The thing I'd push on is whether it needs to be a standalone attack class, because I think the framework already expresses both flavors of it without new orchestration.

There are really two variants of this idea:

1. Upfront / pre-planned split (my recommended default). This is exactly what generate_simulated_conversation_async is for: run the adversarial chat to build the decomposed, individually-innocuous Q&A offline, return it as prepended_conversation, and then send a single assembly turn as next_message to the real target. Your split_payload_decompose.yaml drops straight in as the adversarial_chat_system_prompt_path, and the assembly turn becomes a next_message_system_prompt_path. See doc/code/datasets/5_simulated_conversation.py. It's the same pattern already used for "simulated crescendo." This is cheap (one real target turn) and matches the "plan all turns up front" design you have today.

2. Adaptive split. If instead you want each innocuous sub-question chosen from the target's actual previous answer (and regenerated when the target refuses), that's just Crescendo with a different adversarial system prompt. Crescendo already does real-target per-turn sending, refusal-driven backtracking (max_backtracks ≈ your max_regenerations), and objective scoring. Note crescendo_variant_1.yaml literally instructs "begin with innocuous questions," and its own few-shot examples decompose-then-assemble (Example 4 ends with "Combine them into a single text"). So this would be a crescendo_split_payload.yaml alongside the existing variant/themed YAMLs — no code.

Mapping your class onto what already exists:

decomposition by design pattern → system-prompt content (a YAML, reusable in either path)
assembly turn → a prompt line / the next_message
regenerate-on-refusal → Crescendo max_backtracks
all_turns_passed_safety / assembled_payload_harmful → derivable from backtrack_count == 0 and the objective score
The one genuinely distinct piece is the per-turn safety audit — asserting each individual turn would pass a content classifier in isolation, separate from whether the target refused. That's a nice signal, but I'd express it as an auxiliary per-turn scorer (e.g. AzureContentFilterScorer) attached to the simulated/Crescendo run, rather than a new attack class.

So my suggestion: I'd start by doing a simualted conversation attack using almost the same prompt. I'd add it to a component initializer (maybe scenario_techniques.py). Or an adapted crsecendo version and add it to the same spot.

[ek0212]

Thanks for this; it's very cool! I worked with copilot to help me comment below:

The underlying idea (fragment a harmful objective into individually-innocuous turns, then assemble) is a good idea and a technique worth having in PyRIT. The thing I'd push on is whether it needs to be a standalone attack class, because I think the framework already expresses both flavors of it without new orchestration.

There are really two variants of this idea:

1. Upfront / pre-planned split (my recommended default). This is exactly what generate_simulated_conversation_async is for: run the adversarial chat to build the decomposed, individually-innocuous Q&A offline, return it as prepended_conversation, and then send a single assembly turn as next_message to the real target. Your split_payload_decompose.yaml drops straight in as the adversarial_chat_system_prompt_path, and the assembly turn becomes a next_message_system_prompt_path. See doc/code/datasets/5_simulated_conversation.py. It's the same pattern already used for "simulated crescendo." This is cheap (one real target turn) and matches the "plan all turns up front" design you have today.
2. Adaptive split. If instead you want each innocuous sub-question chosen from the target's actual previous answer (and regenerated when the target refuses), that's just Crescendo with a different adversarial system prompt. Crescendo already does real-target per-turn sending, refusal-driven backtracking (max_backtracks ≈ your max_regenerations), and objective scoring. Note crescendo_variant_1.yaml literally instructs "begin with innocuous questions," and its own few-shot examples decompose-then-assemble (Example 4 ends with "Combine them into a single text"). So this would be a crescendo_split_payload.yaml alongside the existing variant/themed YAMLs — no code.

Mapping your class onto what already exists:

decomposition by design pattern → system-prompt content (a YAML, reusable in either path) assembly turn → a prompt line / the next_message regenerate-on-refusal → Crescendo max_backtracks all_turns_passed_safety / assembled_payload_harmful → derivable from backtrack_count == 0 and the objective score The one genuinely distinct piece is the per-turn safety audit — asserting each individual turn would pass a content classifier in isolation, separate from whether the target refused. That's a nice signal, but I'd express it as an auxiliary per-turn scorer (e.g. AzureContentFilterScorer) attached to the simulated/Crescendo run, rather than a new attack class.

So my suggestion: I'd start by doing a simualted conversation attack using almost the same prompt. I'd add it to a component initializer (maybe scenario_techniques.py). Or an adapted crsecendo version and add it to the same spot.

Thanks, agreed. I refactored the PR to remove the standalone attack class and reuse CrescendoAttack, which keeps the adaptive behavior: we still test whether the target can be guided through the split sequence live.

The PR now adds pyrit/datasets/executors/crescendo/split_payload.yaml and registers it as the opt-in split_payload technique. Selecting it runs CrescendoAttack with that YAML as the adversarial system prompt, so Crescendo still owns the adaptive turns, refusal backtracking, and scoring.

The prompt is narrower than default Crescendo: instead of general escalation from innocuous questions, it tells the adversarial model to split the objective into standalone benign-looking pieces, ask one per turn, build on prior answers, and only assemble near the final turns.