Vai al contenuto principale
Puoi collegare un guardrail a una singola chiave API, ma la maggior parte dei team vuole un pavimento: una content policy che si applica a ogni chiave nel workspace a meno che una chiave non opti per qualcos’altro. Quel pavimento è il default del workspace — un guardrail, marcato is_default, a cui il gateway fa fallback ogni volta che una chiave non ha un collegamento esplicito. Questa pagina copre il guardrail AI di default: come impostarlo, come funziona la risoluzione e l’unico invariante che vale la pena memorizzare — un default per workspace. Per il riferimento completo del motore, vedi il riferimento Guardrails.
Tutto qui è un’azione di console sul gateway gestito (api.orcarouter.ai), eseguita sotto la tua sessione. Solo la chiamata /v1/* finale usa una chiave di relay sk-orca-.... Promuovere o declassare un guardrail di default richiede Developer+ nel workspace.

​
1. Perché impostare un guardrail AI di default

Il collegamento per chiave è preciso ma facile da dimenticare — emetti una nuova chiave, salti il menu a tendina, e quella chiave parte con zero filtri. Un default del workspace chiude quella lacuna:

Le chiavi senza collegamento lo ereditano

Qualsiasi chiave il cui guardrail_id non è impostato (0/null) viene filtrata dal default automaticamente — incluse le chiavi create dopo che lo imposti.

Modifica una volta, sposta l'intero workspace

Il default vive nel gateway, non su ogni chiave. Modificalo e ogni chiave che lo eredita si sposta alla chiamata successiva — nessun redeploy, nessuna modifica all’SDK.
Un pattern comune: rendi un conservativo PII Shield il default del workspace così che nulla trapeli per caso, poi lascia che chiavi specifiche colleghino una policy più rigida o più permissiva quando ne hanno bisogno.

​
2. Promuovi un guardrail al default

Nella console, apri Guardrails, modifica il guardrail che vuoi come pavimento e attiva Set as workspace default. Salva.
1

Crea o scegli un guardrail

Scrivi una policy come al solito — es. il preset PII Shield, una singola regola pii che maschera nello stage both.
2

Marcalo come default e salva

Attiva Set as workspace default e salva. Il flag is_default del guardrail si attiva.
3

Lascia le chiavi senza collegamento

Qualsiasi chiave senza guardrail esplicito ora eredita questo. Le chiavi che già puntano a un guardrail diverso mantengono il loro collegamento.
Il default deve anche essere abilitato per avere effetto. Un guardrail marcato is_default ma disabilitato si risolve a nessuna applicazione — il toggle e lo stato abilitato sono interruttori indipendenti.

​
3. Un default per workspace — la promozione è atomica

Questo è l’invariante: al massimo un guardrail per workspace porta is_default. Non devi mai disattivare manualmente il vecchio. Quando promuovi un nuovo guardrail a default, il gateway declassa il default precedente nella stessa transazione — la promozione e il declassamento o atterrano entrambi o nessuno dei due. Non c’è mai una finestra in cui due guardrails sono entrambi il default, e mai una finestra in cui nessuno lo è. 
Before:   billing-pii   ← is_default ✓
          legal-redact

Promote "legal-redact" to default
          (single transaction)
          ┌─────────────────────────────────────────┐
          │  legal-redact  → is_default = true       │
          │  billing-pii   → is_default = false       │
          └─────────────────────────────────────────┘

After:    billing-pii
          legal-redact  ← is_default ✓
Non devi declassare prima. Basta promuovere il nuovo — il vecchio default viene azzerato per te, atomicamente. Il guardrail declassato esiste ancora e resta abilitato; semplicemente non agisce più come fallback. Le chiavi collegate ad esso esplicitamente non sono interessate.
Lo stesso swap atomico si applica sia che tu promuova in fase di create (marca un guardrail nuovo di zecca come default) sia in fase di edit (porta il flag su un esistente).

​
4. Come la risoluzione usa il default

Per ogni richiesta, il gateway risolve esattamente un guardrail (o nessuno) in quest’ordine fisso:
OrdineCosa si applica
1Il guardrail_id esplicito della chiave — se esiste ed è abilitato.
2Il guardrail is_default abilitato del workspace (la chiave non aveva collegamento).
3Nessuno — la richiesta è byte-identica a un workspace senza policy.
Un collegamento esplicito della chiave non fa mai fallback silenzioso al default. Se una chiave punta a un guardrail e quel guardrail è disabilitato, la chiave si risolve a nessuna applicazione — non al default del workspace. Disabilitare un guardrail collegato è l’interruttore di spegnimento per quella chiave. (Le policy del firewall si comportano diversamente qui — una policy del firewall collegata disabilitata fa fallback al default del workspace. Vedi Guardrails vs. firewall.)
Quindi il default è il fallback solo per le chiavi senza collegamento. Non sovrascrive mai una chiave che ha fatto una scelta esplicita.
Fail-open by design. Se la risoluzione del default incontra un errore transitorio, il gateway degrada a nessuna applicazione anziché far fallire la richiesta. La sicurezza degrada; la disponibilità è preservata.

​
5. Esempio svolto

Supponi che il tuo workspace abbia due guardrails e tre chiavi:
  • pii-shield — marcato default del workspace, abilitato.
  • strict-block — blocca le carte di credito, non default.
  • Chiave A — nessun collegamento. Chiave B — collegata a strict-block. Chiave C — collegata a un guardrail che hai poi disabilitato.
Una richiesta che menziona un’email si risolve così:
guardrail_id non è impostato, quindi la risoluzione scende al guardrail is_default abilitato pii-shield. L’email è mascherata in [EMAIL] prima che il modello la veda.
Il collegamento esplicito vince. Si applica strict-block; il default non viene mai consultato.
Il collegamento esiste ma il suo guardrail è disabilitato, quindi la risoluzione restituisce nessuno — non scende a pii-shield. La richiesta è non filtrata.
Ora promuovi strict-block a default e salva. In una transazione strict-block.is_default diventa true e pii-shield.is_default diventa false. La chiave A eredita immediatamente strict-block alla sua chiamata successiva — senza alcuna modifica alla chiave stessa.

​
6. Confermare che la richiesta colpisce il default

Invia una richiesta con una chiave senza collegamento e controlla il feed dei Matches — un match registrato sotto il tuo guardrail di default conferma che il fallback è scattato: 
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": "Reply to jane@acme.com please"}
    ]
  }'
Se il default è una policy PII di masking, il gateway riscrive l’email in [EMAIL] prima di inoltrare. Se blocca, la chiamata restituisce HTTP 400 guardrail_blocked — che non costa quota ed è marcata skip-retry. Vedi l’ errore guardrail_blocked per la forma completa della risposta.
Vuoi dimostrare il comportamento del default prima che qualsiasi chiave vi faccia affidamento? Apri la tab Test nell’editor del guardrail ed esegui un campione nello stage input — nessuna chiamata upstream, nessuna quota. Vedi Testing ed eval.

​
7. Dove andare dopo

Collega a una singola chiave

Quando una chiave ha bisogno di una policy diversa dal pavimento del workspace.

Crea il tuo primo guardrail

Il loop end-to-end — crea, testa, collega, invia.

Risoluzione e scope

Come chiavi, policy e workspace si compongono.

Versioning

Ogni promozione scrive una riga di cronologia — confronta e ripristina.
Promuovere o declassare il default è esso stesso una modifica versionata — apri History sul guardrail per vedere quando is_default è cambiato e chi l’ha fatto. Per il motore completo, leggi il riferimento Guardrails.