Tool poisoning: quando uma ferramenta aparentemente confiável esconde instruções

Introdução

O termo tool poisoning descreve uma classe de risco em que o conteúdo associado a uma ferramenta — por exemplo, sua descrição ou seus resultados — pode induzir o modelo a se comportar de forma diferente da esperada. Não significa que todas as ferramentas MCP estejam envenenadas nem que o protocolo force esse comportamento.

Por que a descrição importa

O modelo pode receber detalhes de uma ferramenta que não são apresentados com o mesmo nível de detalhe à pessoa usuária. Uma descrição ambígua, enganosa ou que inclua instruções não relacionadas à função declarada pode influenciar a seleção de ferramentas e os dados enviados a elas. Uma tela de aprovação que mostre apenas um nome curto pode não permitir entender a operação solicitada.

A pesquisa da Invariant Labs de abril de 2025 popularizou o termo e apresentou experimentos sobre descrições maliciosas e mudanças posteriores de ferramentas. É evidência de pesquisa sobre riscos e configurações concretas, não uma medida de prevalência em todo o ecossistema nem um requisito normativo do MCP.

Revisar mais do que o nome

Documente a finalidade de cada ferramenta, suas entradas, seus efeitos e os dados que acessa. Verifique se a descrição corresponde à implementação e apresente ao usuário os argumentos e efeitos materiais antes de uma ação sensível. Mantenha a aprovação vinculada a uma identidade e versão verificáveis do servidor e revise mudanças de esquema ou comportamento.

Limite capacidades, separe leitura de escrita, valide entradas e aplique autorização no serviço que realiza a operação. Uma descrição aparentemente benigna não substitui controles técnicos; uma confirmação tampouco ajuda se ocultar os parâmetros importantes.

Conclusão

O tool poisoning ressalta um ponto geral: as ferramentas e seus resultados fazem parte da superfície de confiança. Avalie o conteúdo que o modelo consome junto com o código, as permissões e a experiência de aprovação.