Saltar al contenido principal
Un agente de IA no solo genera texto — actúa. Llama a shell.exec, consulta una base de datos, recupera una URL, despacha una herramienta a través de un servidor MCP. Cada una de esas es una acción en el mundo real que los guardrails a nivel de prompt no pueden ver. El agent firewall es el plano a nivel de acción que las gobierna: una política nombrada, con alcance de espacio de trabajo, que el gateway evalúa en cada llamada a herramienta, antes de que llegue a la herramienta. Esta página es el hub de la sección Firewall — el modelo de política, los veredictos, las superficies y cómo una política se adjunta a una clave. Cada radio profundiza, y la referencia completa del motor vive en Firewall y Reglas del Firewall.

​
1. Qué hace el agent firewall

Autoras una política una vez en la consola de tu espacio de trabajo, le adjuntas una clave API (o estableces una como el valor por defecto del espacio de trabajo), y a partir de entonces cada llamada a herramienta que emite esa clave se verifica contra la política en el gateway. Sin redespliegue, sin cambio de código del agente — tu agente sigue emitiendo llamadas a herramienta exactamente como antes, y editar la política surte efecto en la siguiente llamada para cada clave adjunta a ella. Una política es una lista ordenada de reglas. Cada regla decide a qué llamadas a herramienta aplica y qué hacer al respecto. El motor recorre las reglas en orden de prioridad, gana la primera coincidencia, y hace fallback al veredicto por defecto de la política si nada coincide.
La detección ocurre en el gateway, en el primer uso — no en tiempo de instalación. Una herramienta, servidor MCP o skill que un agente autoinstala se captura la primera vez que su llamada cruza el gateway. Ese es el único punto de estrangulamiento que ve cada proveedor, cada agente y cada llamada a herramienta sin importar cómo llegó ahí la capacidad.

​
2. Un ejemplo concreto

Supón que quieres bloquear comandos shell destructivos pero dejar pasar todo lo demás bajo audit. En la consola creas una política con default_verdict = audit y una regla: 
{
  "label": "block rm -rf",
  "tool_name_glob": "*.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|drop table\"}]}",
  "verdict": "deny"
}
args_match_json es un string codificado en JSON (el gateway lo valida contra el esquema de cláusulas al guardar): path es un JSONPath hacia los argumentos de la llamada, op es uno de eq, contains, regex, in, cidr_match, gt, lt. Adjunta una clave a la política (establece firewall_policy_id en la clave). Ahora, cuando un agente emite shell.exec con command: "rm -rf /", el gateway devuelve HTTP 400 con el código de error firewall_blocked y una razón que nombra la herramienta — y la llamada nunca llega al shell. Cualquier otra llamada a herramienta se permite y se registra para revisión.
Lanza una política nueva bajo modo shadow primero: evalúa y registra exactamente como lo haría en producción, pero cada veredicto de aplicación se degrada a audit y la razón se prefija con [shadow] would …. Observa el feed de eventos, luego apaga el modo shadow para aplicar.

​
3. Política, reglas y resolución

Una política tiene alcance de espacio de trabajo y nombre, con enabled, is_default, un default_verdict (allow / audit / deny, por defecto audit) y un flag shadow_mode. Una regla es una verificación dentro de ella — ver Crear una política y Esquema de regla. Para cualquier llamada a herramienta el gateway resuelve la política activa en orden:
  1. Vinculación de clave — el firewall_policy_id de la clave que llama, cuando esa política existe y está habilitada.
  2. Valor por defecto del espacio de trabajo — en caso contrario, la política habilitada is_default.
Una política de firewall adjunta deshabilitada hace fallback al valor por defecto del espacio de trabajo — esto difiere de los guardrails, donde una vinculación deshabilitada resuelve a ninguna. El interruptor de apagado en el firewall de una clave es “usa el valor por defecto”, no “sin aplicación”. Ver Gestionar políticas.
Cuando ninguna política resuelve en absoluto, el comportamiento depende del ajuste firewall_observe_mode del espacio de trabajo: con el modo observe activado, la llamada se permite pero se registra como un hueco de cobertura (aparece en Herramientas descubiertas); con él apagado, la llamada se permite silenciosamente.

​
4. Veredictos

Una regla — o el valor por defecto — produce uno de:
VeredictoQué hace
allowDeja pasar, registrado.
auditPermite + registra para revisión. El valor por defecto habitual.
denyBloquea. HTTP 400 firewall_blocked en inbound; error de herramienta en MCP.
sanitizeRedacta las subcadenas coincidentes de los argumentos de la herramienta y reenvía.
pending_approvalRetiene para un humano; HTTP 400 firewall_approval_pending.
cap_costDeniega una vez que el gasto de la ejecución cruza un tope por regla.
Un veredicto sanitize redacta solo los argumentos de la llamada — nunca el contenido que una herramienta devuelve. En la superficie inbound, donde aún no hay argumentos en tiempo de llamada, sanitize escala a un bloqueo. Ver Veredictos y Sanear respuestas.

​
5. Las cuatro superficies de aplicación

Cada llamada a herramienta se evalúa contra exactamente una superficie — fija una regla a una con el campo stage, o déjalo vacío para aplicar a todas.

inbound

