Saltar para o conteúdo principal
Um agente MCP é um agente com alcance. Cada servidor Model Context Protocol ao qual ele se conecta é um novo conjunto de ferramentas, credenciais e destinos de rede que ninguém revisou — e o agente pode puxar um novo no meio de uma run. Esta receita mostra os quatro movimentos que transformam um setup MCP espalhado em um governado no gateway hospedado: um único gateway MCP auditado, quarentena de skill, negação de egress e auth de servidor criptografada. Você configura tudo isso a partir do console (ou da API REST) contra o seu workspace. Seu agente continua falando MCP exatamente como antes.

​
1. Por que proteger um agente MCP

Aponte um agente para cinco servidores MCP diretamente e você tem cinco fronteiras de confiança, cinco repositórios de credenciais e zero trilha de auditoria compartilhada. O tools/call que lê um registro de cliente e aquele que roda um comando de shell parecem idênticos para o modelo, e um servidor da comunidade pode silenciosamente requisitar shell.exec e um escopo de rede externo na primeira vez que carrega. A correção é tornar o OrcaRouter o único ponto de estrangulamento que cada chamada cruza. Para proteger o tráfego de agente MCP de ponta a ponta você roteia todo o dispatch MCP através do gateway MCP do Firewall, de modo que cada tools/call é avaliado por política antes de chegar ao servidor real — com skills pontuadas por risco, egress governado e credenciais criptografadas em repouso.
Esta é uma receita — ela costura recursos existentes em um passe concreto de endurecimento. Para a referência completa, siga os links para Firewall, Servidores MCP e Skills.

​
2. Comece pela linha de base de Agentes Seguros

Antes de criar qualquer coisa sob medida, defina uma postura. No console abra Firewall → Posture e aplique o nível de autonomia balanced (papel Developer). Em uma transação ele audita chamadas de ferramenta e sinaliza PII enquanto nega as ações mais destrutivas — você observa antes de aplicar enforcement amplamente, com desfazer em um clique. Quando os feeds de Events e Runs parecerem certos, mude para tight: default-deny, shell destrutivo negado, egress no formato de SSRF negado, mais os guardrails PII Shield e Secrets Blocker aplicados. Esse único interruptor é o piso sobre o qual esta receita constrói.
Prefere subir gradualmente sem virar o workspace inteiro? Crie as regras abaixo em uma política nomeada e ligue seu shadow mode — ela avalia e registra mas rebaixa todo veredito de enforcement para audit (motivo prefixado [shadow] would …) até você ter certeza. Veja modos de enforcement.

​
3. Roteie cada tools/call através de um gateway MCP

Registre cada servidor MCP uma vez; o gateway agrega suas ferramentas sob uma única conexão (com namespace <server>.<tool>) e roda cada tools/call através do motor de firewall. Registre um servidor a partir do console (ou da API REST, Developer+): 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-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 aponte seu cliente MCP para o gateway — não para os servidores upstream — usando uma chave dedicada com escopo de firewall-gateway: 
https://api.orcarouter.ai/api/v1/firewall/mcp
Agora github.create_issue e shell.exec aparecem lado a lado sob uma conexão, e cada dispatch é avaliado antes de rodar. Uma chamada bloqueada volta para o modelo como um erro de ferramenta (firewall deny: …), não uma falha de transporte, então o agente pode se adaptar.
Uma chave de relay normal recebe 403 na rota de gateway /api/v1/firewall/mcp. Cunhe um token de gateway dedicado (is_firewall_gateway) para a conexão MCP; ler o texto plano dessa chave de gateway exige Admin+.
Antes de poder escrever regras contra as ferramentas de um servidor, sonde-o para descobrir seus nomes e schemas: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"

​
4. Quarentene as skills que o agente puxa

O gateway MCP governa chamadas; a governança de skill governa as capacidades que um agente carrega. Cada skill instalável, servidor MCP próprio ou plugin é escaneado em uma faixa de risco e um modo de enforcement que anda por cima de todo veredito de regra:
ModoEfeito em tempo de execução
allowOs vereditos de regra decidem; a skill não adiciona nada.
quarantineQualquer coisa aquém de deny é retida para pending_approval.
blockAs ferramentas da skill são negadas à força.
O ponto para um agente MCP: uma capacidade que ninguém aprovou não recebe passe livre. Quando um agente autoinstala algo e suas ferramentas cruzam o gateway pela primeira vez, o Firewall a auto-detecta e a quarentena até que um humano a revise — mesmo que ela tenha sido escaneada limpa. Pré-aprove os servidores em que você confia; deixe o resto cair na fila de revisão.
Mantenha balanced/observe ligado enquanto você aprende o que seu agente realmente instala, depois promova as skills confiáveis para allow e deixe a cauda longa em quarentena. Veja Skills.

