Injeção de comandos e validação de entradas: proteger ferramentas que executam ações

Introdução

Uma ferramenta pode parecer uma função simples e acabar executando um processo, consultando um banco de dados ou modificando um recurso externo. Se a entrada for concatenada em um comando ou interpretada sem controles, surge um risco de injeção. A causa está no projeto e na implementação da ferramenta, não no MCP como protocolo.

Validar o significado, não apenas o formato

Defina esquemas estritos: tipos, comprimentos, formatos e campos permitidos. Rejeite valores inesperados com erros claros. Mas uma entrada que cumpre o esquema pode continuar fora da autorização: verifique também se o usuário pode operar sobre esse recurso e se a ferramenta permite essa ação em seu contexto.

Quando precisar invocar um processo, utilize APIs estruturadas ou execução com argumentos separados em vez de concatenar dados em uma string de shell. Evite intérpretes quando não forem necessários. Use caminhos permitidos, diretórios de trabalho controlados e um ambiente isolado com permissões mínimas.

Para operações com efeitos, limite a ação a uma tarefa concreta; não transforme instruções livres do modelo em comandos arbitrários. Aplique limites de tempo, saída e recursos. O serviço que recebe a solicitação deve validar sua própria autorização: a validação do cliente ou uma confirmação de interface não bastam.

Testes e erros seguros

Teste limites, campos ausentes, tipos incorretos e entradas inesperadas com dados de teste inofensivos. Verifique se uma operação rejeitada não deixa efeitos parciais. Mantenha mensagens de erro úteis para diagnosticar, sem devolver segredos, caminhos internos ou detalhes desnecessários.

Conclusão

A defesa combina validação semântica, autorização, APIs seguras, isolamento e testes negativos. A saída mais segura costuma ser uma operação estreita e predefinida, não um intérprete geral conectado ao modelo.