Saltar al contenido principal
Un servidor MCP que conectas trae herramientas que salen a la red — un fetch, un web_search, un poster de webhook. El nombre de la herramienta podría estar en tu lista de permitidos, los argumentos podrían parecer limpios, y la llamada aún termina haciendo POST de tus datos a un host controlado por un atacante o extrayendo credenciales del endpoint de metadatos 169.254.169.254. El destino es la parte de la llamada que tus reglas de nombre de herramienta nunca ven. mcp egress control cierra esa brecha. Una regla de egress acota un veredicto de firewall a dónde alcanza una herramienta — un host, una IP o un rango CIDR — así que el mismo http_fetch que está permitido a api.openai.com se deniega a todo lo demás. Se ejecuta en la superficie egress del firewall, encima de la evaluación por llamada por la que cada tools/call ya pasa.
Esta es una tarea de consola. Las reglas de firewall viven en las rutas /api/workspace/firewall/*, que se autentican con tu token de sesión / acceso — no con una clave de relay sk-orca-…. Autorar una regla requiere el rol Developer+.

​
1. Qué controla una regla de egress

Una regla normal coincide con el nombre de la herramienta y sus argumentos. Una regla de egress añade una tercera dimensión: el destino al que la llamada se resuelve. Estableces el stage de la regla en egress y adjuntas una lista egress_json de entradas allow / deny. El motor extrae el host de destino de la llamada y solo dispara la regla cuando ese host está en alcance. Las entradas se cotejan de tres maneras:

Nombre de host

Coincidencia exacta insensible a mayúsculas, p. ej. api.openai.com. Un punto final se recorta en ambos lados.

IP literal

Coincidencia exacta contra la IP de marcado resuelta, p. ej. 169.254.169.254.

Rango CIDR

La IP de destino — literal o resuelta por DNS — debe caer dentro del bloque, p. ej. 10.0.0.0/8.
Cuando un destino es un nombre de host pero tu lista lleva entradas IP/CIDR, el nombre se resuelve y sus IPs se re-verifican — así metadata.internal coincide con un deny 169.254.0.0/16 aunque no esté listado por nombre. Esto es defensa en profundidad de mejor esfuerzo contra un nombre que resuelve hacia un rango denegado; la guarda SSRF autoritativa sigue ejecutándose en la capa de marcado del gateway.

​
2. Un ejemplo concreto

Deniega que cada herramienta con forma de fetch alcance el endpoint de metadatos de la nube y los rangos RFC-1918. Este es el corte canónico de la pata de exfil SSRF: un veredicto deny en el stage egress, acotado por una lista de denegación 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\"]}"
  }'
Un tools/call cuyo destino resuelve hacia cualquiera de esos rangos vuelve al modelo como un error de herramienta; una llamada a un host público que la lista de denegación no cubre pasa a través.
Las listas allow/deny cambian de significado con el veredicto. En una regla deny (u otra enforcing), la lista deny es el conjunto en alcance y allow talla exenciones — “deniega estos, excepto aquellos”. En una regla allow los roles se invierten: la lista allow es el conjunto en alcance y deny talla exenciones — “permite solo estos”. Un egress_json no vacío debe declarar al menos una entrada allow o deny, o la escritura se rechaza.

​
3. Lista de permitidos de un solo destino

El inverso del ejemplo de arriba: fija una herramienta de fetch a un único host sancionado y deja que el default_verdict de la política (o un catch-all posterior) maneje el resto. Como este es un veredicto allow, la lista allow es el conjunto en alcance. 
// egress_json en una regla con veredicto allow, stage=egress
{ "allow": ["api.openai.com", "api.anthropic.com"] }
La regla ahora dispara (permite) solo cuando el destino es uno de esos dos hosts. Cualquier otra cosa cae a través a la siguiente regla — empareja esto con una política de denegación por defecto para que un destino no listado se rechace en vez de dejarse pasar.
Pruébalo antes de confiar en él. La pestaña Test de la consola y el endpoint POST /api/workspace/firewall/test (Developer+) reproducen una llamada de muestra contra tu política borrador así puedes confirmar el veredicto en un destino conocido sin enviar tráfico en vivo.

​
4. Cómo se compone con el resto del firewall

Una regla de egress es una regla entre muchas en una política de firewall de espacio de trabajo. El motor recorre las reglas en orden de prioridad (la más baja primero) y la primera coincidencia gana, así que pon un deny de egress estrecho por encima de cualquier allow amplio.
Veredicto en una regla de egressEfecto
denyBloquea la llamada a destinos en alcance — registrado en la superficie egress y devuelto a la herramienta como un error.
auditRegistra la llamada coincidente como un evento de firewall; igual se despacha.
allowPermite destinos en alcance; se empareja con un piso de denegación por defecto.
pending_approval y cap_cost no se aplican en la superficie egress — el egress es una verificación de destino, no una retención ni un tope de gasto. Usa esos veredictos en las superficies mcp o inbound en su lugar. Ver la referencia de veredictos.
Dos controles relacionados vale la pena cablear junto a una regla de egress:
Independientemente de cualquier regla que autores, el gateway MCP valida cada endpoint de servidor y su IP de marcado resuelta contra una política SSRF — los rangos de intranet y la dirección de metadatos de la nube se rechazan, y la IP se re-verifica en cada salto para derrotar el DNS rebinding. Tu regla de egress pone en capa una política de destino específica del espacio de trabajo encima de esa base.
Un solo deny de egress detiene que una herramienta alcance un host. Una regla de secuencia detiene la cadena — p. ej. “lee un archivo, luego egress dentro de la ventana” — marcando la pata de egress solo cuando sigue a una lectura sensible. Ese es el rompedor de la trifecta letal; el alcance de egress es el control por llamada.

​
5. Ponlo en sombra primero, luego aplica

Rodar un deny de egress directo a cumplimiento en un espacio de trabajo ocupado arriesga romper una integración legítima que olvidaste. Dos redes de seguridad:
  • Modo sombra. Una política en modo sombra degrada cada veredicto enforcing a audit — tu deny de egress registra [shadow] would deny … en vez de bloquear, así ves el radio de explosión antes de que muerda.
  • Modo observe. El ajuste de espacio de trabajo firewall_observe_mode registra las llamadas no cubiertas como Herramientas Descubiertas, aflorando los destinos reales que tus agentes ya alcanzan así puedes escribir una lista de permitidos precisa a partir de datos en vez de conjeturas.
La coincidencia de destino de egress se basa en el host al que la llamada resuelve en tiempo de evaluación. Un servidor hostil aún puede hacer rebind de DNS entre la verificación de política y el marcado real (TOCTOU) — que es exactamente por qué la guarda de IP a nivel de socket del gateway es el control autoritativo y esta regla es defensa en profundidad, no la única línea.

​
6. Roles y rutas

Todas las rutas de consola tienen alcance de espacio de trabajo y se autentican con tu token de sesión / acceso. Las lecturas están abiertas a cualquier Member; autorar o editar una regla requiere Developer+.
Método y rutaRolPropósito
GET /api/workspace/firewall/policies/:idMemberLeer una política y sus reglas.
POST /api/workspace/firewall/rulesDeveloper+Añadir una regla (establece stage: egress).
PUT /api/workspace/firewall/rulesDeveloper+Actualizar una regla (id en el cuerpo).
DELETE /api/workspace/firewall/rules/:idDeveloper+Eliminar una regla.
POST /api/workspace/firewall/testDeveloper+Reproducir una llamada de muestra contra una política borrador.

​
Relacionado

Referencia de reglas del firewall

El DSL completo de reglas — globs de herramienta, coincidencia de argumentos, listas de egress, secuencias.

Conectar un servidor MCP

Registra un servidor para que sus llamadas a herramienta se ejecuten detrás del firewall.

Lista de permitidos de herramientas MCP

Deniega por defecto las herramientas que no aprobaste explícitamente.

Exfiltración de datos

La amenaza que el control de egress está construido para detener.