Existe uma variante de injeção que não depende de o agente ler nada externo durante a tarefa. O conteúdo hostil já está lá desde a conexão, dentro da declaração das próprias ferramentas.
O vetor
Ao conectar, o cliente busca o manifesto do servidor e injeta no contexto o nome, a descrição e o esquema de argumentos de cada ferramenta. Esses campos são texto livre controlado por quem publicou o servidor. Uma descrição pode conter instruções — e o modelo as lê no mesmo canal em que lê a tarefa.
O agravante é que essa injeção acontece antes de qualquer interação, afeta todas as tarefas daquela sessão, e não deixa rastro numa análise que só olhe o conteúdo lido durante a execução.
Três formas que o ataque assume
- Instrução direta na descrição — texto pedindo que a ferramenta seja usada de determinada maneira, ou que outro recurso seja lido antes.
- Ocultação. Pesquisadores documentaram payloads em blocos de tag Unicode invisíveis, produzindo divergência entre o que a tela de aprovação mostra e o que o modelo lê.
- Rug pull. O manifesto é buscado a cada conexão. O servidor aprovado em janeiro pode declarar outra coisa em março, sem nenhum evento de mudança.
Você revisou o servidor uma vez. Ele se redeclara toda vez que conecta.
Controles
- Fixar o manifesto por hash na aprovação e comparar a cada conexão. Divergência vira alerta e bloqueio, não atualização silenciosa.
- Normalizar e rejeitar caracteres invisíveis, blocos de tag e controle nos campos de metadados.
- Revisar manifesto como código, por pull request, com aprovador nomeado.
- Fixar versão e digest do servidor, nunca instalar da última tag.
A analogia que ajuda a vender internamente
Tool poisoning é dependência não pinada com privilégio de execução. Toda organização de engenharia já entende por que lockfile existe e por que se revisa mudança de dependência. É o mesmo argumento, aplicado a um artefato que hoje ninguém trata como dependência — e é por isso que o argumento costuma funcionar rápido com o time de plataforma.
