Saltar para o conteúdo principal
Quando um agente chama http_fetch, web_search ou qualquer ferramenta que abre uma conexão outbound, o destino é a parte que você mais precisa governar. Um agente confuso ou sequestrado que pode alcançar 169.254.169.254 lê suas credenciais de cloud; um que pode fazer POST para um host atacante exfiltra seus dados. O controle de egress de agente governa esse destino — você cria uma regra de allow/deny de host/CIDR na superfície egress do firewall, vincula-a a uma chave, e o gateway verifica cada destino outbound que a ferramenta de um agente reporta antes de a chamada sair. Esta é uma página de caso de uso focada. Para a gramática de regras completa e a semântica de veredito veja Schema de regra e Vereditos; para como o egress se posiciona entre os outros pontos de enforcement veja Stages.

​
1. Controle de egress de agente na superfície egress

Das quatro superfícies do firewall, egress é a que vê o destino de rede outbound que uma ferramenta reporta — um host, um literal de IP ou um CIDR. Uma regra fixada a stage: egress corresponde a esse destino, não ao nome da ferramenta ou seus argumentos, o que a torna o controle de SSRF e exfiltração de dados: ela responde onde este agente pode alcançar, independentemente de qual ferramenta fez o alcance.
O egress é escopo de destino, não bloqueio de ferramenta. Para impedir que uma ferramenta exista totalmente, negue-a pelo nome na superfície inbound (Bloquear ferramentas). O controle de egress assume que a ferramenta pode legitimamente buscar — ele apenas restringe para onde.

​
2. Um exemplo: negar os destinos de SSRF

A regra de egress canônica nega o endpoint de cloud metadata e as faixas privadas RFC-1918 — os destinos que uma ferramenta com formato de fetch nunca deve alcançar. No console do seu workspace, abra uma política e adicione uma regra com stage egress, veredito deny e uma lista de egress: 
{
  "label": "deny SSRF destinations",
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"],\"allow\":[\"api.openai.com\"]}"
}
egress_json é uma string codificada em JSON carregando as listas de host/CIDR — decodificado, é {"deny": [...], "allow": [...]}. Cada entrada corresponde como um CIDR, um literal de IP ou um hostname case-insensitive. Para um veredito deny a lista deny é o conjunto em escopo (destinos que a regra bloqueia) e a lista allow recorta exceções dele — então a regra acima bloqueia as quatro faixas mas deixa api.openai.com passar mesmo que ele alguma vez resolvesse para uma delas. Quando um destino é um hostname em vez de um literal de IP e sua lista carrega entradas de IP/CIDR, o nome é resolvido em best-effort e seus endereços re-verificados, então metadata.internal ainda corresponde a um deny 169.254.0.0/16 mesmo que não esteja listado pelo nome.
Para uma postura de allow-list em vez disso — permita apenas um conjunto nomeado de destinos e bloqueie o resto — escreva a regra com veredito allow e coloque seus destinos na lista allow. A polaridade inverte: allow vira o conjunto em escopo e deny recorta exceções. Combine-a com um default_verdict de política deny para que qualquer coisa que a regra de allow não cubra seja bloqueada.

​
3. Você cria as regras de CIDR — nenhum preset as traz

Não há lista de CIDR de preset. O OrcaRouter não traz uma regra embutida que nega 169.254.169.254, RFC-1918 ou qualquer outra faixa. A regra de allow/deny de CIDR é sua para criar — é o exemplo no §2, escrito por você contra sua própria rede. Copie-a, depois ajuste as faixas e as exceções da allow-list ao seu ambiente.
O que o nível de autonomia tight e seu preset block_ssrf_egress de fato trazem é um conjunto de denies nos nomes de ferramenta com formato de fetch — http_fetch, web_search, fetch_url, request, mais suas variantes MCP <server>.<tool>. Essa é uma postura contundente: ela recusa as ferramentas com formato de egress totalmente em vez de dar escopo a onde elas podem alcançar. Recorra a ela quando um agente não tem razão alguma para fazer chamadas de rede; recorra a uma regra de destino (§2) quando ele de fato busca mas apenas de um conjunto aprovado de hosts.
AbordagemO que restringeAutor
Preset SSRF tightNomes de ferramenta com formato de fetch (nega-os)Embutido
Regra de egress CIDR/hostO destino que um fetch pode alcançarVocê

