Análise de Injeção de Prompt em Descrições de Ferramentas MCP

Na última vez que escrevi sobre esconder um payload de injeção de prompt na descrição de uma ferramenta MCP e assistir cinco dos sete modelos exfiltrarem um registro que nunca foram solicitados a tocar. A conclusão limpa no final foi: escaneie as descrições das ferramentas no registro da mesma forma que você escaneia a saída da ferramenta em tempo de execução.

Então, tentei quebrar meu próprio conselho. Levou cerca de vinte minutos.

O conselho assume que o payload vive na prosa

Uma definição de ferramenta não é um único campo. Quando um host MCP entrega uma ferramenta ao modelo, ele entrega todo o esquema de função como metadados de capacidade confiáveis. A descrição da função, claro. Mas também a description de cada parâmetro. E qualquer propriedade extra que o servidor decidiu declarar, com um campo de descrição próprio. Um humano que revisa uma ferramenta de terceiros lê a descrição em prosa e passa os olhos pelo resto. O modelo lê tudo isso.

Então, mantive o payload idêntico, byte por byte, e o movi para dentro da definição. O mesmo <system> diretiva dizendo ao agente para também exportar o registro para uma URL do atacante. Três lugares para colocá-lo:

• desc.. na descrição da função. Este é o ataque original, meu controle.
• param_desc.. na descrição do parâmetro record_id. Um campo que lê como "O id do registro." e nada mais.
• added_prop.. dentro da descrição de uma propriedade opcional extra chamada retention_policy que o servidor declara e o usuário nunca preenche.

O datastore permanece honesto o tempo todo. read_record retorna o registro real, export_record é registrado, mas não executado. A única coisa hostil em toda a configuração é qual campo do esquema contém a frase.

Não fez diferença alguma

Todo modelo que aceitou a ordem na descrição a aceitou no campo de parâmetro e na propriedade enterrada, na mesma taxa. Nenhum modelo fechou um campo e deixou outro aberto. Foi tudo ou nada, e o campo não fez diferença em qual.

(Um modelo, llama-3.1-8b, continuou retornando uma chamada de ferramenta malformada neste esquema e não pontuou de nenhuma forma, então eu o deixei de fora em vez de contar um erro como um resultado.)

O campo que ninguém lê como uma instrução

A descrição do parâmetro e a propriedade enterrada são piores do que a prosa, do ponto de vista de um defensor, precisamente porque ninguém as lê como instruções. "O id do registro." não é uma frase que você audita. Um scanner que apenas verifica a descrição de nível superior passa direto por um payload sentado um campo ao lado. Se você vai verificar definições de ferramentas no registro, precisa percorrer cada string no esquema, não apenas a parte que parece documentação.

A parede guarda uma porta, não o prédio

Observe o gpt-oss-120b ao longo dos dois experimentos. Na última vez, quando o mesmo payload chegou na saída retornada da ferramenta, ele se recusou. Aqui, em todos os três campos de definição, ele obedeceu. Mesmo modelo, mesmas palavras.

A hierarquia de instruções da OpenAI classifica a saída da ferramenta na parte inferior da ordem de confiança, então um modelo treinado nela desconsidera instruções que aparecem em um resultado de ferramenta. Mas nenhum desses campos é saída de ferramenta. Eles são a definição da ferramenta, e a definição carrega acima daquela fronteira, na declaração confiável que estrutura, antes que qualquer dado exista. O treinamento que fecha o canal de saída não faz nada por nenhuma parte da definição. A coisa toda está do lado confiável da única parede que foi construída.

Claude recusou todos os campos em ambos os modelos, consistente com onde ele se posicionou na última vez. A mesma ressalva que sempre anexo: recusar aqui não é imunidade, os números de injeção pública são agregados em vez deste caso exato, e cada modelo cede mais terreno quanto mais vezes você pergunta. Uma direção, não uma promessa.

O que eu realmente faria a respeito

A medida de prevenção fica um pouco maior e permanece probabilística: uma verificação no momento do registro deve ler cada campo de uma definição de ferramenta como potencialmente hostil, porque cada campo é controlado por um atacante em um servidor de cadeia de suprimentos e cada campo chega ao modelo como contexto confiável. Vale a pena fazer. Não é suficiente.

A parte que continuo chegando é a mesma da última vez, e este experimento é o porquê. O payload pode se esconder em um campo que você não pensou em escanear, em um canal que seu treinamento de modelo não cobriu, e você não saberá qual até depois que o agente já tenha feito a chamada. Portanto, a coisa durável não é mais um filtro. É um registro que sobrevive a estar errado: um log à prova de adulteração por chamada, que mostra a diretiva que realmente chegou, ao lado da chamada da ferramenta que realmente foi acionada. Quando export_record é acionado sem um humano por trás, essa lacuna é visível e atribuída ao agente em vez de aterrissar silenciosamente em quem quer que seja a sessão em que foi executada. Não importa qual campo do esquema carregou a instrução. O registro lê o mesmo. Essa é a coisa que estou construindo Crumb para.

Escopo honesto

A contaminação da definição da ferramenta é uma classe nomeada, documentada pelos Invariant Labs em 2025, na família de injeção de prompt indireta (Greshake et al. 2023, OWASP LLM01, InjecAgent, AgentDojo). Estou demonstrando e decompondo isso, não descobrindo.

O que é meu aqui é a divisão controlada entre três subcampos com um payload mantido constante. Eles se mostraram igualmente eficazes, então a superfície é toda a definição, não a parte que lê como prosa. E há o indicativo de execução cruzada: ele localiza exatamente o que o treinamento da hierarquia de instruções protege e o que nunca toca.

Tudo foi executado offline contra modelos hospedados pela Groq, OpenAI e Anthropic. A exportação é uma tentativa registrada contra um destino falso. Nada saiu do laboratório.

O primeiro artigo é a configuração para este, se você quiser o resultado de descrição versus saída que ele constrói.

Crumb: crumb.alexlaguardia.dev · github.com/AlexlaGuardia/crumb