Zum Hauptinhalt springen
Der schnellste Weg, eine Content-Policy vor jeden Modell-Aufruf zu stellen, ist ein Guardrail — eine workspace-bezogene, benannte Policy, die Sie einmal in der Konsole verfassen und an einen API-Key anhängen. Das Gateway prüft dann den Request-Input und den Modell-Output beim nächsten Aufruf, ohne Redeploy und ohne SDK-Änderung. Diese Seite durchläuft die End-to-End-Schleife: ein Guardrail erstellen, eine Regel hinzufügen, es in der Sandbox testen, an einen Key anhängen und einen echten Request senden. Die vollständige Engine-Referenz — jeder Regeltyp, jedes Feld, jede Route — finden Sie in der Guardrails-Referenz.
Jeder Schritt hier ist eine Konsolen-Aktion auf dem gehosteten Gateway (api.orcarouter.ai). Die Guardrail-Konfiguration läuft unter Ihrer eigenen Session; nur der finale /v1/*-Aufruf verwendet einen sk-orca-...-Relay-Key. Das Erstellen und Bearbeiten von Guardrails erfordert Developer+ im Workspace.

​
1. Wie Sie LLM-Guardrails in fünf Schritten hinzufügen

Hier ist die gesamte Schleife auf einen Blick — jeder Schritt wird unten ausgeführt.
1

Ein Guardrail erstellen

Öffnen Sie in der Konsole Guardrails und klicken Sie auf New guardrail. Geben Sie ihm einen Namen (≤ 64 Zeichen), z. B. pii-shield.
2

Eine Regel hinzufügen

Fügen Sie eine PII detection-Regel an der input-Stage mit der mask-Action hinzu.
3

In der Sandbox testen

Öffnen Sie den Tab Test, fügen Sie ein Sample ein und führen Sie die Policy lokal aus — kein Upstream-Aufruf, kein Kontingent.
4

An einen Key anhängen

Bearbeiten Sie einen API-Key und wählen Sie das Guardrail aus dem Dropdown Guardrail. Die Bindung lebt am Key.
5

Einen Request senden

Rufen Sie /v1/chat/completions mit diesem Key auf. Das Gateway wendet die Policy vor dem Weiterleiten an.

​
2. Das Guardrail erstellen

Öffnen Sie in der Konsole Guardrails und klicken Sie auf New guardrail. Ein Guardrail ist eine workspace-bezogene, benannte Content-Policy — eine geordnete Liste von Regeln, die das Gateway gegen den Request-Input und den Modell-Output ausführt. Benennen Sie es pii-shield und speichern Sie.
Der New guardrail-Splitbutton öffnet auch direkt in ein Template. Das PII Shield-Preset ist eine einzelne pii-Regel, die email, phone, ssn, credit_card und ip maskiert. Ein Preset anzuwenden ist ein Keim, keine Sperre — bearbeiten Sie es danach frei. Durchstöbern Sie die Preset-Templates für weitere Ausgangspunkte.

​
3. Eine Regel hinzufügen

Jede Regel entscheidet drei Dinge — wonach gesucht wird (ein Regeltyp), wo gesucht wird (eine Stage) und was zu tun ist (eine Action). Fügen Sie eine Regel hinzu:
  • Type: PII detection (pii)
  • Stage: Input (die Anfrage)
  • Action: Mask — den Treffer redigieren
  • Entities: email, phone, ssn
Bei einer mask-Action wird jeder Treffer durch einen typisierten Tag ersetzt — aus einer E-Mail wird [EMAIL], aus einer SSN wird [SSN]. Die sieben Regeltypen (keyword, regex, pii, max_chars, external, llm_judge, grounding) und die fünf Actions (block, mask, flag, annotate, spotlight) werden in der Referenz behandelt. Für dieses erste Guardrail genügt eine Masking-Regel.
Masking ist auf beiden Stages live. Input-Stage-Regeln maskieren die Anfrage, bevor das Modell sie je sieht; Output-Stage-Regeln maskieren die Antwort des Modells — bei nicht-streamenden Responses und Chunk für Chunk bei streamenden — bevor der Client sie empfängt. Block wird ebenfalls auf beiden Stages durchgesetzt. Wenn Sie Modell-Antworten gaten möchten, setzen Sie die Stage der Regel auf output (oder both); siehe Output-Stage-Regeln.

​
4. In der Sandbox testen

Bevor Sie das Guardrail an irgendeinen Key anhängen, beweisen Sie, dass es tut, was Sie erwarten. Öffnen Sie den Tab Test im Editor, fügen Sie ein Sample ein, wählen Sie die input-Stage und führen Sie aus: 
Reply to jane@acme.com please
Die Sandbox evaluiert die aktuelle Policy lokal und gibt das Verdikt plus den gerenderten Text zurück: 
Reply to [EMAIL] please
Nichts wird nach Upstream gesendet und nichts wird gemessen. Für ein A/B-Raster gegen einen Korpus von Inputs liegt das Eval-Harness einen Tab weiter.

​
5. An einen Key anhängen

Ein Guardrail tut nichts, bis ein Key auf es zeigt. Zwei Wege zu binden:

Pro Key

Bearbeiten Sie einen API-Key und wählen Sie das Guardrail aus dem Dropdown Guardrail. Dies setzt guardrail_id auf dem Key. Siehe An einen Key anhängen.

Workspace-Default

Markieren Sie das Guardrail als Workspace-Default, sodass jeder Key ohne explizite Bindung es erbt. Siehe Account-Default.
Die Auflösung ist explizit und vorhersehbar:
ReihenfolgeWas gilt
1Die explizite guardrail_id des Keys (sofern sie existiert und aktiviert ist).
2Der Workspace-Default (wenn der Key keine Bindung hat).
3Keines — die Anfrage ist byte-identisch zu einem Workspace ohne Policy.
Eine explizite Bindung fällt nie stillschweigend zurück. Das Deaktivieren eines angehängten Guardrails ist der Aus-Schalter — es fällt nicht auf den Workspace-Default durch. (Firewall-Policies unterscheiden sich hier; siehe Guardrails vs. Firewall.)

​
6. Einen Request senden

Mit einem an pii-shield gebundenen Key rufen Sie OrcaRouter genau wie zuvor auf — keine SDK-Änderung, keine neuen Header: 
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"}
    ]
  }'
Das Gateway maskiert die E-Mail vor dem Weiterleiten zu [EMAIL] — das Upstream-Modell sieht die Adresse nie. Tauschen Sie die Action der Regel zu block, und der allernächste Request, der die Entity enthält, wird mit HTTP 400 guardrail_blocked abgelehnt. Ein blockierter Request kostet kein Kontingent (ein Input-Block feuert vor der Messung; ein Output-Block erstattet das vorab verbrauchte Kontingent zurück) und wird als skip-retry markiert. Siehe den guardrail_blocked-Fehler für die vollständige Response-Form.

​
7. Wohin als Nächstes

Jede Regel, die feuert, zeichnet einen Match auf — Type, Action, Stage und einen Detail-String. Der gematchte Teilstring wird nur aufgezeichnet, wenn Log raw content an ist (standardmäßig aus). Siehe den Matches-Feed und Logging & Datenschutz.
PII detection deckt email, phone, credit_card, ssn, ip, iban, mac_address, jwt, aws_access_key, api_key_openai, bitcoin_address (plus regionale Entities) ab, und Sie können Ihre eigenen verfassen. Siehe PII Shield, Benutzerdefinierte PII-Entities und Masking-Formate.
Fügen Sie einen Secrets-Blocker oder das Prompt-Injection-Grundlagen-Preset hinzu — letzteres markiert gängige Jailbreak-Phrasen zur Prüfung. Um Injection-Absicht semantisch statt per Phrase abzufangen, fügen Sie eine llm_judge-Regel daneben hinzu.
Jede Bearbeitung schreibt eine Versionshistorie-Zeile. Öffnen Sie History, um zu diffen und zu reverten. Siehe Versionierung.
Guardrails prüfen Inhalte. Um die Tool-Calls eines Agenten zu steuern — destruktive Aktionen verweigern, Kosten begrenzen, Freigabe verlangen — verwenden Sie die Firewall. Beginnen Sie mit KI-Agenten absichern und der Bedrohung durch gefährliche Tool-Calls.
Lesen Sie die Guardrails-Referenz für die vollständige Engine — Regelfelder, externe Anbieter, das Eval-Harness und die vollständige API — oder den Security-Quickstart, um Guardrails und Firewall für eine Agent-Baseline zu verdrahten.