Seu Agente Agora Tem Ferramentas: Por Que Chamadas de Ferramentas MCP Precisam de Verificação em Tempo de Execução

Durante a maior parte da curta história das aplicações LLM, o risco do modelo era o risco de texto. Um modelo poderia fornecer conselhos ruins, vazar algo de seu prompt ou produzir um rascunho convincente de phishing — mas não poderia tocar na sua máquina. O pior cenário terminava na tela.

Conecte algumas ferramentas a esse modelo — um shell, um buscador HTTP, um cliente de sistema de arquivos, um SDK de nuvem — e a equação muda. Com o Protocolo de Contexto do Modelo, os agentes não apenas sugerem operações; eles as realizam, com suas credenciais, em sua infraestrutura. A superfície de ataque muda de "texto que o modelo escreveu" para "ações que o modelo executou." Um prompt que costumava produzir um parágrafo agora pode produzir um processo.

Se você está enviando agentes com acesso a ferramentas, a higiene de configuração é necessária, mas não suficiente. Aqui está o porquê e o que a verificação em tempo de execução adiciona.

Quatro maneiras como chamadas de ferramentas podem dar errado

Os padrões de abuso abaixo são categorias bem conhecidas — descritas genericamente, sem referência a incidentes de projetos específicos.

1. Ferramentas de execução de código → execução remota de código. Ferramentas de shell, exec e interpretadores existem porque os agentes realmente precisam delas: executar testes, estruturar projetos, transformar dados. Mas qualquer string que chegue a um shell é um comando. Conteúdo buscado de uma página da web, um nome de arquivo, uma mensagem de erro ou os metadados de uma dependência podem carregar metacaracteres de shell. O modelo não precisa ser "hackeado" no sentido clássico — ele só precisa passar fielmente texto influenciado por um atacante para uma ferramenta de execução.

2. Ferramentas de busca / HTTP → SSRF. Os agentes adoram buscar URLs: docs, APIs, "leia este link que o usuário colou." Uma URL também é um destino de rede. Aponte um buscador para um endpoint de metadados de nuvem (169.254.169.254), um endereço privado RFC1918 ou localhost:port e o agente se torna um primitivo SSRF — lendo serviços internos de dentro do seu perímetro de rede e resumindo o que encontrou.

3. Exfiltração de credenciais e variáveis de ambiente. Processos de agentes herdam o ambiente: AWS_*, GITHUB_TOKEN, URLs de banco de dados, chaves de API. As ferramentas frequentemente aceitam pares chave/valor ou argumentos arbitrários. Uma cadeia de dois passos — ler um arquivo ou variável de ambiente sensível, depois POST para algum lugar via a ferramenta HTTP — transforma um "agente útil" em um canal de exfiltração. Nenhum dos passos parece dramático por si só.

4. Injeção de prompt → chamadas de ferramentas não autorizadas. Conteúdo não confiável no contexto do modelo (uma página da web, um e-mail, um arquivo, um resultado de ferramenta) pode conter instruções direcionadas ao modelo. O modelo é quem segura as alças das ferramentas, e ele nem sempre consegue distinguir suas instruções das instruções embutidas nos dados. O resultado é uma chamada de ferramenta que você nunca autorizou, realizada com sua autoridade.

Por que verificações de configuração estática não são suficientes

Escanear sua configuração MCP é o primeiro passo certo. Um scanner estático captura problemas reais e corrigíveis: transportes HTTP simples, verificação TLS desativada, credenciais coladas diretamente no JSON de configuração, timeouts ausentes, permissões excessivamente amplas, versões de servidor não fixadas. O correctover-scan de código aberto executa 14 verificações locais contra seus arquivos de configuração e descobre automaticamente os locais usuais — .cursor/mcp.json, claude_desktop_config.json, .claude/mcp.json, mcp.json e alguns mais.

