Saltar para o conteúdo principal
Um servidor MCP que você conecta vem com ferramentas que alcançam a rede — um fetch, um web_search, um poster de webhook. O nome da ferramenta pode estar na sua lista de permissão, os argumentos podem parecer limpos, e a chamada ainda acaba postando seus dados para um host controlado por um atacante ou puxando credenciais do endpoint de metadados 169.254.169.254. O destino é a parte da chamada que suas regras de nome de ferramenta nunca veem. O controle de egress de mcp fecha essa lacuna. Uma regra de egress escopa um veredito de firewall para onde uma ferramenta alcança — um host, um IP ou um range CIDR — de modo que o mesmo http_fetch que tem permissão para api.openai.com é negado para todo o resto. Ele roda na superfície egress do firewall, em cima da avaliação por chamada pela qual cada tools/call já passa.
Esta é uma tarefa de console. As regras de firewall vivem nas rotas /api/workspace/firewall/*, que autenticam com o seu token de sessão/acesso — não uma chave de relay sk-orca-…. Escrever uma regra exige o papel Developer+.

​
1. O que uma regra de egress controla

Uma regra normal corresponde ao nome da ferramenta e aos seus argumentos. Uma regra de egress adiciona uma terceira dimensão: o destino para o qual a chamada resolve. Você define o stage da regra como egress e anexa uma lista egress_json de entradas de allow / deny. O motor extrai o host de destino da chamada e só dispara a regra quando esse host está em escopo. As entradas são comparadas de três formas:

Hostname

Correspondência exata insensível a maiúsculas/minúsculas, ex.: api.openai.com. Um ponto final é aparado em ambos os lados.

Literal de IP

Correspondência exata contra o IP de discagem resolvido, ex.: 169.254.169.254.

Range CIDR

O IP de destino — literal ou resolvido por DNS — deve cair dentro do bloco, ex.: 10.0.0.0/8.
Quando um destino é um hostname mas sua lista carrega entradas de IP/CIDR, o nome é resolvido e seus IPs são reverificados — de modo que metadata.internal corresponde a um deny 169.254.0.0/16 mesmo não estando listado por nome. Isso é defesa-em-profundidade best-effort contra um nome que resolve para um range negado; o guard de SSRF autoritativo ainda roda na camada de discagem do gateway.

​
2. Um exemplo concreto

Negue cada ferramenta com formato de fetch de alcançar o endpoint de metadados de nuvem e os ranges RFC-1918. Este é o corte canônico da perna de exfil de SSRF: um veredito deny no stage egress, escopado por uma denylist egress_json. 
curl https://api.orcarouter.ai/api/workspace/firewall/rules \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_id": 12,
    "priority": 10,
    "label": "Deny SSRF / metadata egress",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny",
    "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"]}"
  }'
Um tools/call cujo destino resolve para qualquer um desses ranges volta ao modelo como um erro de ferramenta; uma chamada a um host público que a denylist não cobre passa adiante.
As listas de allow/deny invertem de significado com o veredito. Em uma regra deny (ou outra enforcing), a lista deny é o conjunto em escopo e allow recorta exceções — “negue estes, exceto aqueles.” Em uma regra allow os papéis se invertem: a lista allow é o conjunto em escopo e deny recorta exceções — “permita apenas estes.” Um egress_json não vazio deve declarar pelo menos uma entrada allow ou deny, ou a escrita é rejeitada.

​
3. Permitir apenas um destino

O inverso do exemplo acima: fixe uma ferramenta de fetch em um único host sancionado e deixe o default_verdict da política (ou um catch-all posterior) lidar com o resto. Como este é um veredito allow, a lista allow é o conjunto em escopo. 
// egress_json em uma regra de veredito allow, stage=egress
{ "allow": ["api.openai.com", "api.anthropic.com"] }
A regra agora dispara (permite) apenas quando o destino é um desses dois hosts. Qualquer outra coisa cai para a próxima regra — combine isso com uma política default-deny para que um destino não listado seja recusado em vez de ser deixado passar.
Teste antes de confiar. A aba Test do console e o endpoint POST /api/workspace/firewall/test (Developer+) reproduzem uma chamada de amostra contra a sua política rascunho para que você possa confirmar o veredito em um destino conhecido sem enviar tráfego ao vivo.

​
4. Como ela se compõe com o resto do firewall

Uma regra de egress é uma regra entre muitas em uma política de firewall de workspace. O motor percorre as regras em ordem de prioridade (a menor primeiro) e a primeira correspondência vence, então coloque um deny de egress apertado acima de qualquer allow amplo.
Veredito em uma regra de egressEfeito
denyBloqueia a chamada para destinos em escopo — registrado na superfície egress e retornado à ferramenta como um erro.
auditRegistra a chamada correspondente como um evento de firewall; ainda despacha.
allowPermite destinos em escopo; combina com um piso default-deny.
pending_approval e cap_cost não são aplicados na superfície egress — egress é uma verificação de destino, não uma retenção ou um teto de gasto. Use esses vereditos nas superfícies mcp ou inbound em vez disso. Veja a referência de vereditos.
Dois controles relacionados valem ser ligados junto com uma regra de egress:
Independentemente de qualquer regra que você escreva, o gateway MCP valida cada endpoint de servidor e seu IP de discagem resolvido contra uma política de SSRF — ranges de intranet e o endereço de metadados de nuvem são recusados, e o IP é reverificado em cada hop para derrotar DNS rebinding. Sua regra de egress camada uma política de destino específica do workspace em cima dessa baseline.
Um único deny de egress impede uma ferramenta de alcançar um host. Uma regra de sequência impede a cadeia — ex.: “leia um arquivo, depois egress dentro da janela” — sinalizando a perna de egress apenas quando ela segue uma leitura sensível. Esse é o quebrador da trifecta letal; o escopo de egress é o controle por chamada.

​
5. Faça shadow primeiro, depois enforce

Levar um deny de egress direto para enforcement em um workspace movimentado corre o risco de quebrar uma integração legítima que você esqueceu. Duas redes de segurança:
  • Shadow mode. Uma política em shadow mode rebaixa cada veredito enforcing para audit — seu deny de egress registra [shadow] would deny … em vez de bloquear, de modo que você vê o raio de impacto antes que ele morda.
  • Observe mode. A configuração de workspace firewall_observe_mode registra chamadas não cobertas como Ferramentas Descobertas, expondo os destinos reais que seus agentes já alcançam para que você possa escrever uma lista de permissão precisa a partir de dados em vez de adivinhação.
A correspondência de destino de egress se baseia no host para o qual a chamada resolve no momento da avaliação. Um servidor hostil ainda pode fazer rebind de DNS entre a verificação da política e a discagem real (TOCTOU) — que é exatamente por que o guard de IP na camada de socket do gateway é o controle autoritativo e esta regra é defesa-em-profundidade, não a única linha.

​
6. Papéis e rotas

Todas as rotas de console têm escopo de workspace e autenticam com o seu token de sessão/acesso. As leituras são abertas a qualquer Member; escrever ou editar uma regra exige Developer+.
Método & pathPapelPropósito
GET /api/workspace/firewall/policies/:idMemberLer uma política e suas regras.
POST /api/workspace/firewall/rulesDeveloper+Adicionar uma regra (defina stage: egress).
PUT /api/workspace/firewall/rulesDeveloper+Atualizar uma regra (id no corpo).
DELETE /api/workspace/firewall/rules/:idDeveloper+Remover uma regra.
POST /api/workspace/firewall/testDeveloper+Reproduzir uma chamada de amostra contra uma política rascunho.

​
Relacionados

Referência de regras de firewall

O DSL completo de regras — globs de ferramenta, matching de args, listas de egress, sequências.

Conectar um servidor MCP

Registre um servidor para que suas chamadas de ferramenta rodem atrás do firewall.

Lista de permissão de ferramentas MCP

Negue por padrão as ferramentas que você não aprovou explicitamente.

Exfiltração de dados

A ameaça que o controle de egress é construído para parar.