De acordo com o preprint Beyond Max Tokens: Stealthy Resource Amplification via Tool Calling Chains in LLM Agents, de Kaiyu Zhou e colegas, um agente de IA pode concluir corretamente uma tarefa e ainda assim ser conduzido a desperdiçar uma quantidade enorme de processamento, energia e dinheiro. O ponto central do estudo é simples e perturbador. O ataque não tenta sabotar a resposta final. Ele explora o ciclo de comunicação entre o agente e as ferramentas conectadas via Model Context Protocol, o MCP, para alongar o caminho até a resposta e inflar o custo ao longo desse percurso.
Como se trata de um preprint, o trabalho ainda não passou por revisão por pares. Isso exige cautela. Ainda assim, o artigo merece atenção porque descreve uma superfície de ataque muito plausível no ecossistema atual de agentes com ferramentas. Nos últimos meses, o debate sobre risco em IA ficou muito concentrado em alucinação, jailbreak e prompt injection. O que este estudo mostra é que já existe outra classe de problema ganhando forma. Um atacante não precisa quebrar a tarefa. Em certos casos, basta torná-la artificialmente cara.
Essa mudança de foco é importante. Em um chatbot comum, o custo da interação costuma estar preso a um único turno de resposta. Em um agente, a lógica é diferente. O modelo pode consultar várias ferramentas, interpretar saídas intermediárias, decidir o próximo passo e repetir esse processo muitas vezes. O artigo argumenta que essa natureza multi-etapas criou uma oportunidade nova para ataques de negação de serviço, ou DoS, voltados não para derrubar a aplicação de forma barulhenta, mas para consumir recursos de maneira silenciosa e persistente.
O que o preprint está dizendo
A tese dos autores é que o ciclo agente-ferramenta virou uma superfície de ataque própria. Em vez de forçar uma resposta longa diretamente no prompt do usuário, o atacante manipula o servidor MCP que responde ao agente. A ferramenta continua aparentando ser legítima. Suas assinaturas de função continuam iguais. O payload final, isto é, a resposta útil da ferramenta, também permanece intacto. O desvio acontece no meio do caminho. O servidor passa a devolver mensagens intermediárias que sugerem progresso, pedem reformatação ou exigem uma sequência longa de saída antes de liberar o resultado final.
Em termos práticos, o ataque faz o agente acreditar que precisa seguir um procedimento mais longo para concluir a tarefa. Isso é crucial. O modelo não entra em colapso nem passa a responder absurdos. Pelo contrário. Ele continua tentando fazer exatamente o que deveria fazer. Só que passa a produzir muito mais texto em cada etapa e a chamar a mesma ferramenta repetidas vezes. O dano, portanto, é econômico e operacional. O sistema continua útil para o usuário, mas muito menos eficiente para quem paga a conta.
Os autores chamam isso de um ataque de negação de serviço econômica no nível da ferramenta. A expressão faz sentido. Em vez de mirar somente disponibilidade, o ataque mira custo de inferência, latência, consumo energético, pressão sobre memória de execução e queda de throughput. Em sistemas cobrados por token, isso pode virar gasto direto. Em sistemas locais, rodando dentro da empresa, isso pode significar menos tarefas processadas por segundo, mais contenção de GPU e menos espaço para workloads legítimos.
Por que o MCP entra no centro da história
O MCP foi criado para padronizar a forma como modelos se conectam a ferramentas e fontes externas. A promessa é boa. Um protocolo comum reduz improviso, facilita integração e ajuda a transformar ferramentas dispersas em componentes reutilizáveis. O problema é que padronizar também torna mais clara a interface entre agente e servidor. E toda interface estável tende a virar alvo de exploração.
O artigo não diz que o MCP é defeituoso por definição. O que ele mostra é que a própria camada de tool calling, ou chamada automática de ferramentas, merece ser tratada como parte da superfície de ataque. Isso é um ponto conceitual importante. Por muito tempo, segurança em LLMs foi discutida quase sempre na borda textual, isto é, no que o usuário digita ou no que entra pelo contexto recuperado. O preprint desloca a atenção para dentro do workflow agentic. Em vez de perguntar apenas o que entra no modelo, ele pergunta o que acontece quando o modelo começa a conversar com a infraestrutura ao redor.
Como o ataque funciona
A mecânica do ataque é engenhosa porque depende apenas de mudanças textuais. Os autores não alteram as assinaturas das funções nem o identificador da ferramenta. O servidor malicioso mantém a aparência de compatibilidade. O que muda são os campos visíveis em texto e a política de retorno. A ferramenta passa a introduzir uma noção artificial de progresso por segmentos, além de uma sequência de calibração que o agente precisa produzir de forma completa e ordenada.
Se essa sequência vem incompleta ou fora do formato esperado, o servidor responde com uma espécie de aviso de reparo e força uma nova tentativa. Se a sequência vem correta, mas ainda não chegou ao estágio terminal, o servidor devolve uma mensagem de progresso. Só no ponto final a resposta legítima é liberada. O efeito prático é simples. O agente aprende, durante a própria interação, que precisa continuar chamando a ferramenta e continuar gerando texto longo para avançar. Como a tarefa só termina no fim do roteiro, ele segue obedientemente.
Para tornar essa manipulação mais robusta, os autores usam Monte Carlo Tree Search, conhecido como MCTS, uma estratégia de busca que testa variações e mantém as que funcionam melhor. Em vez de escrever manualmente uma única mensagem maliciosa e esperar que ela generalize, o algoritmo faz pequenas edições locais no texto do servidor e mede quais delas geram mais custo sem derrubar a taxa de sucesso da tarefa. É um detalhe técnico importante porque mostra que o ataque não depende apenas de intuição artesanal. Ele pode ser otimizado.
O que foi testado
Os experimentos foram feitos em um simulador controlado, não em stacks de produção. Isso limita a extrapolação, mas torna os testes mais reprodutíveis e seguros. Os autores avaliaram seis modelos com suporte forte a ferramentas, entre eles Qwen-3-32B, Llama-3.3-70B-Instruct, Mistral Large e Seed-32B. Usaram também dois benchmarks conhecidos de tool use, ToolBench e BFCL, convertendo as ferramentas originais em servidores MCP compatíveis. No conjunto final, ficaram 105 servidores MCP e 261 consultas no ToolBench, além de 80 servidores e 203 consultas no BFCL.
O ataque foi comparado com três linhas de base. A primeira foi a execução benigna. A segunda foi Overthink, um método anterior que tenta inflar custo em um único turno. A terceira foi uma versão multi-turno desse mesmo ataque. Também houve um template manual sem a otimização por MCTS, para mostrar o quanto a busca automática realmente ajuda. Esse desenho experimental é bem construído porque não compara o método novo apenas com um cenário inocente. Ele o coloca lado a lado com tentativas anteriores de inflação de custo.
O que os números mostram
Os resultados são fortes. Em vários cenários, o ataque empurra a geração total para acima de 60 mil tokens por consulta. No BFCL com Seed-32B, o artigo reporta 90.298 tokens médios por consulta. No ToolBench com Llama-3.3-70B-Instruct, a média chega a 81.830 tokens. Isso não é um aumento marginal. É uma mudança de regime.
Mais importante ainda, a taxa de sucesso da tarefa permanece alta. No ToolBench com Llama-3.3-70B-Instruct, a taxa de sucesso do sistema benigno é de 98,1%. Sob ataque, a taxa continua em 96,2%. No BFCL, o mesmo modelo cai de 100,0% para 93,9%. Isso ajuda a explicar por que o ataque é perigoso. Se a tarefa falhasse de forma escancarada, seria mais fácil perceber o problema. O que o estudo sugere é o contrário. O usuário pode receber uma resposta correta enquanto a infraestrutura sofre.
Os fatores de amplificação também impressionam. Os autores destacam um caso de 658,10 vezes mais tokens em Mistral Large no BFCL. Em outro exemplo, Llama-3.3-70B-Instruct no ToolBench sobe de 260 tokens para 81.830. Essa combinação de correção preservada com inflação brutal de custo é o coração do paper. O sistema continua parecendo funcional. Só que seu funcionamento se torna economicamente hostil.
Não é só dinheiro, é infraestrutura
O artigo vai além da contagem de tokens e mede energia, uso de memória de contexto e throughput. Aqui o trabalho fica ainda mais interessante. Segundo os autores, o consumo de energia aumenta de cerca de 100 vezes até mais de 560 vezes, dependendo do modelo e do benchmark. Em um caso citado no texto, Llama-3.3-70B-Instruct no ToolBench sobe de 5,63 Wh para 3159,45 Wh. Em outro, Mistral Large no BFCL salta de 4,24 Wh para 2269,60 Wh.
Também cresce fortemente a ocupação do KV cache, o cache de chaves e valores que ajuda o modelo a manter o contexto ativo ao longo da geração. Em termos didáticos, é uma parte importante da memória de trabalho do sistema. No cenário benigno, a ocupação costuma ficar abaixo de 1%. Sob ataque, os autores observam faixas de 35% a 74%. Isso importa porque memória ocupada por tempo prolongado reduz a folga do servidor para atender outras demandas.
O efeito agregado aparece no throughput. Quando executam uma carga benigna em paralelo, os autores observam queda média de aproximadamente 50% na eficiência. Em alguns casos, a degradação passa de 60%. Isso dá ao trabalho um peso prático que muitos papers de segurança em LLM não conseguem alcançar. Ele não mostra apenas que algo pode dar errado em teoria. Ele mostra que um workflow aparentemente normal pode estrangular a capacidade de atendimento do sistema.
Por que as defesas falham
Talvez a parte mais desconfortável do preprint seja a avaliação das defesas. Os autores testam filtros de perplexidade, mecanismos de automonitoramento e guardrails, como Qwen-Guard-3 e Llama-Guard-3. O resultado é ruim para as defesas e ótimo para a tese do artigo. A detecção do ataque costuma ficar perto de zero e sempre abaixo de 3% nos monitores testados.
Esse fracasso tem uma explicação intuitiva. Os filtros tradicionais procuram conteúdo estranho, perigoso ou semântico demais. Aqui o ataque é protocolar e comportamental. As mensagens do servidor continuam parecendo parte de um procedimento legítimo. O modelo não acha que está fazendo algo suspeito. Os guardrails também tendem a olhar para algo como se estivessem avaliando segurança de conteúdo. Só que o problema não é toxicidade, nem jailbreak visível, nem instrução obviamente maliciosa. O problema é ineficiência induzida.
Os autores também testam limites rígidos de orçamento, como teto de tokens por sessão e limite de chamadas de ferramenta. Esses mecanismos ajudam a conter o dano máximo, mas não resolvem o problema de fundo. O ataque continua funcionando dentro do orçamento disponível e empurra o sistema para consumir o máximo permitido. Ou seja, o controle vira um acelerador com limite, não um detector confiável.
O que o artigo ainda não prova
O próprio preprint reconhece limitações importantes. Os experimentos usam um emulador controlado, com payloads estáticos e tarefas de ferramenta única. Isso facilita a medição, mas não captura toda a complexidade de agentes reais em produção, com múltiplas ferramentas, estados mais longos e infraestrutura heterogênea. Também não fica demonstrado que os mesmos níveis de amplificação apareceriam com a mesma força em todos os runtimes, políticas de orquestração e ambientes de hardware.
Mesmo assim, a limitação não enfraquece a tese principal. O artigo não precisa provar que todo agente com MCP já está vulnerável da mesma forma. Basta mostrar que a lógica de ataque é plausível, eficaz em ambiente controlado e mal detectada por defesas correntes. E isso ele mostra.
Por que vale a pena comentar esse preprint
Este é um daqueles trabalhos em que o valor está menos no alarmismo e mais na precisão do deslocamento conceitual. O artigo nos obriga a parar de pensar em segurança de LLM apenas como uma disputa em torno do prompt. Em agentes, custo e confiabilidade dependem do workflow inteiro. Se o protocolo que organiza a conversa entre modelo e ferramenta pode ser usado para induzir desperdício, então a segurança precisa olhar para comportamento, proveniência do servidor, padrões de trajetória e eficiência esperada, não apenas para o conteúdo final da resposta.
Em outras palavras, o paper sugere que a próxima grande classe de falhas em agentes não será necessariamente a resposta errada. Pode ser a resposta certa obtida pelo caminho errado, lento e caro demais. E, do ponto de vista de infraestrutura, isso já é dano suficiente.
