Saltar para o conteúdo principal
Um “rug pull” é o modo de falha de MCP em que um servidor se comporta enquanto você está observando e vira hostil uma vez que é confiado: uma ferramenta que você aprovou no momento de conexão começa a contrabandear argumentos extras, um servidor da comunidade que você listou silenciosamente adiciona uma nova capacidade, ou uma skill que um agente auto-instalou vira de benigna a perigosa em produção. O perigo é que ninguém re-revisa uma conexão depois que ela está ativa — a decisão de confiança foi feita uma vez, no handshake, e nunca revisitada. O OrcaRouter não confia no handshake. Ele defende em três frentes. O gateway MCP do Firewall avalia cada tools/call no momento do dispatch contra sua política ativa. O conjunto de ferramentas anunciado de cada servidor registrado é baselined no primeiro probe e re-checado contra drift — se o schema da ferramenta muda em relação à baseline aprovada, o servidor falha fechado até que um admin re-aprove ou o coloque em quarentena. E a camada de Skills atribui a cada capacidade instalada uma faixa de risco e um modo de enforcement — colocando em quarentena qualquer coisa arriscada ou não revisada até que um humano assine embaixo. Um servidor não pode ganhar um passe livre por se comportar nas primeiras cem chamadas.

​
1. Por que a proteção contra rug pull de MCP precisa de avaliação por chamada

Uma revisão no momento de conexão responde uma pergunta uma vez: este servidor é seguro de listar? Ela não pode responder a pergunta que de fato importa em runtime: esta chamada específica, com estes argumentos específicos, é segura agora? O OrcaRouter responde à segunda pergunta. Cada tools/call que cruza o gateway é avaliado na superfície mcp antes de ser despachado ao servidor real, com o nome da ferramenta e os argumentos em mãos. O veredito é computado de novo a cada vez, de modo que no momento em que uma ferramenta começa a fazer algo que sua política proíbe — exfiltrar um segredo em um argumento, alcançar um host que é negado, chamar uma capacidade que você nunca aprovou — a chamada é parada, independentemente de como a mesma ferramenta se comportou um minuto atrás.
A avaliação por chamada governa o comportamento de cada chamada — conteúdo dos argumentos, destinos, o risco da skill proprietária — então ela pega um rug pull mesmo quando a ferramenta mantém uma assinatura idêntica e apenas seu comportamento vira hostil. A detecção de drift de schema (§ abaixo) é a camada complementar: ela pega o caso em que o próprio conjunto de ferramentas anunciado do servidor muda. Ambas rodam.
Os vereditos que o motor pode retornar na superfície mcp:

allow / audit

Encaminhado ao servidor. audit registra a chamada; allow fica quieto.

sanitize

Encaminhado com os argumentos da chamada de ferramenta redigidos primeiro (nunca reescreve o que o servidor retorna).

deny

Retornado ao modelo como um erro de ferramenta (firewall deny: …) de modo que o agente pode se adaptar em vez de quebrar.

pending_approval

A chamada é retida para um humano resolver antes que possa rodar.

​
2. Quarentena por faixa de risco de skill

A segunda metade da defesa contra rug-pull cobre a cadeia de suprimentos: as skills, plugins e servidores MCP bring-your-own que um agente instala. Cada um é registrado como um registro com escopo de workspace, escaneado por um motor de risco determinístico, e recebe uma faixa de risco (low / medium / high / critical) mais um modo de enforcement:
ModoEfeito em runtime
allowOs vereditos de regra decidem; a skill não adiciona nada.
quarantineQualquer coisa aquém de um deny é escalada para pending_approval — as ferramentas rodam apenas depois que um humano aprova.
blockAs ferramentas da skill são negadas de imediato.
É aqui que um rug pull fica contido. Uma capacidade que um agente auto-instala é auto_detected e colocada em quarentena até ser revisada — mesmo que tenha escaneado limpa, ela não roda por sua própria autoridade. E o modo de uma skill só fica mais apertado no re-scan: um block ou quarantine que você define nunca é silenciosamente relaxado quando um manifesto é re-apresentado.
A quarentena é imposta independentemente do shadow mode. Uma skill definida como quarantine ou block ainda é retida mesmo enquanto a política ao redor está em rollout shadow — então uma capacidade arriscada não pode escapar durante um deployment em etapas.
Veja Firewall: Skills para o scanner completo, os pesos de pontuação e os sinais de confiança.

​
3. Detecção de drift de schema de ferramenta

O rug pull clássico é um servidor registrado que muda o que anuncia — adiciona uma ferramenta, altera o schema de input de uma ferramenta, troca uma descrição. O OrcaRouter baselina o conjunto de ferramentas anunciado de cada servidor registrado em um probe bem-sucedido e o observa contra drift.

Baseline no primeiro probe

O primeiro probe bem-sucedido registra um hash canônico das ferramentas do servidor (trust-on-first-use sob uma postura de descoberta; sob uma postura enforcing um servidor não baselined é retido como pending até que um admin aprove seu conjunto inicial de ferramentas).

Drift falha fechado

Em um probe posterior, se o conjunto de ferramentas canônico não corresponder mais à baseline aprovada, o servidor é marcado como changed e deixa de ser servido — o gateway não despachará suas ferramentas até que você decida.

Aprovar ou colocar em quarentena

