microsoft/PyRIT

Is your feature request related to a problem? Please describe. PyRIT now requires Python >=3.11 (currently <3.15), and Ruff targets py311. We can use Python 3.11 features consistently across supported versions, simplify older compatibility patterns, and improve typing, diagnostics, and async lifecycle management. Some features are already partially adopted; the opportunities below are investigations, not instructions to replace every existing pattern. Describe the solution you'd like How to participate: ONE opportunity at a time Claim exactly ONE checklist item at a time by commenting on this issue thread with its ID (for example, P311-01) and a short description of what you intend to investigate. Do not start multiple items or claim a bundle. Wait for confirmation here before treating the item as reserved. Claims are processed in comment order, and this issue is checked approximately every three hours. You must open a PR within five days (120 hours) of your claim comment. The confi

Is your feature request related to a problem? Please describe. Scenario progress exposes flat result rows, producer roles, parent-relative indexes, and stored child IDs. Generic attack APIs expose one attack's details and conversations, but do not resolve a Scenario's parent/child hierarchy in a bounded read. A client would otherwise have to reconstruct relationships and fetch children individually, with unclear behavior for missing legacy records. The producer-side failure-link prerequisite was fixed in #3048, which closed #3039. For example, an error envelope can retain a completed child's ID followed by the failed child's confirmed persisted ID. The read contract still needs to present those ordered edges, nested envelopes, and unresolved children without inventing lineage or equating a producer role with a physical target invocation. Describe the solution you'd like Add a consumed, typed, bounded Scenario result hierarchy projection using existing async memory reads, generic atta

Is your feature request related to a problem? Please describe. Current main records producer roles but does not use them for target-attempt rollups. The shared analytics helper, progress, and history SQL count attempts without a producer-role predicate. Thus their existing logical-unit/raw-history counts must not be presented as target-attempt counts. For example, two target-facing child results plus one Sequential envelope are three historical result rows, but only two target-facing producer attempts. The envelope can still complete one outer planned logical unit. A preparation error may also have a target-facing role, so this role alone does not prove a target request occurred. This check inspected code; it did not run an attack. Describe the solution you'd like Add a consumed typed target-facing accounting projection using the existing AttackResultMetadata contract and shared Scenario analytics/identity policy. Keep planned logical progress, raw historical attempts, and target-fac

Describe the bug garak.web_injection can use datasets that are not included in an explicit --dataset-names selection. As a result, the same command fails with empty memory but succeeds when load_default_datasets has already populated memory. For example, task_xss requires both garak_xss_normal_instructions and garak_web_html_js. Selecting normal instructions and example domains omits the HTML/JavaScript payload dataset. The scenario does not validate this missing dependency before reading all four web-injection source datasets directly from memory. The missing dataset in the command is a configuration error. The bug is that preloading datasets hides that error and changes the command's behavior, despite --dataset-names being documented as replacing the scenario defaults. Steps/Code to Reproduce Use a configured openai_chat target and a fresh backend with memory_db_type: in_memory. Do not include load_default_datasets in the backend configuration initially. Run: pyrit_scan run garak.w

Is your feature request related to a problem? Please describe. Scenario progress does not explicitly distinguish a result that represents orchestration from one that represents a target-facing attack. It also lacks the planned group's semantic kind. For example, a SequentialAttackResult has no target conversation of its own. Its child results own the conversations, and their ordered IDs already survive storage in the parent's metadata. Without an explicit role, progress consumers have to interpret names or result details themselves. That makes later hierarchy rendering and target-attempt accounting harder to keep consistent. Conceptually, an Adaptive execution can look like this: One planned execution unit SequentialAttack parent: orchestration child attempt 0: target-facing child attempt 1: target-facing Those child results must not silently turn one planned unit into two. A target-facing role also does not, by itself, prove that a request reached the objective target. Thi