[Dev3 ^~^ (shashank03-dev)]

Fixes #3270

Adds an opt-in prefill technique built on PromptSendingAttack. The adapter sends the converted user objective followed by an exact assistant prefix; scoring independently determines attack success.

• Enables request support on Hugging Face, OpenAI Chat, OpenAI Responses, LiteLLM, and AzureML chat targets. Known-model profiles preserve the adapter default; custom configuration can disable it. HTTP, Playwright, and Completion targets stay disabled by default.
• Keeps explicit prefix selection in seed preparation. Execution recognizes the outgoing simulated assistant message without an extra AttackParameters argument, preserves its prefix, and requires native prefill, multi-turn, and editable-history support. Ordinary user requests after assistant history still get converted.
• Validates stored provider output according to its replayed wire format, including refusals and omitted reasoning through direct and RoundRobin targets. Current requests and unsupported history remain strictly validated.
• Preserves simulated memory roles, retry isolation, continuation scoring, and evaluation hashes. Updates both paired single-turn docs.

Tests: 34,686 passed, 28 skipped, 4 xfailed; 96.28% overall coverage; 98% changed-line coverage. Typing, pre-commit, and paired-doc checks pass. Public SQLite-backed regressions cover both request shapes and refusal/reasoning follow-ups; fake provider boundaries verify the exact objective/prefix order independently of the returned answer.

[Manohar Paturi (ManoharPaturi)]

This is a great implementation of the prefill attack. Requiring supports_prefill natively in TargetRequirements is the right design decision because attempting to adapt or fall back on targets that drop trailing assistant messages would disguise a target limitation as an attack refusal. Scoping request converters strictly to the prepended user objective preserves the exact prompt tokens intended for continuation, and tagging the prefill as a simulated assistant role keeps memory history truthful. The HuggingFaceChatTarget chat template continuation tests cover the mechanics nicely.

[Dev3 ^~^ (shashank03-dev)]

Manohar Paturi (@ManoharPaturi) Thank you :)

[Roman Lutz (romanlutz)]

Dev3 ^~^ (@shashank03-dev) Sorry, I missed an architectural point in my earlier reviews, especially after asking you to make fixes around the new attack class. I should have caught this before approving. On a closer look, I think prefill should be an attack technique built on PromptSendingAttack, rather than a separate PrefillAttack. I'd like us to make that change before merging.

The capability and target changes are still useful. The part I'd like to change is how we package the behavior. Prefill does not introduce a new conversation algorithm: it prepares a user objective followed by an assistant prefix, then uses the same sending, scoring, retry, and result-handling flow we already have. That is a better fit for the technique/executor split in framework.md.

Here is the direction I suggest:

1. Keep the target capability and native continuation support. Keep CapabilityName.PREFILL, the default-false supports_prefill field, and the Hugging Face chat-template change. The target should still use continue_final_message=True and avoid adding a new generation prompt for a trailing assistant message. Keep OpenAICompletionTarget unsupported unless its adapter can preserve the objective as well as the prefix.

2. Represent prefill as technique configuration. Register a technique using AttackTechniqueFactory(attack_class=PromptSendingAttack, ...), with the prefix supplied as technique-owned seed/configuration. Put the general-purpose technique in pyrit/setup/initializers/techniques/extra.py, rather than adding it to the small default core catalog. Declare native PREFILL, MULTI_TURN, and EDITABLE_HISTORY requirements through TechniqueRequirements and TargetRequirements. Unsupported targets should fail compatibility checks, not silently flatten or drop the prefix.

3. Add only the missing reusable preparation support. This is not quite a configuration-only replacement with today's code. PromptSendingAttack can send a supplied next_message, but SeedGroup.next_message only extracts a final user turn; an assistant-ending seed group is treated as history. Request converters also normally run on the outgoing message. Please use the existing seed/technique composition and add the smallest explicit, reusable opt-in needed for this shape:

   user:      <the current objective, after request conversion>
   assistant: <the exact configured prefix, left open for continuation>
   

   Do not globally reinterpret every assistant-ending seed group as an outgoing request. Other techniques use assistant-ending seeds as completed simulated history before the real request. The prefill behavior needs an explicit contract, while existing seed extraction and ordinary prompt-sending behavior retain their defaults. Technique code should configure preparation, not implement its own send/scoring/retry loop.

