Zum Hauptinhalt springen
Sie haben eine Liste von Begriffen, die nie ein Modell erreichen oder von einem zurückkommen dürfen — der Name eines Wettbewerbers, ein internes Codename, eine verbotene Beleidigung, ein noch nicht angekündigtes Produkt. Die schnellste Kontrolle dafür ist eine Keyword-Denylist: eine Liste wörtlicher Begriffe, nach denen das Gateway bei jedem Aufruf scannt und die es dann blockiert, maskiert oder markiert. Dies ist eine fokussierte Landingpage für den Anwendungsfall verbotener Begriffe. Die vollständige Guardrail-Engine — jeder Regeltyp, jedes Feld und jede Route — finden Sie in der Guardrails-Referenz.

​
1. Der Sensitive-Word-Filter-KI-Anwendungsfall

Eine keyword-Regel ist die einfachste Regel in der Engine: Sie geben ihr eine Liste von Begriffen, und das Gateway trifft beliebige davon gegen den Text an einer Stage. Das Matching ist ein Substring ohne Beachtung der Groß-/Kleinschreibung — BadWord, badword und BADWORD treffen alle, und der Begriff trifft auch, wenn er in ein längeres Wort eingebettet ist (sodass class auch classic trifft). Jeder Begriff wird als wörtlicher String behandelt, nicht als Muster; Sie escapen keine Regex-Metazeichen. Speichern Sie die Regel einmal in der Konsole, hängen Sie das Guardrail an einen beliebigen API-Key (oder machen Sie es zum Workspace-Default), und jeder Aufruf auf diesem Key wird ohne SDK-Änderung und ohne Redeploy geprüft. Die Policy lebt im Gateway, nicht in Ihrer Anwendung — Ihre App ruft /v1/chat/completions weiterhin genau wie zuvor auf.
Greifen Sie zu einer keyword-Regel, wenn Ihre Denylist eine endliche Menge wörtlicher Begriffe ist. Wenn Sie Wildcards, Wortgrenzen oder Struktur brauchen (ein SKU-Format, eine Bestellnummern-Form), nutzen Sie stattdessen einen Regex-Detektor.

​
2. Die Regel in der Konsole verfassen