Las herramientas que un agente anuncia al modelo en la solicitud. Bloquea una herramienta peligrosa antes de que el modelo pueda siquiera elegirla.

response

Los tool_calls que el modelo emite en su respuesta.

mcp

Un tools/call despachado a través del gateway MCP. Ver Servidores MCP.

egress

Un host / IP / CIDR saliente que una herramienta alcanza — la superficie de SSRF y exfiltración de datos.

​
6. Coincidencia

Las reglas expresan a qué llamadas a herramienta capturan con un vocabulario pequeño y determinista que es seguro en la ruta caliente:
Un glob sensible a mayúsculas sobre el nombre de la herramienta (shell.*, *.delete), opcionalmente conjugado con un glob sobre la skill propietaria. Ver Sintaxis glob y Lista de permitidos de herramientas.
Predicados JSONPath sobre los argumentos de la llamada con operadores eq, contains, regex, in, cidr_match, gt, lt — la diferencia entre “bloquear shell.exec” y “bloquearlo solo cuando el comando es rm -rf”. Las cláusulas fallan cerradas (la regla, no la solicitud). Ver Validar argumentos.
Listas de permitidos y denegados de host / IP / CIDR en la superficie egress. Puedes autorar tu propia regla de denegación para metadatos de nube o rangos RFC-1918. Ver Control de egress.
Una regla sequence coincide con una cadena ordenada de llamadas a lo largo de una ventana (aplicada de forma reactiva); una regla cap_cost deniega una vez que el gasto acumulado de la ejecución de un agente cruza un techo en centavos. Ver Reglas de secuencia y Limitar coste.

​
7. Aprobación humana, autonomía y anomalías

  • Humano en el ciclo. Un veredicto pending_approval retiene la llamada y devuelve su id de aprobación. Un revisor lo resuelve en la consola (Developer+) o vía un callback de webhook firmado con HMAC; el agente hace polling y reenvía con una cabecera X-OrcaRouter-Firewall-Approval de un solo uso. Ver Aprobaciones y Webhook de aprobación.
  • Niveles de autonomía. Un interruptor establece toda tu postura: tight (defecto-deny + denegar shell destructivo + denegar herramientas con forma de fetch (http_fetch/web_search/fetch_url/request, el vector SSRF) + PII Shield + Secrets Blocker aplicados), balanced (audit por defecto, denegar shell destructivo, PII Shield solo audit) o permissive (solo observe). Cada uno escribe filas de política y guardrail reales y editables, con deshacer de un clic desde el snapshot de auditoría.
  • Detección de anomalías. Más allá de las reglas estáticas, el firewall puntúa el uso de herramientas contra una línea base de hora-de-la-semana aprendida (14 días) y marca picos de tasa/coste, retry_loop y novel_path en un feed legible por Member que puedes posponer (snooze) hasta 7 días.

​
8. Dónde encaja el firewall

El firewall es el par a nivel de acción de dos planos adyacentes:
PlanoGobiernaCuándo recurrir a él
GuardrailsTexto de prompt y respuestaPII, secretos, jailbreaks, intención de inyección
Agent firewallAcciones de herramientaQué herramientas, llamadas MCP, hosts y coste
CumplimientoEvidencia y marcosPreparación para SOC 2 / HIPAA / EU AI Act
Tanto el plano de contenido como el de acción pueden aplicarse a una sola solicitud, y un nivel de autonomía los configura juntos. Ver Guardrails vs. Firewall y la pila de controles.

​
9. Adjuntar y conectar

Una política se vincula a una clave vía firewall_policy_id (configurado en la consola; la vinculación vive en la clave dentro del gateway). Dos formas en que una llamada a herramienta llega al motor, ambas requieren una clave con alcance de gateway de firewall (is_firewall_gateway = true) — una clave de relay normal obtiene 403 en estas rutas:
  • Gateway MCP — apunta tu cliente MCP al endpoint unificado ANY /api/v1/firewall/mcp; cada tools/call se evalúa en línea. Ver Servidores MCP.
  • Hook de evaluación — llama a POST /api/v1/firewall/evaluate (o /evaluate_plan para un plan de varios pasos) desde tu propio bucle de agente antes de despachar, y actúa sobre el veredicto.
Toda la configuración de consola se ejecuta bajo tu sesión vía /api/workspace/firewall/*. Las lecturas de políticas, configuraciones, herramientas descubiertas, el simulador de autonomía de solo lectura y el feed de anomalías están abiertas a cada miembro del espacio de trabajo; el sandbox de Test de ejecución en seco, el registro de Events / Runs y todas las escrituras requieren Developer+. Ver Claves de gateway y Probar reglas.

​
10. Amenazas que aborda este plano

Llamadas a herramienta peligrosas

Deniega shell destructivo, drops de BD y verbos arriesgados por glob + args.

Exfiltración de datos

Listas de egress y reglas de secuencia leer-luego-exportar.

Envenenamiento de herramientas MCP

Evaluación por llamada en la superficie mcp antes del despacho.

Agencia excesiva

Aprobaciones, topes de coste y postura defecto-deny.

​
Próximos pasos

Crear una política

Autora tu primera política y regla.

Veredictos

Qué hace cada veredicto en el cable.

Registro de eventos

Lee qué decidió el firewall y por qué.