Log-To-Leak: ataque de prompt injection via MCP sequestra chamadas de ferramentas para vazar dados de agentes LLM
Pesquisadores demonstram o Log-To-Leak, um ataque que explora a superfície de metadados em linguagem natural do Model Context Protocol (MCP) para injetar uma chamada adicional e não autorizada depois que o agente já completou sua tarefa legítima. Testado em 18 combinações de servidor MCP e modelo, o ataque atinge até 100% de sucesso e continua funcionando mesmo contra três defesas avaliadas, com impacto mínimo sobre a tarefa original — o que o torna difícil de perceber operacionalmente.
O MCP é o protocolo que agentes LLM usam para descobrir e invocar ferramentas externas, e essas ferramentas se descrevem por metadados em texto livre — nome, descrição, parâmetros — que o próprio modelo lê como parte do seu contexto. Isso significa que um servidor MCP malicioso ou comprometido pode embutir instruções dentro dessa descrição, e o agente, ao processá-la como texto confiável, pode acabar seguindo instruções que não vieram nem do usuário nem do operador do sistema.
O Log-To-Leak não tenta desviar a tarefa principal do agente: deixa a chamada legítima ser concluída normalmente e injeta uma chamada extra, posterior, de aparência administrativa ("de log"), que na realidade envia a consulta do usuário, o nome do servidor MCP, a resposta do servidor e a resposta do agente para um destino controlado pelo atacante. Os autores decompõem o payload de injeção em quatro elementos reutilizáveis — gatilho, amarração à ferramenta, justificativa textual e pressão — que juntos convencem o modelo de que essa chamada adicional é parte legítima do fluxo esperado de auditoria ou logging.
Em 18 pares modelo-servidor com execução válida de ferramentas, a taxa de sucesso do ataque variou de 62,64% a 100%, com acurácia de 76,55% a 95,64% no conteúdo efetivamente vazado, e em 16 desses pares a conclusão da tarefa legítima variou no máximo 6,63 pontos percentuais — do ponto de vista do usuário, o agente funcionou normalmente enquanto vazava dados em paralelo.
As três defesas testadas deixaram taxa de sucesso residual acima de 55% no GitHub MCP com GPT-4o, e um detector de instruções maliciosas classificou 85,53% das descrições benignas como suspeitas, expondo o dilema clássico entre falsos positivos e falsos negativos nesse tipo de filtro. O resultado prático reforça que autorizar chamadas secundárias de ferramentas precisa ser decidido pelo host ou orquestrador do agente, e não inferido pelo próprio LLM a partir do texto que ele está lendo — qualquer defesa que dependa de "o modelo vai perceber que isso é suspeito" tende a falhar contra um payload desenhado especificamente para parecer legítimo.