Saltar para o conteúdo principal
Um agente que fala o Model Context Protocol (MCP) é tão seguro quanto os servidores aos quais se conecta. Cada servidor MCP é um novo conjunto de ferramentas, uma nova credencial e um novo alcance de rede — e no momento em que um agente disca um diretamente, ninguém está observando a chamada. Esse é todo o problema que a mcp security precisa resolver: não “esta única ferramenta é segura” mas “quem governa todas elas, em cada chamada, com uma única trilha de auditoria.” A resposta do OrcaRouter é um único ponto de estrangulamento auditado. Você registra cada servidor MCP uma vez; os agentes se conectam a um gateway; e cada tools/call roda através do motor do firewall antes de chegar ao servidor real. Esta página é o mapa dessa superfície — o gateway, o veredito por chamada, a governança de skills, o egress e as credenciais criptografadas — com links para o how-to focado de cada um.
Cada ação de gerenciamento aqui é configurada a partir do console (ou da API REST com seu session/access token) e é gated por papel. Apenas as chamadas de relay /v1/* e as rotas do gateway do firewall carregam uma chave no estilo sk-orca-....

​
1. Por que a mcp security precisa de um gateway

Aponte dez agentes para cinco servidores MCP da comunidade diretamente e você obtém o pior de todos os mundos: nenhuma política compartilhada, nenhuma trilha de auditoria, credenciais copiadas para dez configs de agentes, e uma ferramenta chamada shell.exec a um redirect de distância do seu endpoint de metadados de nuvem. O gateway colapsa isso em uma única conexão governada.

Uma conexão, todos os servidores

Os agentes se conectam a um único endpoint. O gateway agrega as ferramentas de cada servidor habilitado e alcançável sob um namespace <server>.<tool>.

Política em cada chamada

Cada tools/call é avaliado pela sua política de firewall antes do dispatch.

Credenciais criptografadas

Os segredos de auth do servidor são criptografados em repouso, mascarados na leitura e injetados no dispatch — eles nunca chegam ao modelo ou ao cliente.

Egress sob controle

O endpoint de um servidor registrado é validado por padrão contra ranges de IP privados e de metadados de nuvem. Para destinos por ferramenta, aplique a denylist de egress SSRF de linha de base ou crie suas próprias regras de host/CIDR.
Para os fundamentos por trás de tudo isso, veja Segurança de agentes de IA e Por que zero trust.

​
2. Os quatro blocos de construção

A governança de MCP no OrcaRouter são quatro peças cooperando. Escolha aquela que corresponde à pergunta que você está tentando responder.
Um único endpoint ao qual seus agentes se conectam em vez de discar servidores diretamente. Ele agrega as ferramentas de cada servidor registrado, com namespace <server>.<tool>, e re-expõe o schema de input de cada ferramenta verbatim. Comece em Conectar um servidor MCP e Autenticar; a referência completa fica em Firewall: Servidores MCP.
O gateway roda cada tools/call através do firewall na superfície mcp e retorna um veredito — allow, audit, deny, sanitize ou pending_approval — antes do dispatch. Veja Lista de permissão de ferramentas MCP e Sanitize de argumentos de ferramenta.
Capacidades que um agente auto-instala — skills, servidores MCP BYO, plugins — são escaneadas, recebem uma faixa de risco e um modo de enforcement (allow / quarantine / block) que monta sobre cada veredito de regra. Veja Firewall: skills e Defesa contra rug-pull.
O segredo de auth de cada servidor é criptografado em repouso e mascarado na leitura. Veja Autenticar e Rotação de credenciais.

​
3. Como um tools/call é avaliado

Quando um agente chama uma ferramenta através do gateway, a chamada não vai direto ao servidor. Ela é correspondida contra a política do seu workspace, o modo de enforcement da skill proprietária é aplicado por cima, e apenas um veredito allow / audit / sanitize chega ao servidor real.
VereditoO que o agente vê
allow / auditEncaminhado. audit também registra um evento.
sanitizeEncaminhado com os argumentos redigidos (nunca o resultado).
deny / pending_approvalRetornado como um erro de ferramenta, de modo que o agente pode se adaptar em vez de quebrar.
Uma chamada MCP bloqueada volta como um erro de ferramenta (firewall deny: …), o mesmo formato que qualquer ferramenta que falha retorna — o agente pode tentar de forma diferente, perguntar ao usuário ou parar. Não é um crash de transporte.
O vocabulário de vereditos, as superfícies e a correspondência de regras estão documentados por completo em Firewall e Regras do firewall; o modelo conceitual está em Modos de enforcement e Como o OrcaRouter inspeciona.

​
4. Registrar um servidor (um exemplo concreto)

Você registra cada servidor uma vez. Um registro de servidor carrega um name (único por workspace, sem .), um endpoint, um auth_mode (none / bearer / oauth / basic) e suas credenciais criptografadas. Faça isso a partir do console — a escrita exige Developer+. 
# Rota de console, chamada com seu session/access token (UserAuth).
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\"}",
    "enabled": true
  }'
Depois faça probe dele para descobrir suas ferramentas e registrar a alcançabilidade (ok / degraded / down): 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Agora você pode criar regras contra github.* sabendo exatamente o que github.create_issue aceita. O passo a passo de ponta a ponta fica em Conectar um servidor MCP.
Os segredos nunca são armazenados em texto puro. O auth_json é criptografado em repouso e mascarado na leitura; em uma atualização, ecoe a máscara de volta para manter o valor armazenado. Veja Rotação de credenciais.

​
5. Conectar um agente ao gateway

Uma vez que os servidores estejam registrados, aponte qualquer cliente MCP para o gateway com uma chave com escopo de firewall-gateway (um token sem esse escopo recebe 403): 
https://api.orcarouter.ai/api/v1/firewall/mcp
O gateway fala streamable HTTP e anuncia as ferramentas de cada servidor habilitado e alcançável sob o namespace <server>.<tool>. Um SDK que faz proxy das chamadas ele mesmo pode ler o registro de runtime de GET /api/v1/firewall/mcp_servers com o mesmo token de gateway.

​
6. Restrinja o que as ferramentas podem alcançar

Os vereditos por chamada governam qual ferramenta roda; os controles de egress governam onde ela pode alcançar. Duas camadas cooperam. Primeiro, quando o gateway se conecta ao endpoint de um servidor registrado, essa URL é validada por padrão contra ranges privados (RFC1918), de loopback, link-local e de metadados de nuvem — e o host é resolvido por DNS de modo que um nome que resolve para um range bloqueado também é recusado. Então um servidor BYO apontado para 169.254.169.254 ou um endereço de intranet é rejeitado, a menos que você o tenha explicitamente colocado na whitelist. Segundo, para destinos por ferramenta, uma regra de egress carrega uma lista de allow/deny de host/CIDR correspondida contra o destino outbound da chamada na superfície egress. O template de caso de uso de linha de base inclui uma regra de deny de egress pronta cuja lista já cobre os ranges privados, de loopback, link-local e de metadados de nuvem (incluindo 169.254.169.254 e metadata.google.internal), então aplicá-la te dá defesa contra SSRF/metadados sem criar CIDRs à mão.
SSRF e egress são a diferença entre “esta ferramenta retornou dados” e “esta ferramenta exfiltrou seus segredos para o host de um atacante”. Aplique a denylist de egress de linha de base e adicione suas próprias regras de host/CIDR — veja Limites de egress e Exfiltração de dados.

​
7. Observe: eventos, runs e anomalias

Cada chamada governada deixa um rastro. Os eventos de firewall registram o veredito, a superfície e a regra correspondida; as runs agrupam as chamadas de uma sessão; e o feed de anomalias sinaliza picos de taxa e custo contra uma baseline aprendida. Leituras de configurações, políticas e ferramentas descobertas estão abertas a qualquer Member; leituras de evento/run/agregado exigem Developer+.

​
8. Para onde ir a seguir

Conectar um servidor MCP

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

Lista de permissão de ferramentas MCP

Default-deny um servidor e permita apenas as ferramentas que você revisou.

Defesa contra rug-pull

Governe servidores e skills que mudam depois que você os aprovou.

Firewall: Servidores MCP

A referência completa de campos e rotas.
Novo no modelo? Leia Guardrails vs. firewall para ver onde a governança de MCP se encaixa, depois Envenenamento de ferramentas MCP e Agência excessiva para as ameaças que ela fecha.