Envenenamento de ferramenta MCP e rug-pulls

Um servidor MCP de terceiros ou uma skill instalada é uma dependência de cadeia de suprimentos. Dois modos de falha se destacam:

• Envenenamento — o servidor foi malicioso desde o início. Seu manifesto pareceu benigno; o comportamento perigoso estava na implementação da ferramenta, não nos escopos declarados.
• Rug-pull — você confiou nele, depois ele mudou. Uma nova ferramenta apareceu que o operador do servidor adicionou silenciosamente, ou uma entrada de registro da comunidade foi sequestrada e atualizada para ligar para casa.

Ambas as ameaças compartilham uma causa raiz: depois que você disse “eu confio neste servidor”, seus agentes continuam chamando suas ferramentas — mesmo as novas ou modificadas — sem revisão adicional.

​

1. Como o envenenamento de ferramenta MCP alcança seus agentes

Cada tools/call que seu agente emite viaja pelo conjunto de ferramentas declarado do servidor MCP. Um servidor envenenado ou com rug-pull explora essa confiança de algumas maneiras:

​

2. As defesas do OrcaRouter

​

2.1 Cada tools/call é avaliado pelo firewall antes de executar

Servidores MCP se conectam aos seus agentes pelo gateway MCP do Firewall em /api/v1/firewall/mcp. O gateway não encaminha uma chamada de ferramenta até que o motor de firewall a tenha avaliado contra sua política. Isso significa que sua lista de permissão é a fonte da verdade — não o manifesto de ferramentas do servidor. Se um rug-pull adiciona shell.exec e sua política não tem nenhuma regra permitindo-o, o veredito é deny e a chamada nunca sai do gateway. O modelo recebe um erro de ferramenta (firewall deny: …) e pode reagir; a ferramenta adicionada pelo atacante está morta na chegada. Vereditos que o motor pode retornar:

​

2.2 Capacidades auto-detectadas são colocadas em quarentena até revisão

Quando um agente auto-instala uma capacidade — ou um rug-pull adiciona novas ferramentas que não estavam presentes quando você registrou o servidor — o Firewall auto-detecta a nova capacidade fora do caminho quente, sintetiza um manifesto, escaneia-o e atribui uma banda de risco e modo de enforcement. Crucialmente, capacidades auto-detectadas são sempre colocadas em quarentena independentemente do resultado do scan: elas são retidas em pending_approval até que um humano as revise. É assim que os rug-pulls são contidos. Um operador não pode adicionar silenciosamente uma nova ferramenta e fazer seus agentes começar a usá-la — essas chamadas são retidas até que você inspecione e aprove a nova capacidade.

​

2.3 O escaneamento de skill atribui uma banda de risco e modo de enforcement

Cada capacidade instalável — seja registrada por você ou auto-detectada pelo Firewall — passa pelo scanner de skill. O scanner executa passes determinísticos sobre o manifesto e escopos declarados:

• prompt_injection — texto de manifesto que tenta sequestrar instruções.
• tool_creep — ferramentas que o manifesto usa mas nunca declarou.
• network_egress — hosts HTTP(S) fora dos escopos de rede aprovados.
• fs_write_unsafe — acesso ao sistema de arquivos em modo de escrita fora de /tmp.

Os achados se somam a uma banda de risco (low / medium / high / critical) e um modo de enforcement: Uma skill de banda high é colocada em quarentena automaticamente; critical é bloqueada. Um único achado de error (ex.: tool_creep para um shell.exec não declarado) é suficiente para bloquear uma skill mesmo quando sua pontuação numérica parece baixa. O modo só aumenta a restrição — aprovar uma skill nunca relaxa um bloqueio definido por um scan novo.

​

2.4 Credenciais são armazenadas criptografadas

Segredos de autenticação do servidor são criptografados em repouso com uma chave de segredos do workspace e injetados pelo gateway no tempo de dispatch. Eles nunca alcançam o modelo, o agente ou os argumentos da chamada. Um servidor comprometido não pode exfiltrar suas chaves de API lendo seu próprio auth_json.

​

3. O que fazer após um rug-pull suspeito

1. Desabilite o servidor imediatamente — um servidor desabilitado é removido do registro de runtime e suas credenciais nunca são descriptografadas. Use PUT /api/workspace/firewall/mcp_servers com "enabled": false.
2. Re-sonde para exibir mudanças — POST /api/workspace/firewall/mcp_servers/:id/probe executa tools/list e retorna quaisquer novas ferramentas que apareceram desde sua última sondagem.
3. Rescancie o registro de skill — POST /api/workspace/firewall/skills/:id/rescan re-executa o scanner contra o manifesto atualizado. Se o veredito piora para flagged ou blocked, o Firewall emite um evento no seu feed.
4. Revise a fila de pending_approval — quaisquer chamadas retidas desde o rug-pull estão na fila. Inspecione e negue-as em vez de aprovar em massa.
5. Audite o log de chamadas — verifique a trilha de eventos do Firewall para chamadas que passaram antes que você detectasse a mudança.

​

4. Combinando escaneamento de skill com regras de firewall

O escaneamento de skill e as regras de firewall são complementares e se compõem:

• Uma regra com tool_name_glob: community.* definida como pending_approval garante que você revise cada chamada de um servidor fornecido pela comunidade, independentemente da banda de risco.
• Uma skill em quarentena substitui uma regra allow — mesmo que sua política permita http.fetch amplamente, uma skill em quarentena que a possui ainda retém a chamada.
• Use skill_name_glob em uma regra para aplicar políticas mais restritivas a servidores não confiáveis sem afetar suas integrações próprias.

Veja Firewall: Servidores MCP para o modelo completo de gateway e Firewall: Skills para o scanner e referência de modo de enforcement.

​

5. Ameaças relacionadas

• Chamadas de ferramenta perigosas — regras para bloquear ações de ferramenta destrutivas ou irreversíveis independentemente da fonte.
• Exfiltração de dados — regras de egress que restringem para onde chamadas de ferramenta podem enviar dados.
• Modelo de ameaças — a superfície de ataque completa que o OrcaRouter foi projetado para defender.