Firewall: Servidores MCP

O Model Context Protocol (MCP) permite que agentes chamem ferramentas hospedadas por servidores externos. Isso é poderoso e perigoso em igual medida: cada servidor MCP ao qual um agente se conecta é um novo conjunto de ferramentas, credenciais e alcance de rede que ninguém revisou. O gateway MCP do Firewall coloca um único ponto de estrangulamento auditado na frente de todos eles. Você registra cada servidor MCP uma vez; o gateway expõe suas ferramentas aos seus agentes sob uma conexão e roda cada tools/call através do motor do firewall antes que chegue ao servidor real.

1. O que a governança de MCP oferece

Um gateway, todos os servidores. Seu agente se conecta a um endpoint. O gateway agrega as ferramentas de cada servidor registrado alcançável, com namespace <server>.<tool>, de modo que github.create_issue e shell.exec aparecem lado a lado sob uma única conexão MCP.
Política em cada chamada. Cada tools/call é avaliado primeiro pela sua política. Uma chamada bloqueada volta ao modelo como um erro de ferramenta (firewall deny: …), não uma falha de transporte, de modo que o agente pode reagir em vez de quebrar. sanitize reescreve os argumentos antes de encaminhar; pending_approval retém a chamada.
Protegido contra SSRF. Endpoints remotos são validados contra a política de SSRF do gateway — ranges de intranet e endereços de metadados de nuvem são bloqueados, e o IP de discagem resolvido é reverificado para derrotar DNS rebinding, em cada hop incluindo redirects.
Credenciais criptografadas. Os segredos de auth do servidor são criptografados em repouso e mascarados na leitura. O gateway os injeta no momento do dispatch; eles nunca chegam ao modelo ou ao cliente.

2. Dois tipos de servidor

Tipo	`endpoint`	Comportamento
BYO (bring-your-own)	Uma URL streamable-HTTP	O gateway faz proxy do `tools/call` para o seu servidor MCP remoto.
Empacotado	vazio	O servidor MCP in-process do OrcaRouter. Registrado para que seja visível e governável; não probeável separadamente.

3. Registrando um servidor

Um registro de servidor carrega:

Campo	Notas
`name`	Chave de negócio, única por workspace, ≤ 128 chars. Sem `.` — é o separador de namespace `<server>.<tool>`.
`endpoint`	A URL do servidor MCP (≤ 512 chars). Vazio para o servidor empacotado.
`auth_mode`	`none` (padrão), `bearer`, `oauth` ou `basic`.
`auth_json`	Credenciais específicas do modo (veja abaixo). Obrigatório sempre que `auth_mode` não for `none`.
`enabled`	Padrão `true`. Um servidor desabilitado é omitido inteiramente do gateway.
`status`	Alcançabilidade — `ok` (padrão), `degraded` ou `down`. Definido por probing.

Formatos de credencial por modo:

// bearer
{ "token": "ghp_…" }
// oauth
{ "client_id": "…", "client_secret": "…", "token_url": "…" }
// basic
{ "username": "…", "password": "…" }
// none
""

Uma requisição de registro se parece com:

curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'

Um nome duplicado no mesmo workspace retorna HTTP 409 (o mesmo nome em um workspace diferente é aceitável).

Os segredos nunca são armazenados em texto puro. O auth_json é criptografado em repouso com uma chave de segredos do workspace. Se essa chave não estiver configurada, a escrita é rejeitada em vez de persistir uma credencial não criptografada. Na leitura, os segredos e o endpoint são mascarados; ecoe a máscara de volta em uma atualização para manter o valor armazenado. Alternar entre dois modos de auth com credencial exige um auth_json novo (o ciphertext é vinculado em formato ao seu modo).

4. Probe — descubra suas ferramentas

Antes de poder escrever regras contra as ferramentas de um servidor, você precisa saber seus nomes. Probe o servidor:

curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer sk-orca-..."

O gateway roda um initialize + tools/list MCP contra o endpoint (usando as credenciais descriptografadas, limitado a 10s), registra a alcançabilidade status e um timestamp, e retorna as ferramentas anunciadas com seus schemas de input:

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": { } }
  ]
}

Agora você pode criar regras como tool_name_glob: github.* sabendo exatamente o que github.create_issue aceita. O servidor empacotado (endpoint vazio) não é probeável e retorna um 400.

5. Ciclo de vida & enforcement

