Zum Hauptinhalt springen
Sie können ein Guardrail an einen einzelnen API-Key anhängen, aber die meisten Teams wollen einen Boden: eine Content-Policy, die für jeden Key im Workspace gilt, sofern ein Key sich nicht für etwas anderes entscheidet. Dieser Boden ist der Workspace-Default — ein Guardrail, markiert als is_default, auf das das Gateway zurückfällt, wann immer ein Key keine explizite Bindung hat. Diese Seite behandelt das Default-KI-Guardrail: wie man es setzt, wie die Auflösung funktioniert und die eine Invariante, die man sich merken sollte — ein Default pro Workspace. Die vollständige Engine-Referenz finden Sie in der Guardrails-Referenz.
Alles hier ist eine Konsolen-Aktion auf dem gehosteten Gateway (api.orcarouter.ai), ausgeführt unter Ihrer eigenen Session. Nur der finale /v1/*-Aufruf verwendet einen sk-orca-...-Relay-Key. Das Promoten oder Degradieren eines Default-Guardrails erfordert Developer+ im Workspace.

​
1. Warum ein Default-KI-Guardrail setzen

Die Pro-Key-Bindung ist präzise, aber leicht zu vergessen — geben Sie einen neuen Key aus, überspringen Sie das Dropdown, und dieser Key wird mit null Prüfung ausgeliefert. Ein Workspace-Default schließt diese Lücke:

Keys ohne Bindung erben es

Jeder Key, dessen guardrail_id nicht gesetzt ist (0/null), wird automatisch vom Default geprüft — einschließlich Keys, die nach dem Setzen erstellt wurden.

Einmal bearbeiten, den ganzen Workspace verschieben

Der Default lebt im Gateway, nicht auf jedem Key. Bearbeiten Sie ihn, und jeder erbende Key verschiebt sich beim nächsten Aufruf — kein Redeploy, keine SDK-Änderung.
Ein gängiges Muster: machen Sie ein konservatives PII Shield zum Workspace-Default, sodass nichts versehentlich leakt, und lassen Sie dann bestimmte Keys eine striktere oder lockerere Policy anhängen, wenn sie eine brauchen.

​
2. Ein Guardrail zum Default promoten

Öffnen Sie in der Konsole Guardrails, bearbeiten Sie das Guardrail, das Sie als Boden möchten, und aktivieren Sie Set as workspace default. Speichern.
1

Ein Guardrail erstellen oder wählen

Verfassen Sie eine Policy wie gewohnt — z. B. das PII Shield-Preset, eine einzelne pii-Regel, die an der both-Stage maskiert.
2

Als Default markieren und speichern

Schalten Sie Set as workspace default ein und speichern Sie. Das is_default-Flag des Guardrails kippt auf an.
3

Keys ohne Bindung lassen

Jeder Key ohne explizites Guardrail erbt nun dieses. Keys, die bereits auf ein anderes Guardrail zeigen, behalten ihre Bindung.
Der Default muss auch aktiviert sein, um zu wirken. Ein als is_default markiertes, aber deaktiviertes Guardrail löst auf keine Durchsetzung auf — der Toggle und der aktivierte Zustand sind unabhängige Schalter.

​
3. Ein Default pro Workspace — das Promoten ist atomar

Das ist die Invariante: höchstens ein Guardrail pro Workspace trägt is_default. Sie müssen das alte nie manuell zurücksetzen. Wenn Sie ein neues Guardrail zum Default promoten, degradiert das Gateway den vorherigen Default in derselben Transaktion — das Promoten und das Degradieren landen entweder beide oder keines. Es gibt nie ein Fenster, in dem zwei Guardrails beide der Default sind, und nie ein Fenster, in dem keines es ist. 
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 ✓
Sie müssen nicht zuerst degradieren. Promoten Sie einfach das neue — der alte Default wird für Sie atomar geleert. Das degradierte Guardrail existiert weiterhin und bleibt aktiviert; es agiert nur nicht mehr als Fallback. Keys, die explizit daran angehängt sind, bleiben unberührt.
Derselbe atomare Tausch gilt, egal ob Sie beim Erstellen promoten (ein brandneues Guardrail als Default markieren) oder beim Bearbeiten (das Flag auf einem bestehenden kippen).

​
4. Wie die Auflösung den Default verwendet

Für jede Anfrage löst das Gateway genau ein Guardrail (oder keines) in dieser festen Reihenfolge auf:
ReihenfolgeWas gilt
1Die explizite guardrail_id des Keys — sofern sie existiert und aktiviert ist.
2Das aktivierte is_default-Guardrail des Workspaces (Key hatte keine Bindung).
3Keines — die Anfrage ist byte-identisch zu einem Workspace ohne Policy.
Eine explizite Key-Bindung fällt nie stillschweigend auf den Default zurück. Wenn ein Key auf ein Guardrail zeigt und dieses Guardrail deaktiviert ist, löst der Key auf keine Durchsetzung auf — nicht auf den Workspace-Default. Das Deaktivieren eines angehängten Guardrails ist der Aus-Schalter für diesen Key. (Firewall-Policies verhalten sich hier anders — eine deaktivierte angehängte Firewall-Policy fällt sehr wohl auf den Workspace-Default zurück. Siehe Guardrails vs. Firewall.)
Der Default ist also der Fallback nur für nicht gebundene Keys. Er überschreibt nie einen Key, der eine explizite Wahl getroffen hat.

​
5. Durchgespieltes Beispiel

Angenommen, Ihr Workspace hat zwei Guardrails und drei Keys:
  • pii-shield — als Workspace-Default markiert, aktiviert.
  • strict-block — blockiert Kreditkarten, nicht Default.
  • Key A — keine Bindung. Key B — an strict-block angehängt. Key C — an ein Guardrail angehängt, das Sie später deaktiviert haben.
Ein Request, der eine E-Mail erwähnt, löst so auf:
guardrail_id ist nicht gesetzt, daher fällt die Auflösung auf das aktivierte is_default-Guardrail pii-shield durch. Die E-Mail wird zu [EMAIL] maskiert, bevor das Modell sie sieht.
Die explizite Bindung gewinnt. strict-block gilt; der Default wird nie konsultiert.
Die Bindung existiert, aber ihr Guardrail ist deaktiviert, daher gibt die Auflösung keines zurück — sie fällt nicht auf pii-shield durch. Die Anfrage ist ungeprüft.
Promoten Sie nun strict-block zum Default und speichern Sie. In einer Transaktion wird strict-block.is_default zu true und pii-shield.is_default zu false. Key A erbt sofort bei seinem nächsten Aufruf strict-block — ohne jede Änderung am Key selbst.

​
6. Bestätigen, dass der Request den Default trifft

Senden Sie einen Request mit einem nicht gebundenen Key und prüfen Sie den Matches-Feed — ein unter Ihrem Default-Guardrail aufgezeichneter Match bestätigt, dass der Fallback gefeuert hat: 
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"}
    ]
  }'
Wenn der Default eine maskierende PII-Policy ist, schreibt das Gateway die E-Mail vor dem Weiterleiten zu [EMAIL] um. Wenn er blockiert, gibt der Aufruf HTTP 400 guardrail_blocked zurück — was kein Kontingent kostet und als skip-retry markiert wird. Siehe den guardrail_blocked-Fehler für die vollständige Response-Form.
Möchten Sie das Verhalten des Defaults beweisen, bevor sich ein Key darauf verlässt? Öffnen Sie den Tab Test im Guardrail-Editor und führen Sie ein Sample an der input-Stage aus — kein Upstream-Aufruf, kein Kontingent. Siehe Testing & Eval.

​
7. Wohin als Nächstes

An einen einzelnen Key anhängen

Wenn ein Key eine andere Policy als der Workspace-Boden braucht.

Ihr erstes Guardrail erstellen

Die End-to-End-Schleife — erstellen, testen, anhängen, senden.

Auflösung & Scope

Wie Keys, Policies und Workspaces komponieren.

Versionierung

Jedes Promoten schreibt eine Historie-Zeile — diffen und reverten.
Das Promoten oder Degradieren des Defaults ist selbst eine versionierte Änderung — öffnen Sie History auf dem Guardrail, um zu sehen, wann is_default gekippt ist und wer es getan hat. Für die vollständige Engine lesen Sie die Guardrails-Referenz.