Saltar al contenido principal
Una regla de firewall se dispara en un punto específico del ciclo de vida de una llamada a herramienta. Ese punto es su etapa — una de cuatro superficies de aplicación, cada una viendo una porción diferente de la llamada. Fija una regla a la etapa equivocada y verá los datos equivocados: una allowlist de egress en la superficie inbound no tiene destino que verificar; una cláusula de argumentos en inbound aún no tiene argumentos en tiempo de llamada. Esta página es la guía enfocada a las cuatro etapas del agent firewall: qué observa cada superficie, cuándo una regla debería apuntar a ella y la forma concreta en que la misma intención se expresa en etapas diferentes. Para el vocabulario de reglas completo, ver Reglas del Firewall; para el modelo de política a su alrededor, Firewall.

​
1. Las cuatro etapas de un vistazo

Cada evaluación se sella con exactamente una etapa. Una regla sin etapa ("") aplica a todas ellas; una regla fijada a una etapa solo se dispara ahí.
EtapaQué ve la superficie
inboundLas herramientas que el agente anuncia en la solicitud
responseLos tool_calls que el modelo emite en su respuesta
mcpUn tools/call despachado a través del gateway MCP
egressUn host / IP / CIDR saliente que una herramienta alcanza
Los nombres de etapa son valores enum estables — los estableces literalmente en el campo de etapa del editor de reglas, o como la propiedad stage al autorar a través de la API.
La etapa gobierna qué datos están en alcance, no qué tan estricto es el veredicto. Un deny es un deny en cualquier etapa; lo que cambia es si la regla tiene los argumentos, el nombre de herramienta o el destino que necesita para coincidir.

​
2. inbound — las herramientas que un agente anuncia

La superficie más temprana. Antes de que el modelo siquiera se ejecute, tu agente envía una lista de definiciones de herramienta que está dispuesto a dejar que el modelo llame. La etapa inbound ve ese conjunto de herramientas anunciado y puede bloquear una herramienta peligrosa antes de que el modelo pueda siquiera elegirla. No hay argumentos en tiempo de llamada en esta etapa — el modelo aún no ha decidido cómo llamar a nada — así que las reglas inbound coinciden sobre el nombre de la herramienta (y opcionalmente su skill propietaria), no sobre args_match_json.
Un veredicto sanitize en inbound no tiene nada que redactar (aún no existen argumentos), así que escala a un bloqueo. Autora las reglas inbound como allow / deny explícitos, y guarda sanitize para las etapas de ejecución.
Una llamada denegada aquí devuelve HTTP 400 con el código firewall_blocked, nombrada según la herramienta y la razón, y marcada como skip-retry.

​
3. response — las llamadas a herramienta que el modelo emite

Una vez que el modelo responde, puede emitir uno o más tool_calls — invocaciones concretas con argumentos reales. La etapa response ve esas, así que aquí es donde pertenecen las reglas a nivel de argumento: no “bloquear shell.exec” sino “bloquear shell.exec solo cuando el comando es 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=\"}]}"
}
Como los argumentos elegidos por el modelo están presentes, sanitize funciona aquí — redacta las subcadenas coincidentes de los argumentos de la llamada y reenvía la llamada limpia. (Sanitize redacta solo los argumentos de la llamada a herramienta; nunca toca el contenido que una herramienta devuelve.)

​
4. mcp — llamadas despachadas a través del gateway

Cuando un agente alcanza una herramienta a través del gateway MCP de OrcaRouter, cada tools/call se evalúa en la etapa mcp antes de despacharse al servidor registrado. Esta es la superficie que gobierna el tráfico de Model Context Protocol — el mismo vocabulario de glob / argumento / veredicto que response, aplicado al despacho MCP. Un bloqueo aquí se manifiesta como un error de herramienta (firewall deny: <reason>) en vez de un fallo de transporte, así que el modelo ve el rechazo y puede reaccionar — elegir otra herramienta, preguntar al usuario o detenerse.
La etapa mcp se combina con la gobernanza por servidor: cada servidor MCP registrado tiene su propia sonda de salud y credenciales cifradas, y las skills cargadas a través de él llevan una banda de riesgo y un modo de aplicación. Ver Firewall MCP y Firewall skills.

​
5. egress — el destino saliente que una herramienta alcanza

La última superficie. Cuando una herramienta reporta un destino de red saliente, la etapa egress coincide sobre él — la superficie de SSRF y exfiltración de datos. Las reglas de egress no coinciden solo sobre un patrón de nombre de herramienta; coinciden sobre una 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\"]}"
}
Las entradas coinciden como un CIDR, un literal de IP o un nombre de host insensible a mayúsculas. Autoras las reglas de denegación de host y CIDR tú mismo — el endpoint de metadatos de nube (169.254.169.254) y los rangos RFC-1918 son las cosas canónicas a denegar. Ver Reglas del Firewall §6 para la polaridad allow/deny.
Ningún preset incluye reglas CIDR. La postura SSRF del nivel de autonomía tight (nivel de autonomía) deniega nombres de herramienta con forma de fetch (p. ej. http_fetch, web_search, fetch_url); una denegación de egress basada en destino es algo que autoras para los hosts y rangos que tus agentes nunca deben alcanzar.

​
6. Elegir la etapa correcta

El mismo objetivo de seguridad a menudo tiene una etapa óptima. Empareja la intención con la superficie que realmente lleva los datos que necesitas:
Si el modelo nunca debería siquiera ver una herramienta, deniégala en inbound. El bloqueo aterriza antes de la llamada al modelo, así que no cuesta tokens de modelo.
Las cláusulas de argumentos necesitan los argumentos elegidos por el modelo, que solo existen en response y mcp. Deniega sobre un argumento peligroso, o sanitize para quitar un secreto o valor PII que el agente puso en un argumento.
Las llamadas enrutadas a través del gateway MCP se evalúan en mcp antes del despacho — el punto de estrangulamiento para las herramientas de cada servidor registrado.
Las reglas basadas en destino — bloquear la IP de metadatos de nube, denegar un CIDR, poner en allowlist tus hosts aprobados — solo tienen sentido en egress.
Una regla sin etapa se ejecuta en las cuatro. Úsala para una regla de estilo default_verdict general, o una herramienta que deniegas dondequiera que aparezca.

​
7. Etapas y modo shadow

El flag shadow_mode de una política es independiente de la etapa. Actívalo y cada veredicto de aplicación — en cualquier etapa — se degrada a audit y la razón se prefija con [shadow] would …, así que puedes confirmar que una regla se dispara en la superficie correcta antes de que cambie el tráfico en vivo. Ver Modo shadow y Modos de aplicación.

​
8. Dónde encajan las etapas en el panorama más amplio

Las cuatro etapas son el dónde de la aplicación; el resto del modelo es el qué y el quién.

Veredictos

Qué puede hacer cada etapa una vez que coincide — allow, audit, deny, sanitize, retener para aprobación, limitar coste.

Lista de permitidos de herramientas

Usa inbound para restringir el conjunto de herramientas que un agente anuncia.

Validar argumentos

Autora cláusulas de argumentos response / mcp que gobiernan una herramienta por cómo se llama.

Control de egress

Bloquea destinos salientes en la superficie egress — la frontera de exfiltración.
Para cómo estas superficies se sitúan en la ruta de inspección, ver Cómo inspecciona OrcaRouter y las notas de latencia de la ruta de aplicación. Para las amenazas que cada etapa aborda, ver Llamadas a herramienta peligrosas, Exfiltración de datos y Envenenamiento de herramientas MCP.