Vai al contenuto principale
Hai un elenco di termini che non devono mai raggiungere un modello o tornare da esso — il nome di un concorrente, un nome in codice interno, un insulto vietato, un prodotto non ancora annunciato. Il controllo più rapido per questo è una denylist di keyword: un elenco di termini letterali che il gateway scansiona a ogni chiamata e poi blocca, maschera o segnala. Questa è una landing focalizzata sul caso d’uso dei termini vietati. Per il motore di guardrail completo — ogni tipo di regola, campo e rotta — vedi il riferimento Guardrails.

​
1. Il caso d’uso del filtro di parole sensibili ai

Una regola keyword è la regola più semplice del motore: le dai un elenco di termini, e il gateway fa corrispondere uno qualsiasi di essi al testo in uno stage. Il matching è per sottostringa senza distinzione tra maiuscole e minuscole — BadWord, badword e BADWORD corrispondono tutti, e il termine corrisponde anche quando è incorporato in una parola più lunga (quindi class corrisponde anche a classic). Ogni termine è trattato come una stringa letterale, non come un pattern; non fai l’escape dei metacaratteri regex. Salva la regola una volta nella console, collega il guardrail a qualsiasi chiave API (o rendilo il default del workspace), e ogni chiamata su quella chiave viene filtrata senza modifiche all’SDK e senza redeploy. La policy vive nel gateway, non nella tua applicazione — la tua app continua a chiamare /v1/chat/completions esattamente come prima.
Ricorri a una regola keyword quando la tua denylist è un insieme finito di termini letterali. Quando ti servono wildcard, confini di parola o struttura (un formato SKU, una forma di numero d’ordine), usa invece un regex detector.

​
2. Scrivi la regola nella console

