"Denial-of-wallet": pesquisa demonstra ataque que faz uma ferramenta maliciosa multiplicar por até 14 mil vezes o custo de uma sessão de agente de IA
Pesquisadores identificam e formalizam uma nova classe de ataque — "estado billable persistente" — em que uma ferramenta admitida (maliciosa ou comprometida) em um agente LLM com chamadas de ferramenta consegue transformar dados não confiáveis em processamento recorrente cobrado da vítima, sem precisar de credenciais ou privilégio no runtime local. Em 243 execuções de teste contra seis famílias de modelos, o consumo cumulativo de entrada por sessão chegou a 14.293 vezes o tamanho da primeira chamada, e uma varredura de 3.830 repositórios de servidores e transporte MCP encontrou proteção code-visible contra esse vetor em apenas 71 deles, nenhum cobrindo todas as quatro famílias de salvaguarda propostas.
Agentes LLM que chamam ferramentas em múltiplos passos dependem do runtime que os hospeda para preservar estado entre turnos — o retorno de uma chamada de ferramenta anterior costuma ser recarregado no contexto de chamadas seguintes. O problema, batizado de "persistent billable state", é que provedores de LLM cobram (metering) por token de entrada toda vez que esse conteúdo retido reentra no contexto, e nada impede que uma ferramenta comprometida ou maliciosa, uma vez admitida no fluxo, injete conteúdo desenhado para inflar esse contexto retido repetidamente — convertendo dado não confiável em custo recorrente debitado da conta da vítima, sem exigir credenciais roubadas nem privilégio de execução local.
Os autores derivam seis vetores de ataque de negação de carteira (denial-of-wallet) a partir dessa fronteira e constroem o DOW-BENCH, um harness ponta a ponta avaliado contra seis famílias de modelo. Os números são expressivos: em 243 execuções, o pico de entrada cumulativa por sessão chegou a 14.293 vezes o tamanho da primeira chamada da sessão, e comparações controladas isolam a contribuição específica da retenção bruta de histórico — mantê-lo sem tratamento aumenta o custo efetivo médio da sessão entre 21% e 36%. Estratégias de compressão do histórico funcionam bem (sucesso em 10 de 12 e 11 de 12 tarefas dependentes de histórico), enquanto simplesmente deletar o histórico falha na maioria dos casos, porque quebra a continuidade de que o agente precisa.
A parte mais preocupante para quem opera esses sistemas hoje é a varredura de exposição real: dos 3.830 repositórios de servidores e camadas de transporte MCP (Model Context Protocol) analisados, apenas 71 expunham qualquer proxy de salvaguarda visível no código contra esse vetor, e nenhum cobria as quatro famílias de invariantes propostas pelos autores (limite de massa de prompt, limite de crescimento de contexto, limite de oportunidade recursiva e limite de gasto cumulativo antes de reingestão). Ou seja: a defesa proposta neste artigo é, até onde os próprios autores conseguiram verificar, praticamente inexistente no ecossistema MCP em produção.
O impacto prático é direto e mensurável em dinheiro: qualquer aplicação que exponha um agente de chamada de ferramentas a uma fonte de dados não totalmente confiável (uma página web, um resultado de busca, um servidor MCP de terceiros) está potencialmente exposta a ter sua fatura de API inflada de forma agressiva por um terceiro malicioso, sem que isso exija comprometer credenciais ou a infraestrutura do host — uma classe de risco financeiro que a maioria dos deployments atuais de agentes não trata como superfície de segurança.