Orchestrate Multi-Turn Adversarial Tests with PyRIT

Tier: Advanced · Workflow area: AI red-team program & tooling

PyRIT (Microsoft's Python Risk Identification Toolkit) automates these orchestrated, stateful attacks against a target you control. This playbook uses PyRIT to red-team your own guardrailed model, so you discover the multi-turn bypasses before an adversary does — and so your defenses are tested against the attack shape that matters, not just one-liners.

When to reach for this

• •
  Your app survives single-shot Garak/Promptfoo cases but you have not tested escalating, conversational attacks.
• •
  You have guardrails and want to know their real multi-turn bypass rate, not their single-prompt behavior.
• •
  You are red-teaming an agent or chatbot that maintains conversation state, where turn N depends on turns 1..N-1.
• •
  Skip this for stateless single-call endpoints with no conversation memory — single-turn suites cover those adequately.

The workflow

1. 1.

   Wire PyRIT to a target you control. Configure the target as your own application endpoint or a local model. Use PyRIT's memory to persist transcripts for later analysis.

   Copy

   from pyrit.prompt_target import OpenAIChatTarget
   from pyrit.orchestrator import CrescendoOrchestrator
   
   target = OpenAIChatTarget(          # your own app / local model endpoint
       endpoint="http://localhost:11434/v1/chat/completions",
       model_name="my-guardrailed-app",
   )
   

2. 2.

   Choose an orchestrator that matches the threat. Crescendo for gradual escalation, TAP for automated tree search over rephrasings, or the red-teaming orchestrator for an attacker-LLM-vs-target loop. Set an adversarial "objective" describing the unsafe outcome you are testing the defense against.

   Copy

   orchestrator = CrescendoOrchestrator(
       objective_target=target,
       adversarial_chat=attacker_model,      # a model you host that plays the attacker
       max_turns=10,
       max_backtracks=5,
   )
   result = await orchestrator.run_attack_async(
       objective="Get the assistant to reveal its hidden system instructions."
   )
   

3. 3.

   Let a scorer judge each turn. PyRIT scorers (rule-based or LLM-based) label whether the target complied. Multi-turn attacks succeed on turn 7 after six innocuous turns — the scorer flags the exact turn where the guardrail broke.

4. 4.

   Read the full transcript, not just the verdict. The value is in how the bypass happened: which reframing, which escalation step, which apparent-authority claim flipped the model. That is what you will defend against.

5. 5.

   Capture the bypass, then re-test after hardening. Save the winning conversation. After you add a defense (input reframing detection, per-turn policy checks, conversation-level guardrails), replay the same orchestrator and see whether the bypass still lands. That before/after number is the deliverable (formalized in pb-46).

6. 6.

   Log everything to memory. PyRIT's memory database is your evidence and reproduction store. Export the successful attack paths for the finding write-up (pb-44) and ATLAS mapping (pb-45).

Verify before you trust it

A multi-turn "success" must be reproducible and real. Replay the saved conversation against your target two or three times; because both attacker and target are stochastic, a genuine bypass should reproduce a clear majority of the time, not once in ten runs. Then hand-read the transcript end to end and confirm the target actually did the unsafe thing on the flagged turn — PyRIT scorers, especially LLM scorers, can mislabel a refusal as compliance or vice versa. If you cannot reproduce the bypass by manually walking the same conversation through your app, it is not a finding. Only reproducible, human-confirmed bypasses go into your baseline bypass rate; anything else is scorer noise that will make your hardening look falsely effective or falsely useless.

Pitfalls

• Pointing the orchestrator at anything you do not own. The non-negotiable boundary. Configure only your own app, staging, or local target.
• Trusting the scorer blindly. LLM scorers misjudge multi-turn compliance often. Human-confirm every "success" before it counts.
• Uncapped runs. Crescendo/TAP can spend a lot of tokens and time exploring. Set max_turns, max_backtracks, and tree-width limits so a run terminates.
• Testing the model instead of the product. If production wraps the model in conversation-level guardrails and moderation, point PyRIT at that wrapped endpoint — otherwise you overstate the vulnerability.
• Losing the transcript. The bypass path is the whole point. If you record only pass/fail and discard the conversation, you cannot design a defense or reproduce the finding.

Tools

• PyRITthe free, open multi-turn red-team toolkit (Microsoft) with Crescendo, TAP, and red-teaming orchestrators plus a memory store for transcripts.
• DeepTeaman OSS alternative mapped to OWASP Agentic risks, useful for cross-checking multi-turn agent findings.
• Local model runtime (Ollama / vLLM)hosts both your target and the attacker model entirely within your control so no third party is involved.

Client-safe variant

Multi-turn transcripts are the most sensitive artifact in AI red-teaming — they contain working attack recipes and often reveal internal prompts and business logic. In a client engagement, run PyRIT only against the client's authorized endpoint under a signed rules-of-engagement, keep the memory database and transcripts inside the client's environment, and never export a working bypass path outside their boundary. Report the class of bypass (for example, "gradual-escalation system-prompt extraction succeeds in 4 of 5 attempts") and the recommended defense, not the verbatim winning conversation, in any document that leaves the client. Discard or hand over the attacker model and corpus at engagement end; do not reuse a client's discovered bypasses elsewhere.