Saltar para o conteúdo principal
Uma regra de firewall dispara em um ponto específico do ciclo de vida de uma chamada de ferramenta. Esse ponto é seu stage — um entre quatro superfícies de enforcement, cada uma vendo uma fatia diferente da chamada. Fixe uma regra ao stage errado e ela vê os dados errados: uma allowlist de egress na superfície inbound não tem destino para verificar; uma cláusula de argumento em inbound ainda não tem argumentos em tempo de chamada. Esta página é o guia focado nos quatro stages do agent firewall: o que cada superfície observa, quando uma regra deve mirá-la, e a maneira concreta como a mesma intenção é expressa em stages diferentes. Para o vocabulário completo de regras, veja Regras do Firewall; para o modelo de política em torno dele, Firewall.

​
1. Os quatro stages em resumo

Cada avaliação é carimbada com exatamente um stage. Uma regra sem stage ("") se aplica a todos eles; uma regra fixada a um stage só dispara ali.
StageO que a superfície vê
inboundFerramentas que o agente anuncia na requisição
responsetool_calls que o modelo emite em sua resposta
mcpUm tools/call despachado através do gateway MCP
egressUm host / IP / CIDR outbound que uma ferramenta alcança
Os nomes de stage são valores enum estáveis — você os define verbatim no campo de stage do editor de regras, ou como a propriedade stage ao criar através da API.
O stage governa quais dados estão no escopo, não o quão estrito é o veredito. Um deny é um deny em qualquer stage; o que muda é se a regra tem os argumentos, o nome da ferramenta ou o destino que precisa para corresponder.

​
2. inbound — as ferramentas que um agente anuncia

A superfície mais antecipada. Antes de o modelo sequer rodar, seu agente envia uma lista de definições de ferramenta que está disposto a deixar o modelo chamar. O stage inbound vê esse conjunto de ferramentas anunciado e pode bloquear uma ferramenta perigosa antes que o modelo sequer possa escolhê-la. Não há argumentos em tempo de chamada neste stage — o modelo ainda não decidiu como chamar nada — então as regras inbound correspondem ao nome da ferramenta (e opcionalmente à sua skill proprietária), não a args_match_json.
Um veredito sanitize em inbound não tem nada para redigir (nenhum argumento existe ainda), então ele escala para um block. Crie regras inbound como allow / deny explícitos, e reserve o sanitize para os stages de execução.
Uma chamada negada aqui retorna HTTP 400 com o código firewall_blocked, nomeada conforme a ferramenta e o motivo, e marcada como skip-retry.

​
3. response — as chamadas de ferramenta que o modelo emite

Uma vez que o modelo responde, ele pode emitir uma ou mais tool_calls — invocações concretas com argumentos reais. O stage response vê essas, então é aqui que as regras em nível de argumento pertencem: não “bloquear shell.exec” mas “bloquear shell.exec apenas quando o comando for rm -rf”. 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Porque os argumentos escolhidos pelo modelo estão presentes, o sanitize funciona aqui — ele redige substrings correspondentes dos argumentos da chamada e encaminha a chamada limpa. (O sanitize redige apenas os argumentos da chamada de ferramenta; ele nunca toca no conteúdo que uma ferramenta retorna.)

​
4. mcp — chamadas despachadas através do gateway

Quando um agente alcança uma ferramenta através do gateway MCP do OrcaRouter, cada tools/call é avaliado no stage mcp antes de ser despachado ao servidor registrado. Esta é a superfície que governa o tráfego de Model Context Protocol — o mesmo vocabulário de glob / argumento / veredito que response, aplicado ao dispatch de MCP. Um block aqui aparece como um erro de ferramenta (firewall deny: <reason>) em vez de uma falha de transporte, de modo que o modelo vê a rejeição e pode reagir — escolher outra ferramenta, perguntar ao usuário, ou parar.
O stage mcp se combina com governança por servidor: cada servidor MCP registrado tem seu próprio health probe e credenciais criptografadas, e as skills carregadas através dele carregam uma faixa de risco e um modo de enforcement. Veja Firewall MCP e Skills do Firewall.

​
5. egress — o destino outbound que uma ferramenta alcança

A última superfície. Quando uma ferramenta reporta um destino de rede outbound, o stage egress corresponde a ele — a superfície de SSRF e exfiltração de dados. As regras de egress não correspondem a um padrão de nome de ferramenta sozinho; elas correspondem a uma lista de host / IP / CIDR: 
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\"],\"allow\":[\"api.openai.com\"]}"
}
As entradas correspondem como um CIDR, um literal de IP ou um hostname case-insensitive. Você cria regras de deny de host e CIDR você mesmo — o endpoint de cloud-metadata (169.254.169.254) e as faixas RFC-1918 são as coisas canônicas a negar. Veja Regras do Firewall §6 para a polaridade allow/deny.
Nenhum preset traz regras de CIDR. A postura de SSRF do nível de autonomia tight autonomy level nega nomes de ferramenta com formato de fetch (ex.: http_fetch, web_search, fetch_url); um deny de egress baseado em destino é algo que você cria para os hosts e faixas que seus agentes nunca devem alcançar.

​
6. Escolhendo o stage certo

O mesmo objetivo de segurança frequentemente tem um melhor stage. Combine a intenção com a superfície que de fato carrega os dados de que você precisa:
Se o modelo nunca deve sequer ver uma ferramenta, negue-a em inbound. O block aterrissa antes da chamada ao modelo, então não custa tokens de modelo.
As cláusulas de argumento precisam dos argumentos escolhidos pelo modelo, que só existem em response e mcp. Negue em um argumento perigoso, ou sanitize para remover um valor de segredo ou PII que o agente colocou em um argumento.
Chamadas roteadas através do gateway MCP são avaliadas em mcp antes do dispatch — o ponto de estrangulamento para as ferramentas de cada servidor registrado.
Regras baseadas em destino — bloquear o IP de cloud-metadata, negar um CIDR, fazer allowlist dos seus hosts aprovados — só fazem sentido em egress.
Uma regra sem stage roda em todos os quatro. Use-a para uma regra de estilo default_verdict abrangente, ou uma ferramenta que você nega em todo lugar onde ela aparece.

​
7. Stages e shadow mode

A flag shadow_mode de uma política é independente do stage. Ligue-a e cada veredito de enforcement — em qualquer stage — é rebaixado para audit e o motivo recebe o prefixo [shadow] would …, de modo que você possa confirmar que uma regra dispara na superfície certa antes de ela alterar o tráfego ao vivo. Veja Shadow mode e Modos de enforcement.

​
8. Onde os stages se encaixam no quadro maior

Os quatro stages são o onde do enforcement; o resto do modelo é o o quê e o quem.

Vereditos

O que cada stage pode fazer uma vez que corresponde — allow, audit, deny, sanitize, reter para aprovação, limitar custo.

Allow-listing de ferramentas

Use inbound para restringir o conjunto de ferramentas que um agente anuncia.

Validar argumentos

Crie cláusulas de argumento response / mcp que controlam uma ferramenta por como ela é chamada.

Controle de egress

Bloqueie destinos outbound na superfície egress — a fronteira de exfiltração.
Para como essas superfícies se posicionam no caminho de inspeção, veja Como o OrcaRouter inspeciona e as notas de latência do caminho de enforcement. Para as ameaças que cada stage endereça, veja Chamadas de ferramenta perigosas, Exfiltração de dados e Envenenamento de ferramenta MCP.