Mas um arquivo de configuração é estático, e a parte perigosa é dinâmica. Seu mcp.json nunca conterá o argumento que o modelo constrói às 3 da manhã — a URL que decidiu buscar, a string de comando que montou a partir de um resultado de ferramenta, o nome da variável de ambiente que colocou em um corpo HTTP. A análise estática responde "esta configuração é razoável?"; não pode responder "esta chamada específica é segura?"

A atalho tentador é uma lista negra de palavras-chave: bloquear chamadas contendo exec, bloquear URLs contendo 169.254, bloquear argumentos contendo AWS_SECRET. Isso não funciona, porque a segurança é contextual:

• Uma ferramenta de interpretador de código executando exec() como sua função normal e declarada é ok.
• Um modelo concatenando texto buscado e não confiável em uma string exec() passada para um shell é crítico.
• Um buscador recuperando uma URL de docs pública é ok; o mesmo buscador atingindo o endpoint de metadados é crítico.
• Ler um arquivo é ok; ler um arquivo e imediatamente canalizar seu conteúdo para uma URL externa é uma cadeia de exfiltração.

Mesmos tokens, diferentes veredictos — porque a ferramenta, o chamador, os argumentos e a cadeia de chamadas anteriores diferem. Esse julgamento deve acontecer no momento da chamada, com os argumentos reais em mãos.

O que a verificação em tempo de execução deve checar

Um verificador em tempo de execução se coloca na frente da execução da ferramenta e avalia cada chamada antes que ela seja executada. Para segurança, cinco camadas são as mais importantes:

1. Estrutura — nome da ferramenta bem formado, argumentos como um objeto, profundidade de aninhamento e tamanho de carga úteis razoáveis. Chamadas malformadas são rejeitadas, não embaralhadas na ferramenta.
2. Esquema — validação por ferramenta: tipos, campos obrigatórios, enums, intervalos numéricos, comprimentos de string. Uma chamada payments.send com amount como uma string falha antes de chegar à API.
3. Identidade — qual agente está chamando, contra uma lista de chamadores permitidos. As permissões da ferramenta pertencem a identidades, não ao processo em tempo de execução.
4. Integridade — hashes criptográficos sobre os argumentos e a solicitação exatos, além de recibos assinados que vinculam o veredicto (permitir/negar/escalar) a esses bytes exatos. Isso lhe dá evidências à prova de adulteração: após um incidente, você pode provar o que foi decidido e com qual entrada, e encadear recibos em fluxos de múltiplas etapas ou múltiplos agentes.
5. Intenção de segurança — análise semântica da chamada em contexto: padrões de injeção de comando, alvos SSRF (IPs de metadados, loopback, intervalos privados), travessia de caminho, sinais de exfiltração de variáveis de ambiente, ofuscação (envoltório hex/base64), marcadores de injeção de prompt e — criticamente — cadeias de ataque entre ferramentas (ler-arquivo-sensível → rede-escrever = exfiltração, mesmo que cada passo isoladamente pareça benigno).

Duas propriedades inegociáveis:

• Falhar fechado. Se o verificador estiver inacessível, expirar ou receber entrada malformada, a chamada é bloqueada. Um caminho de verificação que gera erro aberto não é um verificador.
• Determinístico e rápido. A verificação de intenção é uma computação baseada em padrões e políticas — nenhuma chamada LLM no loop de decisão. O alvo é sub-milissegundo no caminho de verificação central, então a verificação é algo que você deixa ativado em desenvolvimento, não algo que você contorna quando o agente parece lento.

Experimente em 30 segundos

Passo 1 — escaneie suas configurações localmente. Zero dependências, nenhuma rede necessária:

# Descobre automaticamente .cursor/mcp.json, claude_desktop_config.json,
# .claude/mcp.json, mcp.json e amigos no diretório atual
npx correctover-scan

# Ou aponte para um arquivo / diretório, com saída SARIF para CI
npx correctover-scan mcp.json -f sarif > report.sarif
npx correctover-scan -d ./meu-projeto