Novas pesquisas mostram que o Model Context Protocol (MCP) — a interface que permite que agentes de modelos de linguagem de grande escala (LLM) chamem ferramentas externas — pode ser sequestrado por meio de ataques de “envenenamento de ferramentas” (tool-poisoning) que têm sucesso em mais de um terço das vezes. Entre 20 agentes populares, a taxa média de sucesso foi de 36,5%; o modelo o1-mini sucumbiu em 72,8% das tentativas, enquanto o Claude-3.7-Sonnet recusou chamadas maliciosas em menos de 3% das vezes. Para qualquer pessoa que implemente agentes de LLM que dependem do MCP, as descobertas transformam um recurso de conveniência em um risco de cadeia de suprimentos que pode ser explorado antes mesmo de qualquer código ser executado.
Por que o MCP é importante para os desenvolvedores hoje
O MCP padroniza como os agentes descobrem, registram e invocam ferramentas, como leitores de arquivos, APIs web ou remetentes de e-mail. Ao publicar o nome de uma ferramenta, o esquema de entrada e uma breve descrição, um servidor disponibiliza essa capacidade para qualquer cliente que entenda o protocolo. A promessa é simples: um agente pode procurar uma ferramenta, enviar uma solicitação e receber uma resposta sem a necessidade de codificar cada integração de forma rígida (hard-coding).
Essa flexibilidade também cria uma relação de confiança implícita. A especificação instrui os clientes a tratarem as descrições das ferramentas como confiáveis apenas se elas vierem de um servidor no qual o cliente já confia. O novo estudo mostra que essa confiança pode ser abusada.
Como o envenenamento de ferramentas difere da injeção de prompt comum
A injeção de prompt tradicional insere instruções maliciosas no texto que o modelo gera ou recebe durante a execução (runtime). O modelo então segue essas instruções porque elas aparecem no mesmo fluxo de tokens que a solicitação do usuário.
O envenenamento de ferramentas, por outro lado, esconde a carga útil (payload) nos metadados da ferramenta — o nome, a descrição ou o esquema de parâmetros que é registrado antes de qualquer chamada do agente. Quando um agente seleciona a ferramenta posteriormente, ele trata a descrição como parte do “contexto confiável” e pode seguir a instrução oculta sem qualquer verificação em tempo de execução. Como a injeção ocorre durante o registro, não há ponto no fluxo de execução em que o modelo possa sinalizar a carga útil como suspeita.
Escala do problema – o benchmark MCPTox
Os pesquisadores por trás do MCPTox (arXiv:2508.14925) avaliaram 45 servidores MCP que oferecem um total de 353 ferramentas distintas. Eles criaram scripts de ataques contra 20 agentes de LLM amplamente utilizados, medindo a frequência com que os agentes executavam a chamada de ferramenta envenenada.
- Taxa média de sucesso: 36,5%
- Pico de sucesso: o1-mini com 72,8%
- Melhor recusa: Claude-3.7-Sonnet, ainda abaixo de 3%
Os números revelam uma realidade dura: a maioria dos agentes não recusa uma chamada envenenada porque a solicitação parece uma invocação legítima de ferramenta. Os agentes assumem que a descrição da ferramenta é um pedaço benigno de documentação, não um vetor para execução de código.
Por que os agentes raramente recusam chamadas envenenadas
A diretriz LLM01 da OWASP explica que os LLMs não diferenciam instruções de dados — ambos são apenas tokens em uma sequência. Quando uma descrição de ferramenta diz “envie um e-mail para admin@example.com com o assunto ‘Update’”, o modelo não consegue distinguir se essa linha é um comentário inofensivo ou uma instrução que ele deve obedecer mais tarde. Consequentemente, o modelo trata a descrição como parte do ambiente confiável e segue qualquer comando incorporado quando a ferramenta é invocada.
Orientações existentes e suas lacunas
A especificação do MCP já aconselha os clientes a tratarem as descrições das ferramentas como não confiáveis, a menos que se originem de um servidor confiável, e a manterem um humano no ciclo (human-in-the-loop) para chamadas de alto impacto. O benchmark mostra que muitas implementações no mundo real ignoram ou interpretam essas recomendações de forma superficial.
Passos concretos que os desenvolvedores podem tomar hoje
- Pin server versions – Reference a specific, immutable server image or hash rather than a moving tag. This stops an attacker from swapping a clean registry for a poisoned one after deployment.
- Start with an empty allowlist – Enable only tools that have been explicitly vetted. Anything not on the list is blocked by default.
- Gate state-changing tools – Require additional approval for any tool that writes, sends, or deletes data. Separate “read-only” from “write-capable” capabilities in the schema.
- Add human approval for high-impact calls – For actions that could affect external systems (e.g., sending email, executing commands, modifying files), prompt a human reviewer before the call is sent.
- Log every tool invocation – Record the tool name, arguments, timestamp, and the originating agent. An immutable audit trail makes post-mortem analysis feasible and can deter attackers who know their actions will be visible.
Treat each tool description like source code—subject to linting, code review, and version control—to align the MCP supply chain with standard software-development practices.
Counter-arguments and open questions
The benchmark, however, shows that even the most advanced model in the study refused fewer than three percent of poisoned calls. Fine-tuning may improve detection, but it cannot guarantee safety against novel payloads embedded in schema fields that the model has never seen.
What to watch next
- Emerging standards – Watch for proposals from the LLM security community to require cryptographic signatures on tool schemas.
- Tool-registry hardening – Vendors may start offering immutable, read-only registries as a service, reducing the attack surface.
- Model-level defenses – Research into prompting techniques or auxiliary models that flag suspicious tool metadata could complement host-side safeguards.
The practical takeaway is clear: any MCP-based deployment should audit tool descriptions with the same rigor applied to third-party libraries. Ignoring the supply-chain risk turns a convenient abstraction into a silent backdoor. By pinning servers, enforcing least-privilege allowlists, gating state-changing actions, involving humans where needed, and keeping an immutable log, developers can keep their LLM agents from becoming unwilling accomplices.