4. Preserve converter, memory, and scoring semantics. Request converters should act on the objective, not the prefix. Store the caller-written prefix as simulated_assistant, but send it with the assistant API role. Response converters and scorers should still operate on the generated continuation. Reuse the existing executor lifecycle, retry isolation, labels, and persistence. The technique identity must include the prefix so two different prefixes retain different evaluation hashes. Also declare which incoming seed-group shapes the technique accepts; do not silently discard dataset-provided prompts or history.

5. Replace the dedicated attack API and update the example. Once the shared path works, remove the new PrefillAttack/PrefillAttackParameters class and exports from this PR. Move the relevant coverage to the technique and shared preparation/execution paths. Update both paired single-turn documentation files to show the technique-based usage. There is no need to retain a compatibility wrapper for an API that this unmerged PR has not released.

6. Keep the original regression coverage and add boundary tests. Exercise the public technique/executor path with a recording target or fake provider. Check the exact user/assistant ordering, unchanged prefix tokens, objective-only request conversion, continuation scoring, simulated memory role, distinct persisted evaluation hashes, unsupported-target rejection, and retry isolation. Add controls showing ordinary user-ending requests and existing assistant-ending history still behave as before. Keep the QRCodeConverter/text-only-target rejection test.

There is also still an audio-history regression to address in the shared validation change. With OpenAIChatTarget(audio_response_config=OpenAIChatAudioConfig(voice="alloy")), the first text request can produce a transcript plus an audio_path response. The next text request now rejects that stored assistant audio as unsupported input, before the adapter can omit the audio and send its transcript. Please validate the content the adapter actually sends, or provide a narrow adapter-aware validation hook, without weakening the rejection of genuinely unsupported objective images. Add a two-turn public-send test with a fake SDK: first an audio response, then a text follow-up, and assert that the second payload carries the transcript rather than input_audio.

I realize this changes the direction after the earlier feedback, and I'm sorry for the extra work. The goal is to keep the useful prefill support while avoiding another attack subclass for behavior that can share our existing execution scaffolding. If there is a constraint in the technique path that I have missed, please point it out so we can address that shared gap explicitly.

[Dev3 ^~^ (shashank03-dev)]

Roman Lutz (@romanlutz) Thanks for the detailed guidance. Agreed — I’ll move prefill into a PromptSendingAttack technique, fix the audio-history regression, and add coverage for the edge cases. I’ll update the PR once verified.

[Dev3 ^~^ (shashank03-dev)]

Roman Lutz (@romanlutz) I’ve addressed your feedback and updated the PR. Could you pls review it when you get a chance? Thanks!

[Roman Lutz (romanlutz)]

The technique-based rewrite addresses the architectural feedback, but two regressions remain in the shared code.

[Dev3 ^~^ (shashank03-dev)]

Roman Lutz (@romanlutz) Fixed both: LiteLLM now allows the audio history its adapter omits, and continue_final_assistant_message is keyword-only so the old positional AttackParameters call works again. Added regression tests for each. Could you take another look when you get a chance?

[Roman Lutz (romanlutz)]

Dev3 ^~^ (@shashank03-dev) One more correction to my earlier guidance, sorry. I tried assistant-ending requests against live OpenAI Chat Completions (gpt-5.4) and Responses (gpt-4.1). Both APIs accepted them. The models did not produce the particular suffixes I expected, but that is not enough to conclude that the request is unsupported. We should not confuse capability support with the model doing what the attack wants.

Please adjust the capability policy in this PR:

1. Define supports_prefill as request support. It means the adapter can send the full conversation, including the objective and a caller-supplied trailing assistant prefix. It does not promise that the model will continue the prefix as intended or that the attack will succeed. Please update the field description and documentation to make that distinction clear.