​
4. Como é um egress bloqueado

Quando um destino corresponde a uma regra de egress de enforcement, a chamada é negada antes de sair do gateway e a avaliação é registrada como um evento de firewall com superfície egress e veredito deny. No shadow mode o deny é rebaixado para audit com o motivo prefixado [shadow] would …, então você pode medir exatamente quais destinos uma regra bloquearia contra o tráfego real antes de aplicá-la.
Uma lista de egress malformada ou sem entradas é tratada conservadoramente: uma regra de enforcement deny ainda controla (um typo não pode silenciosamente impedi-la de bloquear), mas uma regra allow com uma lista quebrada não dispara — caso contrário uma allow-list mal digitada se tornaria allow-all e faria sombra a um deny padrão. Novas regras são validadas ao salvar (a lista deve declarar ao menos uma entrada allow ou deny), então isso só protege linhas legadas.

​
5. Crie a partir do tráfego real, depois faça o rollout

O log de events registra o host de destino em cada evento de superfície egress (egress_host/egress_url), então filtre-o para a superfície egress e crie sua lista de deny a partir dos destinos que de fato apareceram em vez de adivinhar. A aba Discovered Tools é um rollup por nome de ferramenta (nomes de ferramenta e as superfícies em que dispararam) — ela diz quais ferramentas com formato de fetch rodaram, não os hosts que alcançaram. Veja Analytics.
A aba Test do console faz dry-run de uma política contra um tool_name + superfície de amostra (+ args opcionais) e retorna o veredito, a regra correspondente e o motivo — nada é despachado. Ela confirma qual regra uma chamada resolve; para confirmar sua matemática de CIDR/host contra destinos reais, use o shadow mode abaixo (o payload de Test não carrega um destino, então a correspondência de lista de egress é exercida no tráfego de egress ao vivo). Veja Testar regras.
Ligue o shadow mode e o deny de egress é registrado como dispararia sem bloquear. Observe o log de events filtrado para a superfície egress, confirme que ele captura os destinos que você espera, depois desligue o shadow.
O escopo de destino no gateway é defesa em profundidade, não a última linha. O IP para o qual um hostname resolve no momento da avaliação pode diferir daquele que uma ferramenta de fato disca (DNS rebinding). Mantenha um controle de IP-deny na sua própria camada de egress/dialer também; a regra do gateway é a captura pré-voo barata para os casos óbvios.

​
6. Vincule a política e quem pode editá-la

Uma política não faz nada até que uma chave resolva para ela. Vincule no console definindo firewall_policy_id na chave, ou torne a política o padrão do workspace. A resolução é: a política vinculada da chave (quando ela existe e está habilitada), senão o padrão do workspace. Toda a configuração de regra de egress roda no console sob sua sessão (/api/workspace/firewall/*):
AçãoPapel
Ler políticas, presets, ferramentas descobertas, Simulate de autonomiaMember
Criar / editar / deletar regras de egress e políticasDeveloper+
Endpoint dry-run de Test (POST /test)Developer+
Ler o log de events e agregados de runDeveloper+

​
Relacionados

Exfiltração de dados

A ameaça que o controle de egress endereça.

Stages

As quatro superfícies, e onde o egress se posiciona.

Vereditos

O que deny, audit e allow fazem na prática.

Bloquear ferramentas

Negue uma ferramenta de fetch pelo nome em vez de por destino.

Chamadas de ferramenta perigosas

A classe de risco mais ampla.

Referência do Firewall

A referência completa de regra + correspondência, incluindo listas de egress.