Saltar para o conteúdo principal
Você tem uma lista de termos que nunca devem chegar a um modelo ou voltar de um — o nome de um concorrente, um codinome interno, um insulto banido, um produto ainda não anunciado. O controle mais rápido para isso é uma denylist de keyword: uma lista de termos literais que o gateway varre em cada chamada e então bloqueia, mascara ou sinaliza. Este é um destino focado no caso de uso de termos banidos. Para o motor de guardrail completo — cada tipo de regra, campo e rota — veja a referência de Guardrails.

​
1. O caso de uso de filtro de palavras sensíveis no ai

Uma regra keyword é a regra mais simples do motor: você dá a ela uma lista de termos, e o gateway corresponde qualquer um deles contra o texto em um estágio. A correspondência é por substring sem distinção entre maiúsculas e minúsculas — BadWord, badword e BADWORD todos correspondem, e o termo corresponde mesmo quando está embutido em uma palavra mais longa (então class também corresponde a classic). Cada termo é tratado como uma string literal, não um padrão; você não escapa metacaracteres de regex. Salve a regra uma vez no console, vincule o guardrail a qualquer chave de API (ou faça dele o padrão do workspace), e cada chamada nessa chave é filtrada sem mudança de SDK e sem redeploy. A política vive no gateway, não na sua aplicação — sua app continua chamando /v1/chat/completions exatamente como antes.
Recorra a uma regra keyword quando sua denylist é um conjunto finito de termos literais. Quando você precisa de curingas, limites de palavra ou estrutura (um formato de SKU, uma forma de número de pedido), use um detector regex em vez disso.

​
2. Escreva a regra no console

Cada passo aqui é uma ação de console sob sua própria sessão. Criar e editar guardrails exige Developer+ no workspace. Apenas a chamada final /v1/* usa uma chave de relay sk-orca-....
1

Crie um guardrail

No console, abra Guardrails e clique em New guardrail. Nomeie-o (≤ 64 chars), ex.: banned-terms.
2

Adicione uma regra de keyword

Adicione uma regra:
  • Tipo: Keyword denylist (keyword)
  • Estágio: Both (requisição e resposta)
  • Ação: Block
  • Keywords: seus termos banidos, um por linha
Salve.
3

Teste-o

Abra a aba Test, cole uma amostra que contenha um termo banido, escolha um estágio e rode a política localmente — sem chamada upstream, sem cota (veja §5).
4

Vincule uma chave

Edite uma chave de API e escolha banned-terms no menu Guardrail (define guardrail_id na chave), ou marque o guardrail como padrão do workspace. Veja Vincular a uma chave e Padrão de conta.
O JSON da regra é exatamente o que você esperaria: 
{
  "type": "keyword",
  "stage": "both",
  "action": "block",
  "keywords": ["project-orca", "competitor-name", "unannounced-sku"]
}

​
3. Escolha a ação

Uma regra de keyword escolhe uma ação por regra:
Qualquer correspondência rejeita a requisição com HTTP 400 guardrail_blocked. Uma requisição bloqueada não custa cota — um block no estágio de input dispara antes da medição; um block no estágio de output reembolsa a cota pré-consumida — e é marcada como skip-retry. Use-o para termos que nunca devem passar em nenhuma direção. Veja o erro guardrail_blocked.
Cada correspondência é substituída no lugar por uma tag de redação e a requisição continua com o texto sanitizado — o modelo upstream nunca vê o termo original. Veja Ações.
Registra um match e não muda nada no tráfego. Use-o para medir com que frequência um termo aparece antes de mudar para enforcement.
Envolve o texto correspondente em delimitadores (ex.: ⟦UNTRUSTED⟧…⟦/UNTRUSTED⟧) para que o modelo o trate como dados, não instruções — uma defesa de prompt-injection no estágio de input. O texto ainda chega ao modelo, apenas cercado. Veja Ações.
O estágio importa. input varre a requisição do chamador, output varre a resposta do modelo, both varre cada lado independentemente. Um termo banido que seus usuários digitam e um que um modelo pode emitir são problemas diferentes — escolha o(s) estágio(s) que se encaixam. Veja Regras de estágio de input e Regras de estágio de output.

​
4. Cobertura de streaming

A ação que você escolhe interage com o fato de a resposta fazer streaming:
AçãoNão-streamingStreaming
block (output)AplicadoAplicado — scanner corta o stream
mask (output)AplicadoAinda não — decisão de block honrada, texto mascarado não encaminhado (roadmap)
As regras de estágio de input rodam antes da chamada upstream, então não são afetadas pelo streaming — um mask de input sanitiza a requisição quer a resposta faça streaming ou não. Um block de termo banido recebe cobertura completa de qualquer forma. Um mask de output, no entanto, só redige em respostas não-streaming hoje: em uma resposta streaming o scanner ainda age sobre a decisão de block, mas a reescrita in-band do texto transmitido está no roadmap, não ativa. Veja Cobertura de streaming.

​
5. Teste antes de vincular

Prove que a regra faz o que você espera antes que qualquer chave aponte para ela. Abra a aba Test dentro do editor, cole uma amostra, escolha o estágio e rode: 
Tell me about Project-Orca and our competitor-name
O sandbox avalia a política atual localmente e retorna o veredito — nada é enviado upstream, nada é medido. Com uma ação block a amostra é rejeitada; com mask o texto renderizado volta com cada termo redigido. Para uma grade A/B contra um corpus — para confirmar que uma denylist pega o que deveria sem sinalizar tráfego benigno — o Eval harness fica uma aba ao lado.

​
6. Envie uma requisição

Usando uma chave vinculada a banned-terms, chame o OrcaRouter exatamente como antes — sem novos headers, sem mudança de SDK: 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Summarize Project-Orca for me"}
    ]
  }'
Com uma ação block a chamada é rejeitada com HTTP 400 guardrail_blocked antes de sequer chegar ao modelo. Troque a ação para mask e o termo é redigido no lugar antes de encaminhar.

​
7. Veja o que disparou

Toda regra que dispara registra um match — tipo de regra, ação, estágio e uma string de detalhe (para regras de keyword, quantos termos corresponderam) — exibido no feed Matches do workspace.
O termo correspondente em si é registrado apenas quando Log raw content está ligado, que está desligado por padrão — a postura conservadora de privacidade. Com ele desligado você ainda vê que uma regra de keyword disparou e com que frequência, apenas não o termo literal. Ligue-o por guardrail quando precisar da substring para triagem; a configuração não é retroativa. Veja Feed de matches e Logging e privacidade.
Se um termo benigno continuar correspondendo (uma entrada de denylist que é substring de uma palavra comum), marque-o como falso positivo a partir do feed de Matches e aperte a entrada. Veja Ajustar falsos positivos.

​
8. Para onde ir a seguir

Detectores regex

Corresponda a padrões estruturados — SKUs, números de pedido, formatos — quando uma denylist literal não basta.

Brand safety

Presets de palavrões, menções a concorrentes e segurança infantil construídos sobre regras de keyword.

Ações

Como block, mask e flag diferem e quando usar cada um.

Referência de Guardrails

O motor completo — cada tipo de regra, campo e rota.
Uma denylist de keyword governa conteúdo. Para governar as chamadas de ferramenta de um agente — negar ações destrutivas, redigir argumentos de chamada de ferramenta, exigir aprovação — use o Firewall. Para políticas difusas que nenhuma lista literal consegue expressar (toxicidade, fora de tópico, intenção de injeção), uma regra llm_judge roda uma verificação semântica contra um modelo do workspace.