2. Enable it by default on the chat adapters. Keep it enabled on HuggingFaceChatTarget, and enable it on OpenAIChatTarget, OpenAIResponseTarget, LiteLLMChatTarget, and AzureMLChatTarget. Keep the base TargetCapabilities default false, and allow an explicit custom configuration to disable it for a deployment that rejects this request shape.

3. Keep HTTP and Playwright off by default. This includes HTTPTarget, HTTPXAPITarget, PlaywrightTarget, and PlaywrightCopilotTarget. Their behavior depends on the particular integration, so they should not advertise this automatically. Also leave OpenAICompletionTarget disabled for this PR: its current adapter sends only the final message text and would lose the preceding objective. No completion-adapter rewrite is needed here.

4. RoundRobin should support it only when all sub-targets do. Its existing identical-configuration requirement can stay. Cover the all-enabled and all-disabled cases, and make sure a single supporting child cannot make the wrapper advertise support when another child does not.

5. Preserve the policy through configuration and test the actual boundary. Known-model profiles and LiteLLM's capability derivation must not accidentally reset the adapter's prefill default. Explicit custom opt-out must still win. Add coverage for those paths and for the disabled HTTP/Playwright/Completion defaults. Through the public technique/executor path with a fake SDK boundary, assert that both the user objective and exact assistant prefix reach the provider in order. A provider returning a complete answer rather than our desired suffix should not make that request-compatibility test fail; response quality and attack success belong to scoring. Keep the existing converter, memory, retry, and unsupported-image tests, and update both paired documentation files.

This supersedes the part of my earlier comment that treated hosted chat APIs as unsupported by default. The request-level policy should be consistent across these adapters rather than tied to whether a particular probe gets the answer we hoped for.

[Dev3 ^~^ (shashank03-dev)]

Roman Lutz (@romanlutz) Updated the prefill request-support policy as requested, added provider-boundary coverage, and updated both docs. Also resolved the merge conflicts with current main. 31,921 tests pass locally. Could you pls review and approve the CI runs when you get a chance? Thanks!

[Copilot]

🟡 Changes recommended

The all-turn modality validation rejects historical error, refusal, and reasoning pieces that adapters serialize or omit, breaking otherwise valid follow-up requests.

1 open issue

• Allow adapter-supported history in modality validation · New

What changed in this PR

Adds an opt-in prefill technique to PyRIT’s existing PromptSendingAttack workflow, carrying an assistant prefix through seed preparation, execution, and target adapters.

Changes:

• Adds prefill capability declarations and native Hugging Face assistant continuation.
• Preserves prefix handling, converters, scoring, retries, and distinct evaluation identifiers.
• Adds regression coverage and paired documentation examples.

