Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#3,345 2 comentários 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 2 dias

@ashwingadhave já está trabalhando nisso.

Desde 20/10/2026.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
ai, security

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
4.6k
Forks
962
Merge médio
2d 15h
PRs com merge (30d)
398

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

  • Sem Dockerfile nem arquivo Docker Compose
  • Tem um modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de microsoft/PyRIT

Todas as issues de microsoft/PyRIT

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.