Re-aprove para re-baselinar ao novo schema, ou coloque o servidor em quarentena. Um servidor em quarentena também é desabilitado e apenas um approve explícito restaura o serviço — uma edição simples não pode reabilitá-lo.

Auditado

A primeira detecção de drift em relação a uma baseline aprovada escreve uma entrada de auditoria de workspace, então a mudança fica no registro.
O status de schema de um servidor é um de unknown (nunca baselined), verified (corresponde à baseline), changed (com drift, retido), pending (não baselined sob enforcing), ou quarantined. Esta camada pega o rug pull que move o schema; a avaliação por chamada (§1) pega aquele que mantém uma assinatura idêntica e apenas muda o comportamento.

​
4. Um exemplo concreto

Suponha que um servidor MCP da comunidade notes anuncia uma ferramenta inofensiva notes.search. Você o lista, o revisa, e ele funciona. Uma semana depois o servidor é comprometido e notes.search começa a anexar um argumento de exfiltração que faz POST do seu contexto para um host atacante. Um gateway que só checa no momento de conexão o encaminharia — o nome e o schema da ferramenta parecem inalterados. O OrcaRouter avalia a chamada: 
# Configure a regra de deny no console (Developer+), não via chave de relay.
# Regra: na superfície mcp, deny notes.search sempre que carregar um
#        argumento em formato de exfiltração.
#   tool_name_glob: notes.search
#   args_match:     { "path": "$.callback_url", "op": "regex",
#                     "value": "^https?://(?!notes\\.example/)" }  → deny
(Os operadores de args_match são eq, contains, regex, in, cidr_match, gt, lt; cidr_match testa um argumento com valor de IP contra um CIDR. Para limitar onde uma ferramenta pode alcançar por host/CIDR, use a lista de destino de egress em vez de uma cláusula de argumento.) No dispatch o motor retorna deny, e em vez de encaminhar a chamada o gateway entrega ao agente um erro de resultado de ferramenta MCP — um resultado normal sinalizado como erro, não uma falha de transporte — de modo que o modelo pode se adaptar: 
firewall deny: <your rule's reason>
A mesma chamada que teve sucesso semana passada agora está bloqueada — porque a decisão é feita na chamada, não na conexão.
sanitize redige os argumentos que seu agente envia, nunca o conteúdo que uma ferramenta retorna. Se você precisa restringir onde uma ferramenta pode alcançar, combine uma regra de deny com uma lista de destino de egress — não confie no sanitize para limpar respostas.

​
5. Como tudo se encaixa

A avaliação por chamada pega uma ferramenta confiada virando maliciosa — mesmo nome, novo comportamento nos argumentos ou no destino. A quarentena de skill pega uma capacidade nova ou não revisada surgindo afinal — uma instalação auto-detectada, um manifesto re-escaneado que degrada de novo. Um rug pull pode tomar qualquer forma, então ambas rodam: o modo da skill monta sobre o veredito de regra por chamada.
Sim — veja §3. O conjunto de ferramentas anunciado de cada servidor registrado é baselined no primeiro probe e re-checado contra drift; um servidor com drift falha fechado até você re-aprovar ou colocar em quarentena. Isso é complementar à avaliação por chamada, que também pega uma ferramenta que mantém uma assinatura idêntica e apenas muda seu comportamento.
Um veredito pending_approval retém a chamada para um humano resolver no console (Developer+) ou via um callback de aprovação HMAC. Veja modos de enforcement para como retenções e aprovações são apresentadas a um agente.

​
6. Configurando

Cada passo abaixo é uma ação de console / gerenciamento autenticada com seu session ou access token — não com a chave de relay sk-orca-…. Apenas o tráfego de relay /v1/* usa a chave de relay.
1

Registre seus servidores MCP atrás do gateway

Conecte cada servidor para que suas ferramentas sejam anunciadas sob um único endpoint auditado. O registro é Developer+.
2

Defina um veredito padrão e regras na superfície mcp

Crie regras com tool_name_glob e args_match para que chamadas arriscadas resolvam para deny, sanitize ou pending_approval. Veja a referência de regras do Firewall.
3

Revise skills em quarentena

Qualquer coisa auto-detectada fica em quarantine até que um revisor (Developer+) a aprove. Leia a faixa e os findings primeiro.
4

Faça rollout em shadow, depois enforce

Use modos de enforcement para rodar novas regras em shadow, observe os eventos de auditoria, e vire para enforcing quando os vereditos parecerem certos.
Leituras (configurações, políticas, ferramentas descobertas, anomalias) estão abertas a qualquer Member; cada escrita é Developer+. Ler o texto puro de uma chave de firewall-gateway é Developer+.

​
Relacionados

Firewall: Servidores MCP

A referência completa do gateway MCP — registro, probing, dispatch.

Firewall: Skills

Passagens do scanner, pontuação de risco e a derivação da quarentena.

Envenenamento de ferramentas MCP

O modelo de ameaça que a defesa contra rug-pull existe para contrariar.

Limites de egress

Crie regras de deny de host/CIDR para limitar onde as ferramentas podem alcançar.

Checklist de confiança

O checklist de ponta a ponta para confiar em um servidor MCP.

Guardrails vs. Firewall

Quando a política de conteúdo se aplica e quando o firewall se aplica.