File	Description
tests/​unit/​setup/​test_technique_initializer.py	Includes prefill in expected registrations.
tests/​unit/​setup/​techniques/​test_prefill_technique.py	Tests prefill execution and adapter payloads.
tests/​unit/​prompt_target/​test_round_robin_target.py	Tests matching child prefill capabilities.
tests/​unit/​prompt_target/​test_discover_target_capabilities.py	Tests preservation during capability discovery.
tests/​unit/​prompt_target/​target/​test_target_capabilities.py	Tests defaults, serialization, and overrides.
tests/​unit/​prompt_target/​target/​test_openai_chat_target.py	Adds audio-history regression coverage.
tests/​unit/​prompt_target/​target/​test_litellm_chat_target.py	Tests capability derivation and audio history.
tests/​unit/​prompt_target/​target/​test_huggingface_chat_target.py	Tests assistant-continuation template options.
tests/​unit/​executor/​attack/​single_turn/​test_prompt_sending.py	Checks positional-parameter compatibility.
tests/​unit/​executor/​attack/​core/​test_attack_parameters.py	Tests keyword-only field preservation.
pyrit/​setup/​initializers/​techniques/​extra.py	Registers the opt-in prefill technique.
pyrit/​scenario/​core/​attack_technique.py	Includes continuation mode in identifiers.
pyrit/​scenario/​core/​attack_technique_factory.py	Includes continuation mode in factory identifiers.
pyrit/​prompt_target/​openai/​openai_response_target.py	Enables prefill request capability by default.
pyrit/​prompt_target/​openai/​openai_chat_target.py	Enables prefill and exempts omitted audio history.
pyrit/​prompt_target/​litellm_chat_target.py	Preserves prefill defaults and handles omitted audio.
pyrit/​prompt_target/​hugging_face/​hugging_face_chat_target.py	Continues trailing assistant turns.
pyrit/​prompt_target/​common/​prompt_target.py	Validates history modalities and preserves prefill defaults.
pyrit/​prompt_target/​common/​discover_target_capabilities.py	Preserves declared prefill support during discovery.
pyrit/​prompt_target/​azure_ml_chat_target.py	Enables prefill request capability by default.
pyrit/​models/​target/​target_capabilities.py	Defines the prefill capability.
pyrit/​models/​seeds/​seed_group.py	Adds optional assistant-prefix extraction.
pyrit/​models/​seeds/​attack_technique_seed_group.py	Validates continuation seed configuration.
pyrit/​models/​seeds/​attack_seed_group.py	Combines objectives with assistant prefixes.
pyrit/​executor/​attack/​single_turn/​prompt_sending.py	Keeps request converters off the prefix.
pyrit/​executor/​attack/​core/​attack_parameters.py	Propagates continuation mode without shifting positional arguments.
frontend/​src/​types/​index.ts	Adds the optional prefill capability field.
doc/​references.bib	Adds two research references.
doc/​code/​executor/​1_single_turn.py	Documents prefill configuration and usage.
doc/​code/​executor/​1_single_turn.ipynb	Adds the paired notebook example and output.
doc/​bibliography.md	Includes the new citation keys.

_{Review effort: Balanced}

[Roman Lutz (romanlutz)]

Dev3 ^~^ (@shashank03-dev) Could we remove continue_final_assistant_message from AttackParameters and derive the execution behavior from the outgoing message instead? Sorry I did not call this out earlier. Making the field keyword-only fixed the compatibility issue I reported, but I think we can avoid adding the argument to the shared attack API altogether.

Once preparation has selected a simulated_assistant message as next_message, the intent is already represented: this is a caller-written assistant prefix being sent for generation. The additional boolean duplicates that information and allows inconsistent combinations, such as a user message with continuation enabled or an assistant prefix with it disabled.

Please keep the distinction between the outgoing message and stored history:

Normal request:  [prepended history, possibly ending in simulated_assistant]
                + next_message(role=user)

Prefill:         [user objective]
                + next_message(role=simulated_assistant)

In the first case, the simulated assistant message is a completed historical reply, not an open prefix. We should not globally treat every assistant-ending history as prefill.

Suggested scope:

1. Keep the explicit selection/preparation contract where needed to choose the final assistant seed as the outgoing message. The existing technique/seed opt-in can remain there; this suggestion is specifically about removing its duplicate from AttackParameters.
2. Stop copying that flag into the constructed attack parameters. In PromptSendingAttack, use the actual outgoing message's role and simulated status to recognize a prefix, preserve it without request conversion, and retain the appropriate target capability validation. Keep objective conversion on the prepared user-history path.
3. Preserve ordinary user-request conversion, completed assistant-history replay, continuation scoring, retry isolation, and simulated memory roles. Do not infer this from the final stored history role alone.
4. Update tests to exercise both shapes above without the extra attack argument. Check that the exact assistant prefix reaches the provider unchanged, the objective still gets its converters, an unsupported target is rejected, and an ordinary request following simulated assistant history still sends the new user message. Keep the existing positional-constructor compatibility coverage.

This would keep the generic attack parameters smaller and make the execution behavior follow the message we are actually sending. If there is a case where the outgoing message does not provide enough information, please point it out so we can account for that without spreading a second representation of the same state through the attack API.

[Dev3 ^~^ (shashank03-dev)]

Roman Lutz (@romanlutz) I removed the duplicate flag from AttackParameters and kept the seed opt-in. Execution now uses the outgoing simulated assistant message; tests cover prefix preservation, objective conversion, ordinary history, and unsupported targets.