Habilitado vs. desabilitado. Um servidor desabilitado é removido do registro de runtime — suas ferramentas desaparecem do gateway e suas credenciais nunca são descriptografadas. É o interruptor de desligar.
Alcançabilidade. O status (ok / degraded / down) reflete o último probe; um servidor inalcançável é pulado quando o gateway monta seu conjunto de ferramentas.
Veredito por chamada. No dispatch, o motor retorna um veredito para a chamada <server>.<tool> específica com seus argumentos:
- allow / audit → encaminhado (audit registra, ainda permite).
- sanitize → encaminhado com argumentos reescritos.
- deny / pending_approval / qualquer coisa desconhecida → bloqueado como um erro de ferramenta. (Através do gateway unificado, uma chamada retida aparece como um erro permanente em vez de encaminhar o id de aprovação — use o hook de avaliação quando você precisar do handshake de aprovação.)
A exclusão é um soft delete; o slot de nome é liberado imediatamente para que você possa re-registrar sob o mesmo nome.

Cada mudança invalida o cache de ferramentas por workspace do gateway imediatamente, de modo que um servidor recém-registrado, desabilitado ou re-probeado entra em vigor na próxima conexão em vez de após um TTL de cache.

6. Conectando um cliente

Aponte qualquer cliente MCP para o endpoint do gateway com um token com escopo de firewall-gateway:

https://api.orcarouter.ai/api/v1/firewall/mcp

O gateway fala streamable HTTP (mensagens POST, GET para o stream SSE, DELETE para encerrar uma sessão) e se identifica como orcarouter-firewall-gateway. Ele anuncia as ferramentas de cada servidor habilitado e alcançável sob o namespace <server>.<tool>, re-expondo o schema de input de cada ferramenta verbatim. Um token sem o escopo de firewall-gateway recebe 403 — cunhe um token de gateway dedicado para isso.

API reference

Console (escopo de workspace, RBAC)

Método & path	Papel	Propósito
`GET /api/workspace/firewall/mcp_servers`	Member	Lista servidores (segredos mascarados, endpoint redigido).
`GET /api/workspace/firewall/mcp_servers/:id`	Member	Servidor único, mascarado.
`POST /api/workspace/firewall/mcp_servers`	Developer+	Registra um servidor (409 em nome duplicado).
`PUT /api/workspace/firewall/mcp_servers`	Developer+	Atualiza um servidor (id no corpo).
`DELETE /api/workspace/firewall/mcp_servers/:id`	Developer+	Soft-delete; libera o nome.
`POST /api/workspace/firewall/mcp_servers/:id/probe`	Developer+	Probe de alcançabilidade + descoberta de ferramentas.

Gateway (token com escopo de firewall-gateway)

Método & path	Propósito
`ANY /api/v1/firewall/mcp`	O endpoint unificado de dispatch do gateway MCP.
`GET /api/v1/firewall/mcp_servers`	Registro de runtime (auth descriptografada, apenas servidores habilitados) para um proxy de SDK.
`POST /api/v1/firewall/evaluate`	Avalia um único `tools/call` antes de despachá-lo você mesmo.

FAQ

Por que rotear MCP através do OrcaRouter afinal?

Para que haja um lugar que veja cada chamada de ferramenta. Sem um gateway, cada agente se conecta a cada servidor MCP diretamente — sem política compartilhada, sem trilha de auditoria, sem proteção contra SSRF, e credenciais espalhadas pelas configs dos agentes. O gateway centraliza tudo isso: uma conexão, uma política, um log auditado, segredos criptografados injetados no dispatch.

O que acontece quando uma chamada MCP bloqueada volta?

O modelo a recebe como um erro de ferramenta (firewall deny: <reason>), o mesmo formato que receberia de qualquer ferramenta que falha. Isso permite que o agente se adapte — tentar uma abordagem diferente, perguntar ao usuário, ou parar — em vez de tratá-la como um crash de transporte.

Posso governar a mesma ferramenta de forma diferente por servidor?

Sim — é para isso que serve o namespace <server>.<tool>. Uma regra com tool_name_glob: trusted.* pode dar allow enquanto community.* é auditado ou pending_approval. Combine-a com um glob de nome de skill para um escopo ainda mais fino.

O gateway protege contra SSRF?

Sim. As URLs de endpoint e seus IPs de discagem resolvidos são validados contra a política de SSRF no registro e em cada hop de dispatch — ranges de intranet e o endereço de metadados de nuvem são recusados, e o IP resolvido é reverificado para derrotar DNS rebinding. Combine-o com uma regra de egress para governar onde as ferramentas podem alcançar.

Veja também

Aprofundando-se em segurança de agentes? Os guias Proteja seus agentes (Zero Trust) colocam este recurso em um fluxo de trabalho zero-trust.

Proteja servidores MCP (Zero Trust)

Conecte, autentique e governe servidores MCP sob uma postura zero-trust.

Checklist de confiança MCP

O que verificar antes de confiar em um servidor MCP de terceiros.

​1. O que a governança de MCP oferece

​2. Dois tipos de servidor

​3. Registrando um servidor

​4. Probe — descubra suas ferramentas

​5. Ciclo de vida & enforcement

​6. Conectando um cliente

​API reference

​Console (escopo de workspace, RBAC)

​Gateway (token com escopo de firewall-gateway)

​FAQ

​Veja também