Ogni passaggio qui è un’azione di console sotto la tua sessione. Creare e modificare guardrails richiede Developer+ nel workspace. Solo la chiamata /v1/* finale usa una chiave di relay sk-orca-....
1

Crea un guardrail

Nella console, apri Guardrails e fai clic su New guardrail. Chiamalo (≤ 64 caratteri), es. banned-terms.
2

Aggiungi una regola keyword

Aggiungi una regola:
  • Type: Keyword denylist (keyword)
  • Stage: Both (richiesta e risposta)
  • Action: Block
  • Keywords: i tuoi termini vietati, uno per riga
Salva.
3

Testala

Apri la tab Test, incolla un campione che contiene un termine vietato, scegli uno stage ed esegui la policy localmente — nessuna chiamata upstream, nessuna quota (vedi §5).
4

Collega una chiave

Modifica una chiave API e scegli banned-terms dal menu a tendina Guardrail (imposta guardrail_id sulla chiave), o marca il guardrail come default del workspace. Vedi Collega a una chiave e Default di account.
Il JSON della regola è esattamente ciò che ti aspetteresti: 
{
  "type": "keyword",
  "stage": "both",
  "action": "block",
  "keywords": ["project-orca", "competitor-name", "unannounced-sku"]
}

​
3. Scegli l’azione

Una regola keyword sceglie un’azione per regola:
Qualsiasi match rifiuta la richiesta con HTTP 400 guardrail_blocked. Una richiesta bloccata non costa quota — un block nello stage di input scatta prima della misurazione; un block nello stage di output rimborsa la quota pre-consumata — ed è marcata skip-retry. Usalo per termini che non devono mai passare in nessuna direzione. Vedi l’ errore guardrail_blocked.
Ogni match viene sostituito sul posto con un tag di redazione e la richiesta continua con il testo sanitizzato — il modello upstream non vede mai il termine originale. Vedi Azioni.
Registra un match e non cambia nulla del traffico. Usalo per misurare quanto spesso un termine appare prima di passare all’applicazione.
Avvolge il testo corrispondente in delimitatori (es. ⟦UNTRUSTED⟧…⟦/UNTRUSTED⟧) così che il modello lo tratti come dati, non istruzioni — una difesa di prompt-injection nello stage di input. Il testo raggiunge comunque il modello, solo recintato. Vedi Azioni.
Lo stage conta. input scansiona la richiesta del chiamante, output scansiona la risposta del modello, both scansiona ogni lato indipendentemente. Un termine vietato che i tuoi utenti digitano e uno che un modello potrebbe emettere sono problemi diversi — scegli gli stage che si adattano. Vedi Regole dello stage di input e Regole dello stage di output.

​
4. Streaming coverage

L’azione che scegli interagisce con il fatto che la risposta sia in streaming:
AzioneNon streamingStreaming
block (output)ApplicatoApplicato — lo scanner interrompe lo stream
mask (output)ApplicatoNon ancora — decisione di block onorata, testo mascherato non inoltrato (roadmap)
Le regole dello stage di input girano prima della chiamata upstream, quindi non sono interessate dallo streaming — un mask di input sanitizza la richiesta che la risposta sia in streaming o meno. Un block di termine vietato ottiene copertura completa in entrambi i casi. Un mask di output, tuttavia, redige solo sulle risposte non in streaming oggi: su una risposta in streaming lo scanner agisce comunque sulla decisione di block, ma la riscrittura in-band del testo streamato è nella roadmap, non attiva. Vedi Streaming coverage.

​
5. Testa prima di collegare

Dimostra che la regola fa ciò che ti aspetti prima che qualsiasi chiave vi punti. Apri la tab Test all’interno dell’editor, incolla un campione, scegli lo stage ed esegui: 
Tell me about Project-Orca and our competitor-name
La sandbox valuta la policy corrente localmente e restituisce il verdetto — nulla viene inviato upstream, nulla viene misurato. Con un’azione block il campione viene rifiutato; con mask il testo renderizzato torna con ogni termine redatto. Per una griglia A/B contro un corpus — per confermare che una denylist cattura ciò che dovrebbe senza segnalare il traffico benigno — l’ harness di eval vive una tab più in là.

​
6. Invia una richiesta

Usando una chiave legata a banned-terms, chiama OrcaRouter esattamente come prima — nessun nuovo header, nessuna modifica all’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"}
    ]
  }'
Con un’azione block la chiamata viene rifiutata con HTTP 400 guardrail_blocked prima che raggiunga mai il modello. Cambia l’azione in mask e il termine viene invece redatto sul posto prima di inoltrare.

​
7. Vedi cosa è scattato

Ogni regola che scatta registra un match — tipo di regola, azione, stage e una stringa di detail (per le regole keyword, quanti termini hanno corrisposto) — fatto emergere nel feed Matches del workspace.
Il termine corrispondente stesso viene registrato solo quando Log raw content è attivo, che è disattivato per default — la postura conservativa sulla privacy. Con esso disattivato vedi comunque che una regola keyword è scattata e quanto spesso, solo non il termine letterale. Attivalo per ciascun guardrail quando ti serve la sottostringa per il triage; l’impostazione non è retroattiva. Vedi Feed dei match e Logging e privacy.
Se un termine benigno continua a corrispondere (una voce di denylist che è una sottostringa di una parola comune), segnalalo come falso positivo dal feed dei Matches e irrigidisci la voce. Vedi Tuning dei falsi positivi.

​
8. Dove andare dopo

Regex detector

Corrispondi a pattern strutturati — SKU, numeri d’ordine, formati — quando una denylist letterale non basta.

Brand safety

Preset di turpiloquio, menzioni di concorrenti e sicurezza dei minori costruiti su regole keyword.

Azioni

Come block, mask e flag differiscono e quando usare ciascuno.

Riferimento Guardrails

Il motore completo — ogni tipo di regola, campo e rotta.
Una denylist di keyword governa il contenuto. Per governare le chiamate a tool di un agent — negare azioni distruttive, redigere gli argomenti delle chiamate a tool, richiedere approvazione — usa il Firewall. Per policy sfumate che nessun elenco letterale può esprimere (tossicità, fuori tema, intento di injection), una regola llm_judge esegue un controllo semantico contro un modello del workspace.