Saltar al contenido principal
Has autorado una guardrail y una política de firewall para tu espacio de trabajo. Ahora quieres que esta clave en particular — la que usa tu agente de finanzas — ejecute una política de contenido más estricta y una lista de herramientas permitidas más ajustada que el resto del espacio de trabajo. Eso es lo que hacen los dos campos de adjunto de una clave: vincular una guardrail y una política de firewall a una sola clave, y cada solicitud que esa clave haga se examina y se aplica exactamente con esas políticas — sin cambio de código del agente, sin redespliegue. Esta página cubre los dos campos, cómo se resuelven en tiempo de solicitud, y la única regla de resolución que atrapa a la gente: un adjunto de firewall deshabilitado se comporta de manera diferente a un adjunto de guardrail deshabilitado.

​
1. La política de seguridad por clave: dos campos en una clave

Una guardrail examina el texto que fluye a través de un modelo (PII, secretos, jailbreaks). Una política de firewall gobierna las llamadas a herramienta que emite un agente (qué herramientas, qué servidores MCP, qué hosts). Ambas son políticas nombradas, con alcance de espacio de trabajo — autoradas una vez, compartidas en todo el espacio de trabajo — y una clave opta por una específica a través de dos campos:
CampoVinculaEstablece en consola
guardrail_idLa guardrail que examina los prompts y respuestas de esta clave.Developer+
firewall_policy_idLa política de firewall que evalúa las llamadas a herramienta de esta clave.Developer+
Ambos se establecen en el editor de claves en /console/token. Establecer cualquiera de ellos es una acción Developer+ — las políticas en sí también se autoran como Developer+ (ver Alcance y claves).
Estos dos campos son independientes. Una clave puede adjuntar una guardrail y no una política de firewall, lo inverso, ambas, o ninguna — cada plano se resuelve por su cuenta. Dejar un campo sin establecer (0) no es lo mismo que apagar la aplicación; ver §3.

​
2. Un ejemplo concreto

Digamos que la guardrail por defecto de tu espacio de trabajo marca PII pero la deja pasar, y la política de firewall por defecto audita cada llamada a herramienta. Eso está bien para la mayoría de los agentes — pero tu agente de finanzas maneja SSNs de clientes y nunca debería llamar a una herramienta de shell. Autora una finance-guardrail más estricta (bloquea PII por completo) y una finance-firewall (lista de permitidos solo con las tres herramientas que necesita), luego vincula ambas a la clave de ese agente: 
# Configure via the CONSOLE (UserAuth — your session), not a relay key.
# This is the key-update call the editor at /console/token makes.
PUT /api/token
{
  "id": 4127,
  "name": "finance-agent",
  "guardrail_id": 12,          // finance-guardrail (PII = block)
  "firewall_policy_id": 8      // finance-firewall (3-tool allow-list)
}
A partir de la siguiente solicitud, el tráfico de esa clave es examinado por la guardrail 12 y sus llamadas a herramienta son evaluadas por la política 8 — mientras cada otra clave en el espacio de trabajo sigue ejecutando los valores por defecto del espacio de trabajo. El propio código del agente nunca cambia; sigue llamando a https://api.orcarouter.ai/v1/... con su clave sk-orca-… exactamente como antes.
Este es el patrón de mínima agencia: una clave con alcance estrecho por agente, cada una vinculada a las políticas que su trabajo realmente necesita. Cuando ese agente se ve comprometido, el radio de explosión es lo que su clave estaba autorizada a hacer — nada más. Ver la lista de verificación de mínima agencia.

​
3. Resolución: la regla que atrapa a la gente

Para cada solicitud, el gateway resuelve la guardrail activa y la política de firewall activa de manera independiente. El orden se ve igual para ambas — adjunto primero, valor por defecto del espacio de trabajo segundo — pero divergen en un caso.

​
Resolución de guardrail

El guardrail_id de la clave apunta a una guardrail que existe y está habilitada. Esa guardrail examina la solicitud.
Deshabilitar la guardrail adjunta es un interruptor de apagado. La clave no obtiene ningún examen de contenido — no hace fallback al valor por defecto del espacio de trabajo. Esto es deliberado: adjuntar una guardrail y deshabilitarla es cómo apagas el examen para esa clave.
Sin guardrail_id en la clave. La guardrail por defecto habilitada del espacio de trabajo aplica, si hay una establecida.
Sin adjunto y sin valor por defecto del espacio de trabajo → la solicitud pasa sin examen de contenido.

​
Resolución de firewall

El firewall_policy_id de la clave apunta a una política que existe y está habilitada. Esa política evalúa las llamadas a herramienta de la clave.
Aquí está la diferencia. Un adjunto de firewall deshabilitado hace fallback a la política de firewall por defecto del espacio de trabajo — no apaga la aplicación. Deshabilitar un adjunto de firewall revierte la clave al valor por defecto del espacio de trabajo; no deja la clave sin protección.
Sin firewall_policy_id en la clave → aplica la política de firewall por defecto habilitada del espacio de trabajo.
Deshabilitar una política adjunta no es simétrico. Un adjunto de guardrail deshabilitado significa ninguna guardrail para esa clave. Un adjunto de firewall deshabilitado significa fallback al valor por defecto del espacio de trabajo. Si quieres que una clave genuinamente no ejecute aplicación de firewall, no puedes llegar ahí deshabilitando su adjunto — asegúrate de que no haya ninguna política de firewall por defecto del espacio de trabajo establecida (o da alcance a la clave para que no emita llamadas a herramienta gobernadas).
A lo sumo una guardrail y una política de firewall por espacio de trabajo pueden ser el valor por defecto en cualquier momento; promover un nuevo valor por defecto degrada al anterior en la misma transacción, así que nunca puedes tener dos por accidente.

​
4. Cómo se ve un block

Cuando una política vinculada deniega una solicitud, el llamante ve un error estructurado — el agente puede reaccionar en vez de fallar:
PlanoCódigo de errorHTTPCoste
Guardrailguardrail_blocked400Ninguno — un bloqueo de entrada se dispara antes de la medición; un bloqueo de salida reembolsa. Marcado skip-retry.
Firewall (inbound)firewall_blocked400Un bloqueo inbound se dispara antes de la llamada al modelo, así que no hay tokens de modelo. Skip-retry.
Firewall (retenido)firewall_approval_pending400Retenido para aprobación humana; el agente hace polling y reenvía una vez aprobado.
Ambos cuerpos de error tienen forma de OpenAI y nombran la política y la razón, así que tu agente puede ramificar según el código. Ver las referencias profundas para el registro completo del evento y cómo se registran las coincidencias.

​
5. Dónde ir a continuación

Alcance y claves

El modelo completo de tres niveles — espacio de trabajo, política, clave — y cada campo que lleva una clave.

El objeto token

Cada campo en una clave: model_limits, allow_ips, credit_limit_usd, expired_time, y los dos adjuntos de política.

Guardrails

Autora la política de contenido que vinculas vía guardrail_id — reglas, entidades PII, acciones y presets.

Firewall

Autora la política de llamadas a herramienta que vinculas vía firewall_policy_id — veredictos, superficies y niveles de autonomía.
¿Quieres establecer toda la postura de tu espacio de trabajo de una sola vez en vez de vincular claves una por una? Un nivel de autonomía escribe ambos planos — guardrails y firewall — a la vez. Luego adjunta políticas más estrictas en las pocas claves que necesitan ir más allá del valor por defecto del espacio de trabajo. Ver Guardrails vs Firewall.