Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

FEAT: OWASP LLM10 cost amplification scenario with a token usage scorer

Offen
  • Stimmt etwas nicht?
#3,345 2 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

@ashwingadhave arbeitet bereits daran.

Seit 20.10.2026.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
ai, security

Rechercherichtung

Start by reading the existing RedTeamingAttack scenarios, scorer implementations, and how OpenAI and LiteLLM targets store token usage in prompt_metadata. Then check how FloatScaleThresholdScorer handles objective results and how target responses expose length and turn counts. Done means a cost amplification scenario and scorer measure token use against a baseline, provide the described fallback estimate, and enforce the proposed run limits.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

There is no scenario for OWASP LLM10 (unbounded consumption) in PyRIT today, and no open issue or PR for it. OpenAI and LiteLLM targets already save token usage in prompt_metadata, but no scorer reads it.

This is a measured risk. Prompt-only attacks raise output tokens many times over (arXiv:2512.23779, arXiv:2607.25936), and DOW-BENCH (arXiv:2609.28585) shows the cost grows across turns in agents.

I would like to add a CostAmplification scenario built on RedTeamingAttack. The adversarial chat stays polite and on topic, but asks for exhaustive answers, keeps asking for clarification, or expands every reply. A new TokenAmplificationScorer compares total tokens with the baseline run for the same objective. It scales the ratio to 0 to 1 against a cap, and FloatScaleThresholdScorer turns that into the objective result. HTTPTarget and PlaywrightTarget do not save tokens, so the scorer falls back to response length and turn count and marks the score as an estimate.

A self-ask scorer cannot see token counts, so it can only guess.

I saw the concern about expensive runs in #2533. So the scenario would be off by default, stop at a hard token budget without changing target settings, and print the maximum spend before it runs.

Would this fit PyRIT? If yes, I will share an implementation plan first.

Vorherrschende Sprache
Python
Sterne
4.6k
Forks
962
Ø Merge
2 T. 13 Std.
Gemergte PRs (30 T.)
417

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus microsoft/PyRIT

Alle Issues in microsoft/PyRIT

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.