Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Proposal: DecayDeltaScorer — a turn-over-turn rate-of-change scorer for multi-turn attacks

Aperta
#2,619 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
ai, security

Direzione di ricerca

Inizia leggendo memory_interface.py, in particolare get_scores() e get_conversation_messages(), quindi confronta i pattern di wrapping di FloatScaleScorer, MessageFloatScaleScorer e FloatScaleThresholdScorer. Determina se i turni precedenti debbano essere valutati nuovamente oppure se si debbano recuperare gli score persistiti tramite gli ID dei frammenti di messaggio, e stabilisci il comportamento previsto per i delta dei turni consecutivi prima dell’implementazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Motivation

PyRIT has strong multi-turn attack orchestration (including Crescendo) and a ConversationScorer that evaluates conversation context by re-scoring the accumulated history. However, I haven't found a scorer that explicitly captures the rate of risk change between turns without repeatedly evaluating the full conversation.

I also searched the repository for related concepts such as delta, rate_of_change, turning_point, and decay across pyrit/score and pyrit/executor, but didn't find an existing equivalent. Happy to be pointed to an existing implementation if I've missed one.

Proposed approach

I'd like to propose a DecayDeltaScorer, implementing FloatScaleScorer / MessageFloatScaleScorer and following the wrapping pattern used by FloatScaleThresholdScorer.

Rather than thresholding the wrapped scorer's output, it would calculate the change in score between consecutive turns:

Δ(t) = S(t) − S(t−1)

where S(t) is the wrapped scorer's score for the current turn and S(t−1) is its score for the previous turn in the same conversation.

The goal is for this to be a deterministic, lightweight complement to ConversationScorer, rather than a replacement:

  • ConversationScorer: "How risky is the conversation at this point?"
  • DecayDeltaScorer: "How quickly is the risk changing?"

This could be particularly useful for gradual, multi-turn escalation such as Crescendo attacks, where individual turns may remain below a detection threshold while the overall trajectory is consistently increasing.

Implementation question

This is the main reason I'm opening an issue before submitting a PR.

I traced get_scores() in memory_interface.py. It supports filtering by score type/category/timestamp/scorer identifier, but I don't see a direct conversation-level filter for retrieving the wrapped scorer's previous score.

Two possible approaches I see are:

  1. Re-score previous turns retrieved through get_conversation_messages().
  2. Retrieve persisted scores using the message-piece IDs associated with the conversation.

I'd appreciate guidance on which approach better fits PyRIT's existing architecture and performance expectations before I proceed with an implementation.

Background

This proposal is motivated by my research into trajectory-level detection of gradual multi-turn attacks. In particular, I've observed cases where per-turn monitoring provides little or no pre-critical signal, while monitoring the trajectory reveals a consistent increase in risk.

I'm happy to share additional methodology or benchmark details if they would be useful for evaluating the proposed scoring approach.

If the approach fits PyRIT's scoring architecture, I'd be happy to follow up with a PR.

Lingua principale
Python
Stelle
4.5k
Fork
896
Merge medio
3g 8h
PR unite (30g)
191

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/PyRIT

Tutte le issue di microsoft/PyRIT

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.