Saltar para o conteúdo principal
Você criou um guardrail e uma política de firewall para o seu workspace. Agora você quer que esta única chave — a que o seu agente de finanças usa — rode uma política de conteúdo mais rígida e uma allow-list de ferramentas mais estreita que o resto do workspace. É isso que os dois campos de anexo de uma chave fazem: vincular um guardrail e uma política de firewall a uma única chave, e cada requisição que essa chave faz é triada e enforçada por exatamente essas políticas — sem mudança no código do agente, sem redeploy. Esta página cobre os dois campos, como eles resolvem no momento da requisição, e a única regra de resolução que pega as pessoas: um anexo de firewall desabilitado se comporta de forma diferente de um anexo de guardrail desabilitado.

​
1. A política de segurança por chave: dois campos em uma chave

Um guardrail triaga o texto que flui através de um modelo (PII, segredos, jailbreaks). Uma política de firewall governa as chamadas de ferramenta que um agente emite (quais ferramentas, quais servidores MCP, quais hosts). Ambos são políticas nomeadas, com escopo de workspace — criadas uma vez, compartilhadas no workspace — e uma chave opta por uma específica através de dois campos:
CampoVinculaDefine no console
guardrail_idO guardrail que triaga os prompts e respostas desta chave.Developer+
firewall_policy_idA política de firewall que avalia as chamadas de ferramenta desta chave.Developer+
Ambos são definidos no editor de chave em /console/token. Definir qualquer um deles é uma ação de Developer+ — as próprias políticas também são criadas como Developer+ (veja Escopo e chaves).
Esses dois campos são independentes. Uma chave pode anexar um guardrail e não uma política de firewall, o inverso, ambos ou nenhum — cada plano resolve por conta própria. Deixar um campo sem definir (0) não é o mesmo que desligar o enforcement; veja §3.

​
2. Um exemplo concreto

Digamos que o guardrail padrão do seu workspace sinaliza PII mas a deixa passar, e a política de firewall padrão audita cada chamada de ferramenta. Isso está bom para a maioria dos agentes — mas o seu agente de finanças lida com SSNs de clientes e nunca deveria chamar uma ferramenta de shell. Crie um finance-guardrail mais rígido (bloqueia PII de vez) e um finance-firewall (allow-list só das três ferramentas de que precisa), depois vincule ambos à chave desse agente: 
# Configure via o CONSOLE (UserAuth — sua sessão), não uma chave de relay.
# Esta é a chamada de atualização de chave que o editor em /console/token faz.
PUT /api/token
{
  "id": 4127,
  "name": "finance-agent",
  "guardrail_id": 12,          // finance-guardrail (PII = block)
  "firewall_policy_id": 8      // finance-firewall (allow-list de 3 ferramentas)
}
Da próxima requisição em diante, o tráfego dessa chave é triado pelo guardrail 12 e suas chamadas de ferramenta são avaliadas pela política 8 — enquanto toda outra chave no workspace continua rodando os padrões do workspace. O próprio código do agente nunca muda; ele continua chamando https://api.orcarouter.ai/v1/... com a sua chave sk-orca-… exatamente como antes.
Este é o padrão de menor agência: uma chave de escopo estreito por agente, cada uma vinculada às políticas que o seu trabalho realmente precisa. Quando esse agente é comprometido, o raio de explosão é o que quer que a sua chave estivesse autorizada a fazer — nada mais. Veja o checklist de menor agência.

​
3. Resolução: a regra que pega as pessoas

Para cada requisição, o gateway resolve o guardrail ativo e a política de firewall ativa independentemente. A ordem parece a mesma para ambos — anexo primeiro, padrão do workspace segundo — mas eles divergem em um caso.

​
Resolução de guardrail

O guardrail_id da chave aponta para um guardrail que existe e está habilitado. Esse guardrail triaga a requisição.
Desabilitar o guardrail anexado é um interruptor de desligar. A chave não recebe nenhuma triagem de conteúdo — ela não cai de volta para o padrão do workspace. Isso é deliberado: anexar um guardrail e desabilitá-lo é como você desliga a triagem para aquela chave.
Nenhum guardrail_id na chave. O guardrail padrão habilitado do workspace se aplica, se houver um definido.
Nenhum anexo e nenhum padrão do workspace → a requisição passa sem triagem de conteúdo.

​
Resolução de firewall

O firewall_policy_id da chave aponta para uma política que existe e está habilitada. Essa política avalia as chamadas de ferramenta da chave.
Aqui está a diferença. Um anexo de firewall desabilitado cai de volta para a política de firewall padrão do workspace — ele não desliga o enforcement. Desabilitar um anexo de firewall reverte a chave para o padrão do workspace; não deixa a chave desprotegida.
Nenhum firewall_policy_id na chave → a política de firewall padrão habilitada do workspace se aplica.
Desabilitar uma política anexada não é simétrico. Um anexo de guardrail desabilitado significa nenhum guardrail para aquela chave. Um anexo de firewall desabilitado significa cair de volta para o padrão do workspace. Se você quer que uma chave genuinamente não rode nenhum enforcement de firewall, você não consegue chegar lá desabilitando o seu anexo — certifique-se de que nenhuma política de firewall padrão do workspace esteja definida (ou dê escopo à chave para que ela não emita chamadas de ferramenta governadas).
No máximo um guardrail e uma política de firewall por workspace podem ser o padrão a qualquer momento; promover um novo padrão rebaixa o antigo na mesma transação, então você nunca pode ter dois acidentalmente.

​
4. Como é um bloqueio

Quando uma política vinculada nega uma requisição, o chamador vê um erro estruturado — o agente pode reagir em vez de quebrar:
PlanoCódigo de erroHTTPCusto
Guardrailguardrail_blocked400Nenhum — um bloqueio de input dispara antes da medição; um bloqueio de output reembolsa. Marcado skip-retry.
Firewall (inbound)firewall_blocked400Um bloqueio inbound dispara antes da chamada ao modelo, então sem tokens de modelo. Skip-retry.
Firewall (retido)firewall_approval_pending400Retido para aprovação humana; o agente faz polling e reenvia uma vez aprovado.
Ambos os corpos de erro têm formato OpenAI e nomeiam a política e o motivo, para que o seu agente possa ramificar com base no código. Veja as referências profundas para o registro de evento completo e como as correspondências são registradas.

​
5. Para onde ir a seguir

Escopo e chaves

O modelo completo de três níveis — workspace, política, chave — e cada campo que uma chave carrega.

O objeto token

Cada campo em uma chave: model_limits, allow_ips, credit_limit_usd, expired_time e os dois anexos de política.

Guardrails

Crie a política de conteúdo que você vincula via guardrail_id — regras, entidades de PII, ações e presets.

Firewall

Crie a política de chamada de ferramenta que você vincula via firewall_policy_id — vereditos, superfícies e níveis de autonomia.
Quer definir toda a postura do seu workspace em um único movimento em vez de vincular chaves uma a uma? Um nível de autonomia escreve ambos os planos — guardrails e firewall — de uma vez. Depois anexe políticas mais rígidas nas poucas chaves que precisam ir além do padrão do workspace. Veja Guardrails vs. Firewall.