Zum Hauptinhalt springen
Sie haben ein gespeichertes Guardrail und möchten, dass ein bestimmter API-Key dadurch geprüft wird — nicht der gesamte Workspace. Genau dafür ist die Guardrail-pro-API-Key-Bindung da: setzen Sie guardrail_id auf dem Key, und jeder /v1/*-Aufruf, der mit diesem Key getätigt wird, wird beim nächsten Request geprüft, ohne Redeploy und ohne SDK-Änderung. Diese Seite behandelt nur die Bindung — wie man anhängt, wie die Auflösung die effektive Policy wählt und was der Aus-Schalter tut. Für die Regeltypen, Actions und Stages siehe die Guardrails-Referenz.

​
1. Ein Guardrail pro API-Key mit guardrail_id binden

Ein Guardrail ist workspace-bezogen, aber die Durchsetzung wird pro Key entschieden. Jeder API-Key trägt ein guardrail_id-Feld. Zeigen Sie es auf ein Guardrail, und dieser Key — und nur dieser Key — wird durch diese Policy geprüft. Damit kann ein Workspace verschiedene Policies auf verschiedenen Keys betreiben:
  • ein Produktions-Key, gebunden an ein striktes pii-blocker,
  • ein Staging-Key, gebunden an eine leichtere flag-only-Policy,
  • ein interner Key ohne etwas Angehängtes.
Die Bindung lebt am Key im Gateway, sodass das Bearbeiten des Guardrails den gebundenen Key bei seinem nächsten Request verschiebt. Ihre Anwendung ruft https://api.orcarouter.ai/v1/chat/completions weiterhin genau wie zuvor auf.
Der Relay-Key (sk-orca-…) ist das, was Ihre App sendet. Ein Guardrail an ihn anzuhängen ist eine Konsolen-/Token-API-Aktion, die durch Ihre Session authentifiziert wird — Sie konfigurieren ein Guardrail nie mit dem Relay-Key selbst.

​
2. In der Konsole anhängen

Konfigurieren Sie die Bindung in der Konsole (rollengesteuert: das Bearbeiten von Keys und Guardrails erfordert Developer+).
1

Den Key öffnen

Gehen Sie zu /console/token und erstellen oder bearbeiten Sie den API-Key, den Sie prüfen lassen möchten.
2

Das Guardrail wählen

Wählen Sie im Key-Editor Ihr Guardrail aus dem Dropdown Guardrail. Dies setzt guardrail_id auf dem Key.
3

Speichern

Die Bindung wird beim nächsten Request dieses Keys wirksam. Kein Redeploy.
Danach wird ein normaler Relay-Aufruf mit dem gebundenen Key automatisch geprüft: 
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 das gebundene Guardrail E-Mail an der Input-Stage maskiert, sieht das Upstream-Modell [EMAIL] und nie die Adresse — derselbe Aufruf, keine Client-Änderung.
Um jeden Key im Workspace statt eines einzelnen zu prüfen, setzen Sie das Guardrail als Workspace-Default, statt jeden Key zu binden. Siehe Account-Default-Guardrail.

​
3. Wie die Auflösung das effektive Guardrail wählt

Bei jedem Request löst das Gateway genau ein effektives Guardrail (oder keines) in dieser Reihenfolge auf:
Wenn die guardrail_id des Keys auf ein Guardrail zeigt und dieses Guardrail existiert und aktiviert ist, gilt es. Eine explizite Bindung ist maßgeblich — sie fällt nie stillschweigend auf den Workspace-Default zurück.
Wenn der Key keine Bindung hat (guardrail_id ist 0 / nicht gesetzt), gilt das aktivierte Default-Guardrail des Workspaces, sofern eines gesetzt ist.
Keine Durchsetzung. Die Anfrage ist byte-identisch zu einem Workspace, der das Feature nie aktiviert hat — nichts blockiert, maskiert oder geloggt.
Die Entscheidung ist ein indizierter Lookup auf dem heißen Pfad und ist fail-open: stößt die Auflösung auf einen transienten Fehler, degradiert das Gateway zu keiner Durchsetzung, anstatt die Anfrage scheitern zu lassen. Die Sicherheit degradiert; die Verfügbarkeit bleibt erhalten.

​
4. Der Aus-Schalter: eine Bindung deaktivieren, kein Fallback

Das ist der Teil, den die Leute übersehen. Eine explizite Key-Bindung ist ihre eigene Autorität — daher schaltet das Deaktivieren des angehängten Guardrails die Durchsetzung für diesen Key AUS, und es fällt nicht auf den Workspace-Default zurück.
Key-ZustandWas den Request prüft
guardrail_id → aktiviertes Guardraildieses Guardrail
guardrail_id → deaktiviertes Guardrailnichts (kein Fallback)
guardrail_id → gelöscht / fehlendnichts (kein Fallback)
guardrail_id = 0 / nicht gesetztWorkspace-Default, falls vorhanden
Das Deaktivieren eines angehängten Guardrails ist der Aus-Schalter für diesen Key, kein Downgrade auf den Default. Wenn Sie möchten, dass ein Key auf den Workspace-Default zurückfällt, löschen Sie seine Bindung (setzen Sie guardrail_id auf 0) — deaktivieren Sie nicht einfach das Guardrail, auf das er zeigt.
Dies ist ein bewusster Unterschied zur Firewall: ein Key mit einer deaktivierten angehängten Firewall-Policy fällt auf die Workspace-Default-Firewall-Policy zurück, während ein deaktiviertes angehängtes Guardrail auf keines auflöst. Gleiche Idee, entgegengesetzter Fallback — siehe Guardrails vs. Firewall.

​
5. Die Bindung lösen oder löschen

Um einen Key nicht länger mit einem bestimmten Guardrail zu prüfen, haben Sie zwei unterschiedliche Schritte mit verschiedenen Ergebnissen:
  • Die Bindung löschen — setzen Sie die guardrail_id des Keys auf 0. Der Key löst nun auf den Workspace-Default auf (falls einer existiert) oder auf keines.
  • Das Guardrail deaktivieren — schalten Sie das enabled des Guardrails aus. Jeder Key, der explizit daran angehängt ist, löst nun auf keines auf (gemäß §4), während Keys, die sich darauf als Workspace-Default verließen, auf keine Durchsetzung durchfallen.
Wählen Sie löschen, wenn Sie den Key auf der Workspace-Baseline möchten; wählen Sie deaktivieren, wenn Sie diese Policy überall dort pausieren möchten, wo sie die benannte Bindung ist.

​
6. Was ein geprüfter Request kostet (und nicht kostet)

Sobald ein Guardrail auflöst, entscheiden seine Regeln über die Anfrage. Die zwei Ergebnisse, die man für einen gebundenen Key kennen sollte:
  • Ein block gibt HTTP 400 mit dem Fehlercode guardrail_blocked zurück und benennt das Guardrail und die ausgelöste Regel. Es kostet kein Kontingent — ein Block der Input-Stage feuert vor der Messung, ein Block der Output-Stage erstattet das vorab verbrauchte Kontingent zurück — und wird als skip-retry markiert.
  • Ein mask schreibt den Treffer zu einem typisierten Tag um (z. B. [EMAIL]) und lässt die Anfrage bereinigt durch; das Upstream-Modell sieht das Original nie.
Siehe die Seite zum guardrail_blocked-Fehler für die exakte Response-Form und Streaming-Abdeckung dazu, wie sich Output-Regeln bei gestreamten Responses verhalten.

​
7. Wohin als Nächstes

Ihr erstes Guardrail erstellen

Bauen Sie die Policy, die Sie an einen Key binden.

Account-Default-Guardrail

Jeden Key im Workspace auf einmal prüfen.

Guardrails-Referenz

Regeltypen, Actions, Stages, PII, Judge, Grounding.

Keys, Policies & Workspaces

Wie Bindungen über das Gateway gescoped werden.