Jeder Schritt hier ist eine Konsolen-Aktion in Ihrer eigenen Session. Das Erstellen und Bearbeiten von Guardrails erfordert Developer+ im Workspace. Nur der finale /v1/*-Aufruf nutzt einen sk-orca-...-Relay-Key.
1

Ein Guardrail erstellen

Öffnen Sie in der Konsole Guardrails und klicken Sie auf New guardrail. Benennen Sie es (≤ 64 Zeichen), z. B. banned-terms.
2

Eine Keyword-Regel hinzufügen

Fügen Sie eine Regel hinzu:
  • Type: Keyword denylist (keyword)
  • Stage: Both (Request und Response)
  • Action: Block
  • Keywords: Ihre verbotenen Begriffe, einer pro Zeile
Speichern Sie.
3

Testen

Öffnen Sie den Tab Test, fügen Sie ein Beispiel ein, das einen verbotenen Begriff enthält, wählen Sie eine Stage und führen Sie die Policy lokal aus — kein Upstream-Aufruf, kein Kontingent (siehe §5).
4

Einen Key anhängen

Bearbeiten Sie einen API-Key und wählen Sie banned-terms aus dem Dropdown Guardrail (setzt guardrail_id am Key), oder markieren Sie das Guardrail als Workspace-Default. Siehe An einen Key anhängen und Account-Default.
Das JSON der Regel ist genau das, was Sie erwarten würden: 
{
  "type": "keyword",
  "stage": "both",
  "action": "block",
  "keywords": ["project-orca", "competitor-name", "unannounced-sku"]
}

​
3. Die Action wählen

Eine Keyword-Regel wählt eine Action pro Regel:
Jeder Treffer lehnt den Request mit HTTP 400 guardrail_blocked ab. Ein blockierter Request kostet kein Kontingent — ein Input-Stage-Block feuert vor der Messung; ein Output-Stage-Block erstattet das vorab verbrauchte Kontingent — und er wird als skip-retry markiert. Nutzen Sie es für Begriffe, die nie in eine der Richtungen passieren dürfen. Siehe den guardrail_blocked-Fehler.
Jeder Treffer wird an Ort und Stelle durch ein Redaktions-Tag ersetzt und der Request läuft mit dem bereinigten Text weiter — das Upstream-Modell sieht den Originalbegriff nie. Siehe Actions.
Zeichnet einen Match auf und ändert nichts am Traffic. Nutzen Sie es, um zu messen, wie oft ein Begriff auftaucht, bevor Sie zur Durchsetzung wechseln.
Umschließt den getroffenen Text in Delimiter (z. B. ⟦UNTRUSTED⟧…⟦/UNTRUSTED⟧), sodass das Modell ihn als Daten, nicht Anweisungen behandelt — eine Input-Stage-Prompt-Injection-Verteidigung. Der Text erreicht weiterhin das Modell, nur abgezäunt. Siehe Actions.
Die Stage zählt. input scannt den Request des Aufrufers, output scannt die Response des Modells, both scannt jede Seite unabhängig. Ein verbotener Begriff, den Ihre Benutzer tippen, und einer, den ein Modell ausgeben könnte, sind verschiedene Probleme — wählen Sie die passende(n) Stage(s). Siehe Input-Stage-Regeln und Output-Stage-Regeln.

​
4. Streaming-Abdeckung

Die gewählte Action interagiert damit, ob die Response streamt:
ActionNicht-StreamingStreaming
block (output)DurchgesetztDurchgesetzt — Scanner schneidet den Stream ab
mask (output)DurchgesetztNoch nicht — Block-Entscheidung respektiert, maskierter Text nicht weitergeleitet (Roadmap)
Input-Stage-Regeln laufen vor dem Upstream-Aufruf, daher sind sie vom Streaming unbeeinflusst — ein Input-mask bereinigt den Request, unabhängig davon, ob die Response streamt. Ein verbotener-Begriff-block erhält in beiden Fällen volle Abdeckung. Ein Output-mask jedoch redigiert heute nur bei Nicht-Streaming-Responses: Bei einer Streaming-Antwort handelt der Scanner weiterhin nach der Block-Entscheidung, aber das In-Band-Umschreiben des gestreamten Textes ist auf der Roadmap, nicht live. Siehe Streaming-Abdeckung.

​
5. Testen, bevor Sie anhängen

Beweisen Sie, dass die Regel tut, was Sie erwarten, bevor irgendein Key darauf zeigt. Öffnen Sie den Tab Test im Editor, fügen Sie ein Beispiel ein, wählen Sie die Stage und führen Sie aus: 
Tell me about Project-Orca and our competitor-name
Die Sandbox wertet die aktuelle Policy lokal aus und gibt das Verdikt zurück — nichts wird nach Upstream gesendet, nichts gemessen. Mit einer block-Action wird das Beispiel abgelehnt; mit mask kommt der gerenderte Text mit jedem redigierten Begriff zurück. Für ein A/B-Raster gegen ein Korpus — um zu bestätigen, dass eine Denylist fängt, was sie soll, ohne gutartigen Traffic zu markieren — liegt das Eval-Harness einen Tab weiter.

​
6. Eine Anfrage senden

Rufen Sie mit einem an banned-terms gebundenen Key OrcaRouter genau wie zuvor auf — keine neuen Header, keine SDK-Änderung: 
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"}
    ]
  }'
Mit einer block-Action wird der Aufruf mit HTTP 400 guardrail_blocked abgelehnt, bevor er je das Modell erreicht. Tauschen Sie die Action auf mask, und der Begriff wird stattdessen vor der Weiterleitung an Ort und Stelle redigiert.

​
7. Sehen, was ausgelöst hat

Jede Regel, die auslöst, zeichnet einen Match auf — Regeltyp, Action, Stage und einen Detail-String (bei Keyword-Regeln, wie viele Begriffe getroffen haben) — sichtbar im Workspace-Matches-Feed.
Der getroffene Begriff selbst wird nur aufgezeichnet, wenn Log raw content aktiviert ist, was standardmäßig deaktiviert ist — die datenschutzkonservative Haltung. Mit deaktiviertem Schalter sehen Sie weiterhin, dass eine Keyword-Regel gefeuert hat und wie oft, nur nicht den wörtlichen Begriff. Aktivieren Sie es pro Guardrail, wenn Sie den Substring für die Triage benötigen; die Einstellung ist nicht-rückwirkend. Siehe Matches-Feed und Logging & Datenschutz.
Wenn ein gutartiger Begriff immer wieder trifft (ein Denylist-Eintrag, der ein Substring eines häufigen Wortes ist), markieren Sie ihn aus dem Matches-Feed als False Positive und verschärfen Sie den Eintrag. Siehe False Positives justieren.

​
8. Wie es weitergeht

Regex-Detektoren

Treffen Sie strukturierte Muster — SKUs, Bestellnummern, Formate — wenn eine wörtliche Denylist nicht ausreicht.

Markensicherheit

Schimpfwort-, Wettbewerber-Erwähnungs- und Kinderschutz-Presets, gebaut auf Keyword-Regeln.

Actions

Wie sich block, mask und flag unterscheiden und wann man welches nutzt.

Guardrails-Referenz

Die vollständige Engine — jeder Regeltyp, jedes Feld und jede Route.
Eine Keyword-Denylist steuert Inhalte. Um die Tool-Calls eines Agenten zu steuern — destruktive Aktionen verweigern, Tool-Call-Argumente redigieren, Freigabe verlangen — nutzen Sie die Firewall. Für unscharfe Policies, die keine wörtliche Liste ausdrücken kann (Toxizität, Off-Topic, Injection-Absicht), führt eine llm_judge-Regel eine semantische Prüfung gegen ein Workspace-Modell aus.