Saltar para o conteúdo principal
Um servidor MCP de terceiros é um pacote não revisado de ferramentas, uma credencial ativa e um novo alcance de rede. No momento em que um agente disca para um diretamente, ninguém está observando a chamada — e “o servidor mudou suas ferramentas depois que você o aprovou” é um ataque real, não um hipotético. Antes de apontar um agente para um servidor que outra pessoa opera, você quer uma verificação pré-voo repetível. Esta página é essa verificação pré-voo: um checklist curto e ordenado para avaliar conexões de servidor mcp no OrcaRouter usando controles que já existem — avaliação por chamada, lista de permissão default-deny, limites de egress, credenciais criptografadas e quarentena de skill. Cada passo linka para o how-to focado para aprofundamento. Rode-o uma vez por novo servidor; re-rode os passos sensíveis a drift sempre que o servidor mudar.
Cada passo de configuração aqui é feito a partir do console (ou da API REST com o seu token de sessão/acesso) e é restrito por papel. Apenas as rotas do gateway do firewall e as chamadas de relay /v1/* carregam uma chave no estilo sk-orca-....

​
1. O checklist para avaliar conexões de servidor mcp

Trabalhe de cima para baixo. Os três primeiros passos são obrigatórios para qualquer servidor que você não opera; o resto o endurece.

1. Faça probe antes de confiar

Descubra a lista real de ferramentas e a alcançabilidade antes de escrever uma única regra.

2. Negue por padrão, depois faça a lista de permissão

Permita apenas as ferramentas que você revisou; todo o resto é negado.

3. Criptografe a credencial

Armazene a auth de modo que seja criptografada em repouso, mascarada na leitura, nunca vista pelo modelo.

4. Restrinja egress

Restrinja onde as ferramentas do servidor podem alcançar na rede.

5. Coloque em quarentena skills auto-instaladas

Retenha qualquer coisa que o agente instale por conta própria até que um humano a revise.

6. Shadow primeiro, depois observe

Faça rollout em apenas-audit, depois leia eventos e anomalias antes de aplicar o enforcement.

​
2. Faça probe antes de confiar

Você não pode revisar ferramentas que nunca viu, e a lista de ferramentas anunciada de um servidor é a coisa com mais probabilidade de mudar sob você. Registre o servidor, depois faça probe dele — o gateway roda um initialize + tools/list MCP contra o endpoint e retorna as ferramentas reais com seus schemas de input, mais um status de alcançabilidade de ok, degraded ou down. 
# Rota de console, chamada com o seu token de sessão/acesso (UserAuth). Developer+.
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Leia cada nome de ferramenta e o que seus argumentos aceitam. Um servidor anunciando um shell.exec ou um http_fetch que você não esperava é um achado, não um detalhe — esse é todo o propósito de fazer probe primeiro.
Faça probe novamente sempre que um servidor mudar de mãos ou você suspeitar de drift. Uma nova ferramenta aparecendo na lista — o “rug pull” — é exatamente o que você está observando. Veja Defesa contra rug-pull.
A referência completa de registro e probe fica em Firewall: servidores MCP; o passo a passo de ponta a ponta é Conectar um servidor MCP.

​
3. Negue por padrão, depois faça a lista de permissão das ferramentas que você revisou

Uma lista de permissão é a diferença entre “o servidor pode fazer seis coisas” e “o servidor pode fazer o que seu operador decidir amanhã.” Defina o default_verdict da política como deny, depois adicione uma regra por ferramenta que você revisou e confia. Como o gateway dá namespace a cada ferramenta <server>.<tool>, você pode escopar regras a um servidor sem tocar nos outros. 
// Política na superfície mcp: negue por padrão, permita só o que você revisou.
// tool_name_glob suporta um wildcard de segmento completo: "github.*" (prefixo),
// "*.exec" (sufixo) ou "*.shell.*" (infixo). Globs de meio-de-segmento como
// "github.get_*" caem de volta para uma correspondência exata e não expandem.
{
  "default_verdict": "deny",
  "rules": [
    { "tool_name_glob": "github.create_issue", "verdict": "allow" },
    { "tool_name_glob": "github.get_issue",    "verdict": "allow" }
  ]
}
Agora github.create_issue roda, github.get_issue roda, e um github.delete_repo recém-introduzido é negado até que você o tenha revisado e permitido. Um tools/call negado volta ao modelo como um erro de ferramenta (firewall deny: …) — o agente se adapta em vez de quebrar. Veja Lista de permissão de ferramentas MCP para a receita completa, e Regras de firewall para o DSL de matching.

​
4. Criptografe a credencial — nunca improvise a auth

Um servidor de terceiros quase sempre precisa de uma credencial, e uma credencial é a coisa que você menos quer parada em texto puro ou chegando ao modelo. Registre a auth do servidor através do OrcaRouter de modo que ela seja criptografada em repouso, mascarada na leitura e injetada apenas no momento do dispatch. auth_mode é um de none, bearer, oauth ou basic: 
# Rota de console, UserAuth, Developer+.
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}"
  }'
A credencial é criptografada e mascarada no momento em que é armazenada — ela nunca chega ao modelo ou ao cliente, e na leitura você só vê a máscara. Em uma atualização, ecoe a máscara de volta para manter o valor armazenado; envie um auth_json novo apenas quando estiver rotacionando. Veja Autenticar e Rotação de credenciais.

​
5. Restrinja egress: onde as ferramentas dele podem alcançar?

Os vereditos por chamada decidem qual ferramenta roda; o egress decide onde ela pode alcançar. Uma ferramenta que “retorna dados” e uma ferramenta que “exfiltra seus segredos para o host de um atacante” podem ser a mesma ferramenta com um argumento diferente — o controle de egress é o que as distingue. O gateway já valida cada endpoint remoto e seu IP de discagem resolvido contra uma política de SSRF em cada hop, recusando ranges de intranet e o endereço de metadados de nuvem e reverificando o IP para derrotar DNS rebinding. Em cima disso, escreva sua própria regra de deny de egress para os hosts e CIDRs que este servidor nunca deveria tocar: 
// Uma regra de stage egress escopa seu veredito ao destino outbound.
// egress_json carrega listas de allow + deny de host/CIDR.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\"]}"
}
Não há preset que entregue regras de CIDR para você — você mesmo escreve a lista de deny de host/CIDR, escopada ao que este servidor legitimamente precisa. Veja Limites de egress e Exfiltração de dados.

​
6. Coloque em quarentena o que o agente instala por conta própria

O servidor que você registrou é um risco; as skills, servidores MCP BYO e plugins que um agente auto-instala depois são outro. O OrcaRouter escaneia cada capacidade instalável, atribui a ela uma faixa de risco e deriva um modo de enforcement — allow, quarantine ou block — que se sobrepõe a cada veredito de regra. Qualquer coisa auto-detectada no primeiro uso é colocada em quarentena até que um humano a revise: uma capacidade que ninguém aprovou não ganha um passe livre só porque escaneou benigna. Uma capacidade quarantine escala qualquer coisa aquém de um deny para pending_approval, de modo que suas ferramentas só rodam depois que você olhou.
Não tente registrar cada skill à mão. Pré-aprove as que você confia e deixe o resto ser auto-detectado e colocado em quarentena — depois revise a partir de dados reais. O modo aperta mais em uma re-varredura, nunca afrouxa. Veja Firewall: skills e Envenenamento de ferramentas MCP.

​
7. Shadow primeiro, depois observe o rastro

Não vire um servidor novo direto para enforcing. Coloque a política em shadow mode — os vereditos enforcing são rebaixados para audit e registrados como [shadow] would … — de modo que você possa ver o que teria sido bloqueado antes que de fato seja. Quando a trilha de auditoria parecer certa, retire o shadow mode e aplique o enforcement. Depois que está ativo, os controles continuam observando:
Cada chamada governada registra seu veredito, superfície e regra correspondente. Leia-os para confirmar que a lista de permissão e as regras de egress se comportam como pretendido. Veja Auditar eventos de MCP.
Picos de taxa e custo contra uma baseline aprendida, mais loops de retry e caminhos de ferramenta novos, aparecem como anomalias — legíveis por qualquer Member.
Ligue o modo observe para registrar como lacunas as chamadas que uma política ainda não cobre, de modo que você aperte a partir do que um agente de fato faz, não de palpites.

​
8. O caminho rápido: escolha um nível de autonomia

Se você prefere não construir à mão os passos 3–5 para um servidor em que não confia totalmente, aplique um nível de autonomia e edite a partir dali. Os níveis escrevem linhas de política e guardrail reais e editáveis — eles são um ponto de partida, não uma caixa-preta:
NívelO que ele define
permissiveModo observe ligado — registra tudo, não aplica enforcement de nada.
balancedPolítica default-audit que nega shell destrutivo, mais o guardrail PII Shield em modo apenas-flag.
tightPolítica default-deny negando shell destrutivo e ferramentas com formato de fetch (http_fetch/web_search/fetch_url/request — o vetor de SSRF), mais os guardrails PII Shield e Secrets Blocker aplicados. Segredos em argumentos são pegos pelo guardrail Secrets Blocker na requisição, não por uma regra de tool-arg.
Para um servidor de terceiros que você ainda está avaliando, comece em tight, faça probe, depois relaxe ferramentas específicas para uma lista de permissão. O undo de um clique restaura o snapshot pré-aplicação.
As leituras de configurações, políticas, ferramentas descobertas, anomalias, servidores MCP registrados e skills são abertas a qualquer Member; leituras de event, run e aggregate exigem Developer+, e cada escrita exige Developer+. Revelar a chave em texto puro de um token também é Developer+.

​
9. Para onde ir em seguida

Conectar um servidor MCP

Registre, faça probe e exponha um servidor através do gateway.

Lista de permissão de ferramentas MCP

Negue por padrão um servidor e permita apenas ferramentas revisadas.

Defesa contra rug-pull

Pegue um servidor ou skill que muda depois de você aprová-lo.

Visão geral de segurança de MCP

O mapa completo da superfície de governança de MCP.
Novo no modelo? Leia Guardrails vs. firewall para onde a governança de MCP se encaixa, depois Agência excessiva e Chamadas de ferramenta perigosas para as ameaças que este checklist fecha.