​
5. Negue egress no formato de SSRF

Uma ferramenta MCP comprometida ou confusa alcançando cloud-metadata ou um host de intranet é o caminho clássico de exfiltração. Duas camadas o cobrem. Primeiro, o gateway valida cada endpoint MCP remoto e seu IP de discagem resolvido contra uma política de SSRF no registro e em cada hop de dispatch — ranges de intranet e o endereço de cloud-metadata são recusados, re-verificados para derrotar DNS rebinding. Isso é embutido; você não configura. Segundo, o nível de autonomia tight entrega um preset de egress de SSRF que nega nomes de ferramenta no formato de fetch — http_fetch, web_search, fetch_url, request e suas formas com namespace <server>.* — então uma ferramenta cujo trabalho inteiro é “vá buscar esta URL” é parada antes de discar. Para governar onde as ferramentas podem alcançar por destino, crie sua própria regra de egress com uma deny list de host/CIDR — essa é a superfície para fixar o alcance outbound: 
// firewall rule, egress stage — deny outbound to an internal range.
// egress_json is a JSON *string*: {"deny":[…],"allow":[…]} of hosts/CIDRs.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\",\"169.254.169.254\"]}"
}
Nenhum preset entrega regras de egress de CIDR — o preset de SSRF corresponde a nomes de ferramenta, não a destinos. Você mesmo cria a deny list de host/CIDR quando precisar de controle em nível de destino. Veja listas de egress e pare a exfiltração.

​
6. Mantenha as credenciais de servidor criptografadas

O auth_json de cada servidor MCP é criptografado em repouso e mascarado na leitura; o gateway injeta as credenciais no momento do dispatch, então elas nunca chegam ao modelo ou ao cliente. Valores de auth_mode suportados:
{ "token": "…" } — um bearer token estático, enviado como Authorization: Bearer.
{ "client_id": "…", "client_secret": "…", "token_url": "…" } — OAuth de client-credentials; o gateway busca e atualiza o token.
{ "username": "…", "password": "…" } — autenticação HTTP Basic.
"" — um servidor não autenticado. O padrão.
Na leitura o segredo é mascarado; ecoe a máscara de volta no update para manter o valor armazenado. O status do servidor (ok / degraded / down) da última sonda diz se ele é alcançável antes que você dependa dele.

​
7. Adicione um guardrail de conteúdo na requisição

O Firewall governa ações; emparelhe-o com um Guardrail para que o texto que se move através do seu agente MCP também seja filtrado. O preset Secrets Blocker captura credenciais em uma requisição antes que o modelo — ou qualquer ferramenta — as veja, e um PII Shield mascara identificadores na entrada. Ambos vêm ligados com o nível de autonomia tight, ou vincule um guardrail nomeado à chave de relay do agente via guardrail_id.
O veredito sanitize do firewall redige os argumentos da chamada de ferramenta, nunca o conteúdo que uma ferramenta retorna. Remova segredos da requisição com o guardrail Secrets Blocker; sanitize os argumentos que um agente emite com uma regra de firewall. Eles cobrem metades diferentes do fluxo.

​
8. Verifique e observe

Confirme que a política faz o que você espera antes de confiar nela, depois fique de olho nos feeds:

Teste uma chamada de ferramenta

Faça um dry-run de um tools/call de amostra contra sua política e veja o veredito, a regra correspondente e o motivo — nada despachado, nada registrado.

Ferramentas descobertas

Cada ferramenta que o workspace viu, marcada covered ou gap — crie regras direto do tráfego MCP real.

Events & Runs

Cada dispatch, seu veredito e a superfície que ele atingiu, consolidado por run de agente.

Feed de anomalias

Picos de taxa/custo, loops de retry e caminhos de ferramenta inéditos contra uma baseline aprendida.

​
9. Para onde ir a seguir

Envenenamento de ferramenta MCP

O modelo de ameaças por trás da quarentena e do gateway MCP.

Agência excessiva

Por que default-deny e HITL importam para uso autônomo de ferramentas.

Receita de agente autônomo

Endureça um agente de alta autonomia de ponta a ponta.

Pare a exfiltração

Restrinja o egress outbound em profundidade.