Saltar al contenido principal
Tienes una clave que tu agente usa en api.orcarouter.ai, y quieres que cada llamada a herramienta que hace esa clave sea gobernada — bloqueada, auditada, saneada o retenida para aprobación — sin tocar el código de tu agente. Esa es una configuración del agent firewall en dos pasos: crea una política de firewall una vez, luego apunta la clave hacia ella. Desde la siguiente llamada en adelante, cada herramienta que la clave emite se verifica contra la política en el gateway. Esta página es la ruta de crear-y-adjuntar. Para el modelo de política completo (superficies, veredictos, resolución) ver la Visión general del Firewall; para la gramática de reglas ver Reglas del Firewall.
Toda la configuración de política y clave ocurre en la consola (o las rutas de gestión /api/workspace/firewall/*, que usan tu sesión / token de acceso — no una clave de relay sk-orca-…). Solo las llamadas /v1/* de tu agente usan la clave de relay. Crear y adjuntar una política es una acción Developer+.

​
1. Configuración del agent firewall de un vistazo

Una política de firewall es un objeto nombrado, con alcance de espacio de trabajo: una lista ordenada de reglas más un veredicto por defecto para todo aquello que ninguna regla coincide. Una clave opta por una política a través de su campo firewall_policy_id. Nada más en tu pila cambia.

Crear la política

Nómbrala, elige un veredicto por defecto, añade reglas — o siembra desde un nivel de autonomía / preset y edita.

Adjuntar una clave

Establece el firewall_policy_id de la clave a la política, o marca la política como el valor por defecto del espacio de trabajo para que cada clave sin vincular la herede.

​
2. Crear una política en la consola

  1. Abre Security → Firewall → Policies y elige New policy.
  2. Nómbrala (única en el espacio de trabajo) y deja Enabled activado.
  3. Elige un veredicto por defecto — ver §3.
  4. Añade reglas en el editor de reglas, o empieza vacío y deja que Herramientas descubiertas impulse la autoría desde el tráfico real más adelante.
  5. Guarda. La política existe pero no gobierna nada hasta que una clave apunte a ella o la hagas el valor por defecto del espacio de trabajo.
¿No quieres autorar reglas a mano primero? Aplica un nivel de autonomía (balanced es el inicio recomendado) — materializa filas de política y guardrail reales y editables que luego puedes afinar. O empieza una regla desde un preset integrado y edítala. De cualquier forma terminas en el mismo lugar: una política nombrada que adjuntas a una clave.

​
3. Elige el veredicto por defecto

El veredicto por defecto es lo que la política hace cuando ninguna regla coincide con una llamada a herramienta. Es el piso de tu postura. Acepta exactamente tres valores:
default_verdictCuando ninguna regla coincide…
audit (por defecto)Permite la llamada, pero la registra. Observa todo, no bloquea nada — el lugar seguro para empezar.
allowPermite y registra, sin registro de revisión.
denyBloquea cualquier cosa que una regla no permita explícitamente — una postura defecto-deny que combinas con reglas allow.
deny es defecto-deny: cualquier llamada a herramienta que tus reglas no permitan explícitamente se bloquea. Potente, pero detendrá llamadas que olvidaste poner en lista de permitidos. Lanza una política defecto-deny bajo modo shadow primero y observa el feed de eventos antes de aplicarla.
Los veredictos que una regla puede producir (allow, audit, deny, sanitize, pending_approval, cap_cost) se cubren en Veredictos — el veredicto por defecto está limitado a los tres de arriba.

​
4. Adjunta la política a una clave

Una clave opta por una política a través de su firewall_policy_id. En la consola:
  1. Abre Keys, edita la clave que tu agente usa.
  2. Establece Firewall policy a la política que creaste (esto escribe firewall_policy_id).
  3. Guarda. La siguiente llamada que hace esa clave es gobernada.
La vinculación vive en la clave, en el gateway — tu agente sigue enviando el mismo Authorization: Bearer sk-orca-… y el mismo cuerpo de solicitud. No hay cambio en el código de llamadas a herramienta de tu agente. 
# Your agent's relay call is unchanged. The attached policy is enforced
# at the gateway before any tool call in the response is dispatched.
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "delete the staging table"}],
    "tools": [{"type": "function", "function": {"name": "db.query"}}]
  }'
Si una regla deniega una llamada a herramienta en la superficie inbound, esa llamada vuelve como HTTP 400 con el código firewall_blocked, nombrando la herramienta y la razón — ver cómo se ve un bloqueo.

​
5. Resolución: adjunta → valor por defecto del espacio de trabajo

Para cualquier llamada a herramienta, el gateway resuelve qué política aplica en este orden:
Si el firewall_policy_id de la clave que llama apunta a una política que existe y está habilitada, esa política aplica.
En caso contrario, aplica la política habilitada is_default del espacio de trabajo (si hay una establecida). A lo sumo una política por espacio de trabajo puede ser el valor por defecto; promover un nuevo valor por defecto degrada al anterior en la misma transacción.
Sin vinculación y sin valor por defecto significa sin política. Con el modo observe activado, la llamada se permite y se registra como un hueco de cobertura; con él apagado, la llamada se permite silenciosamente.
Una política adjunta deshabilitada hace fallback al valor por defecto del espacio de trabajo — no apaga la aplicación. (Esto difiere de los guardrails, donde una vinculación deshabilitada resuelve a ninguna.) Para sacar una clave del alcance del firewall, desvincúlala (establece firewall_policy_id a 0), no solo deshabilites su política.
Para hacer una política el valor por defecto para cada clave sin vincular, edítala y establécela como el valor por defecto del espacio de trabajo en vez de adjuntar claves una por una — ver Gestionar políticas.

​
6. Verifica que surtió efecto

Antes de confiar en ella, confirma que la política se dispara como esperas:
  • Pruébala — la pestaña Test del sandbox ejecuta en seco la política contra una llamada a herramienta de muestra y devuelve el veredicto, la regla coincidente y la razón. Nada se despacha ni se persiste. Ver Probar reglas.
  • Observa el feed de eventos — una vez que la clave toma tráfico en vivo, Events muestra cada evaluación, filtrable por veredicto, superficie, herramienta y ejecución.
Lanza cualquier política de aplicación detrás de modo shadow primero: evalúa y registra exactamente como lo haría en producción, pero degrada cada veredicto de aplicación a audit y prefija la razón con [shadow] would …. Apaga el modo shadow una vez que el feed de eventos muestre que se dispara en lo que esperas y en nada que no.

​
Dónde ir a continuación

Autorar reglas

El lenguaje de coincidencia completo — globs de herramienta, cláusulas de argumentos, listas de egress, saneadores.

Lista de permitidos de herramientas

Combina un veredicto por defecto deny con reglas allow explícitas.

Gestionar políticas

Valores por defecto, habilitar/deshabilitar, versionado y revertir.

Por qué zero trust

Por qué gobernar acciones — no solo texto — importa para los agentes.
Para las amenazas que una política busca detener, ver llamadas a herramienta peligrosas y agencia excesiva.