Guardrails

Sobald Sie einen Workspace und einen API-Key haben (siehe Einführung), sind Guardrails die Art und Weise, wie Sie eine Content-Policy vor jedes Modell stellen. Diese Seite ist die kanonische Referenz für die Guardrail-Engine von OrcaRouter — was sie ist, wie man sie nutzt und wie sie mit dem Rest des Gateways zusammenspielt.

1. Was ist die Guardrail-Engine

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. Sie speichern ein Guardrail einmal, hängen einen beliebigen API-Key daran (oder setzen eines als Workspace-Default), und das Gateway prüft jeden Aufruf vor und nach dem Upstream-Modell. Jede Regel entscheidet eine Sache — wonach gesucht wird (ein Regeltyp), wo gesucht wird (eine Stage: Request-Input oder Modell-Output) und was zu tun ist (eine Action: block, mask oder flag). Die Engine führt jede zutreffende Regel aus und fasst die Ergebnisse zu einer einzigen Entscheidung zusammen. Das Bearbeiten eines Guardrails wirkt sich auf jeden daran gebundenen Key beim nächsten Aufruf aus. Kein Redeploy. Keine Codeänderung. Kein SDK-Upgrade. Die Policy lebt im Gateway, nicht in Ihrer Anwendung — Ihre App ruft /v1/chat/completions weiterhin genau wie zuvor auf. Die Engine ist für die eingebauten Regeltypen deterministisch und ohne Abhängigkeiten: reines String- und Regex-Matching ohne Netzwerkaufruf, sicher auf dem heißen Relay-Pfad. Erweiterte Regeln (externe Anbieter, LLM-Judge, kontextuelle Verankerung) rufen nach außen und werden nebenläufig ausgeführt, sodass eine langsame Prüfung nie hinter einer anderen serialisiert wird. Guardrails sind workspace-bezogen — jedes Mitglied sieht die Guardrails des Workspaces; nichts überschreitet Tenant-Grenzen.

2. Schnellstart — prüfen Sie Ihren ersten Request in 5 Schritten

Ein Guardrail erstellen

Gehen Sie in der Konsole zu /console/guardrails und klicken Sie auf New guardrail. Benennen Sie es pii-shield. Fügen Sie eine Regel hinzu:

Type: PII detection
Stage: Input (request)
Action: Mask — redact match
Entities: email, phone, ssn

Speichern.

Im Sandbox testen

Öffnen Sie den Tab Test im Editor, fügen Sie “email me at jane@acme.com” ein, wählen Sie die input-Stage und führen Sie aus. Die Sandbox zeigt das Verdikt und den gerenderten Text — email me at [EMAIL] — ohne etwas nach Upstream zu senden.

Einen Key anhängen

Gehen Sie zu /console/token, erstellen oder bearbeiten Sie einen API-Key und wählen Sie pii-shield aus dem Dropdown Guardrail. Die Bindung lebt am Key im Gateway.

Eine Anfrage senden

Rufen Sie mit diesem Key OrcaRouter genau wie zuvor auf:

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 zu [EMAIL], bevor es weiterleitet. Das Upstream-Modell sieht die Adresse nie.

Die Policy verschärfen

Bearbeiten Sie zurück in /console/guardrails pii-shield — ändern Sie die Action für ssn per Pro-Entity-Override auf Block. Speichern. Der allernächste Request, der eine SSN enthält, wird mit HTTP 400 guardrail_blocked abgelehnt. Keine Änderung in der Anwendung.

Das ist der Kernnutzen.

3. Konzepte: Guardrails, Regeln, Stages, Actions

Konzept	Definition
Guardrail	Eine benannte, workspace-bezogene Policy. Identifier: `name` (≤ 64 Zeichen). Hat `enabled`, `is_default` und einen `rules`-JSON-Blob.
Regel	Eine Prüfung innerhalb einer Policy: ein `type`, eine `stage`, eine `action` plus typspezifische Felder. Regeln laufen der Reihe nach.
Stage	`input` (die Anfrage), `output` (die Antwort des Modells) oder `both`.
Action	`block` (den Aufruf ablehnen), `mask` (den Treffer redigieren) oder `flag` (nur loggen — beobachten, ohne den Traffic zu verändern).

Scoping und der Workspace-Default

Guardrails sind genau wie API-Keys gescoped: workspace-geteilt, wenn Sie einen aktiven Workspace haben, andernfalls pro Benutzer. Auflösung für jede Anfrage:

Key-Bindung — wenn der Key eine explizite guardrail_id hat, gilt dieses Guardrail (sofern es existiert und aktiviert ist). Eine explizite Bindung fällt nie stillschweigend zurück; das Deaktivieren ist der Aus-Schalter.
Workspace-Default — wenn der Key keine Bindung hat, gilt das aktivierte is_default-Guardrail des Workspaces.
Keines von beiden — keine Durchsetzung. Die Anfrage ist byte-identisch zu einem Workspace, der das Feature nie aktiviert hat.

Höchstens ein Guardrail pro Workspace kann der Default sein. Das Promoten eines neuen Defaults degradiert das alte in derselben Transaktion.

Fail-open by design. Wenn die Guardrail-Auflösung auf einen transienten Fehler stößt (z. B. einen DB-Schluckauf), degradiert das Gateway zu keiner Durchsetzung, anstatt den Traffic lahmzulegen. Die Sicherheit degradiert; die Verfügbarkeit bleibt erhalten.

Wie ein Block aussieht

Ein blockierter Request gibt HTTP 400 mit dem Fehlercode guardrail_blocked und einer Nachricht zurück, die das Guardrail und die ausgelöste Regel benennt. Ein blockierter Request kostet Sie kein Kontingent — ein Block der input-Stage feuert vor der Messung, und ein Block der output-Stage erstattet das vorab verbrauchte Kontingent zurück — und er wird als skip-retry markiert (das erneute Ausführen desselben Prompts würde einfach wieder blockieren).

4. Regeltypen

Regeln fallen in zwei Gruppen: eingebaut (deterministisch, kein Netzwerk) und erweitert (rufen ein Modell oder einen Anbieter auf).

Type	Gruppe	Was sie tut
Keyword denylist (`keyword`)	Eingebaut	Matcht einen beliebigen aus einer Liste literaler Begriffe – ohne Beachtung der Groß-/Kleinschreibung, als Teilstring-Match (`class` matcht also auch `classic`).
Regular expression (`regex`)	Eingebaut	Matcht ein RE2-Muster (lineare Zeit, keine Backreferences).
PII detection (`pii`)	Eingebaut	Erkennt eingebaute Entity-Typen (und Ihre eigenen benutzerdefinierten). Siehe §5.
Maximum length (`max_chars`)	Eingebaut	Begrenzt die Zeichenzahl des Texts an einer Stage.
External vendor (`external`)	Erweitert	Delegiert die Prüfung an einen verbundenen Anbieter (Aporia, Averta, BYO-Webhook, …). Siehe §9.
LLM judge (`llm_judge`)	Erweitert	Führt eine semantische Prüfung gegen ein Modell in Ihrem Workspace aus. Siehe §6.
Contextual grounding (`grounding`)	Erweitert	Bewertet die Treue der Antwort gegenüber den auf der Anfrage abgerufenen Quellen (RAG). Siehe §7.

Ein Guardrail mischt beliebig viele Regeln beliebiger Typen. Erweiterte Regeln (external, llm_judge, grounding) werden nebenläufig ausgeführt, sodass eine langsame Prüfung nicht hinter einer anderen serialisiert wird.

5. PII detection im Detail

Eine pii-Regel erkennt sensible Entities und wendet die Action der Regel auf jeden Treffer an. Der eingebaute Detektor-Satz ist geschlossen und wird von der Engine, dem Validator und dem Rule-Builder gemeinsam genutzt: email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt, bitcoin_address. Bei einer mask-Action wird jeder Treffer durch einen typisierten Tag ersetzt — aus einer E-Mail wird [EMAIL], aus einer SSN wird [SSN] usw.

Benutzerdefinierte Entities

Schichten Sie Ihre eigenen Detektoren über den eingebauten Satz. Eine benutzerdefinierte Entity ist:

name — Kleinbuchstaben-ASCII / Ziffern / Unterstrich, muss mit einem Buchstaben beginnen (z. B. employee_id). Fließt unquoted in Audit-Logs und Telemetrie.
pattern — eine Go-RE2-Regex (lineare Zeit, keine Backreferences).
checksum — optional; luhn validiert den Treffer mit dem Luhn-Algorithmus (z. B. für kartenähnliche Nummern).
mask_with — optionaler wortwörtlicher Ersatz; Standard ist [<UPPERCASE_NAME>].

Bis zu 25 benutzerdefinierte Entities pro Regel (jede ist ein Regex-Scan über den vollständigen Text, sodass das Limit den heißen Pfad linear hält). Kompilierte Muster werden über Requests hinweg gecacht.

Pro-Entity-Action-Overrides

Eine einzelne PII-Regel kann verschiedene Actions auf verschiedene Entities anwenden, via entity_actions. Eine Regel, die E-Mails / Telefonnummern / IPs standardmäßig maskiert, aber bei credit_card oder ssn blockiert — anstatt drei überlappender Regeln:

{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}

Keys müssen eine auf der Regel aktivierte Entity sein; Werte müssen block / mask / flag sein. Der Validator lehnt alles andere ab.

6. LLM judge

Eine llm_judge-Regel führt eine semantische Prüfung gegen ein Modell aus, das Ihr Workspace bereits aufrufen kann. Verwenden Sie sie für unscharfe Policies, die keine Regex erfasst — Toxizität, Belästigung, Off-Topic, Prompt-Injection-Absicht.

Feld	Bedeutung
`judge_model`	Das Modell oder der Router-Alias, mit dem evaluiert wird (z. B. `gpt-4o-mini`, `orcarouter/cheap`). Wird gegen die Channels Ihres Workspaces aufgelöst.
`judge_rubric`	Der System-Prompt, der beschreibt, was zu markieren ist.
`judge_format`	Einer der Werte `yes_no`, `score` oder `category` (erforderlich; die Konsole wählt `yes_no` vor).
`judge_threshold`	Für `score`: blockieren/markieren, wenn der Score auf oder über diesem Wert liegt.
`judge_categories`	Für `category`: die abgelehnte Liste.
`judge_timeout_ms`	Begrenzt den Judge-Aufruf. `0` → Engine-Standard.
`judge_fail_open`	`true` (Standard) → ein Judge-Fehler wird beobachtet, aber die Anfrage fährt fort; `false` → behandelt Fehler/Timeout als Block.

Der Judge-Aufruf wird über die Channels Ihres Workspaces geroutet, sodass seine Tokens wie jeder andere Aufruf abgerechnet und zugeordnet werden (als Judge-Sub-Zeile). Die Engine hängt einen JSON-Schema-Anhang an Ihre Rubric an, damit das Modell parsebare Ausgabe zurückgibt.

7. Contextual grounding

Eine grounding-Regel misst die Antwort des Assistenten gegen die auf der Anfrage abgerufenen Quellen (Ihren RAG-Kontext) und markiert oder blockiert Antworten, die ihnen nicht treu sind. Sie verwendet die Judge-Naht wieder — dieselben Workspace-Channels, dieselbe Kosten-Zuordnung.

Feld	Standard	Bedeutung
`grounding_model`	Workspace-Wahl	Das Modell, gegen das der Runner die Treue-Prüfung auflöst.
`grounding_rubric`	eingebaut	Überschreibt die Standard-Treue-Rubric.
`grounding_threshold`	`0.7`	Treue-Untergrenze, `0.0`–`1.0`. Darunter feuert die Action.
`grounding_strict`	`false`	Wenn `true`, wird „keine Quellen bereitgestellt” als Block behandelt (statt des Standard-Allow).
`grounding_max_bytes`	`100000`	Begrenzt den verketteten Quellkontext, der an den Judge übergeben wird.
`grounding_timeout_ms`	`3000`	Begrenzt den Judge-Aufruf.

8. Templates, die Sandbox und das Eval-Harness

Template-Bibliothek

Der New guardrail-Splitbutton öffnet direkt in ein Template, und die vollständige Bibliothek ist einen Klick entfernt. Presets werden serverseitig verfasst, sodass die Konsole, die Sandbox und diese Doku exakt dasselbe Verhalten beschreiben. Kategorien umfassen:

PII (pii) — PII Shield, PII Blocker (strikt), Contact-Info Redactor, Response-PII-Redactor.
Secrets (secrets) — AWS- / OpenAI- / GitHub-Credential-Blocker, Private Keys & Cloud-Tokens, Krypto-Wallets, Secrets in der Ausgabe.
Compliance (compliance) — GDPR (EU-PII), PCI (vollständiger Karten-Block), HIPAA (PHI), Finanzdaten, Compliance-Logger, Erzwingung rechtlicher Haftungsausschlüsse.
Brand (brand) — Profanität (block / mask / mehrsprachig), Erwähnungen von Wettbewerbern, Kinderschutz-Keywords.
Safety (safety) — Prompt-Injection, Jailbreak, System-Prompt-Leak, Selbstverletzung.
Cost (cost) — Prompt-/Response-Größenlimits und Token-Limits.
Agent (agent) — URL-Filter, Markdown-Image-, Shell-Tool-Call- und SQL-Injection-in-Output-Filter.

Wenden Sie ein Preset als Ausgangspunkt an und bearbeiten Sie dann frei — ein Preset ist ein Keim, keine Sperre.

Die Test-Sandbox

Jeder Editor hat einen Tab Test. Fügen Sie ein Sample ein, wählen Sie eine Stage und führen Sie die aktuelle Policy lokal aus — kein Upstream-Aufruf, kein Kontingent. Die Sandbox gibt das Verdikt und (bei mask-Regeln) den gerenderten Text zurück, sodass Sie beweisen können, dass eine Regel das tut, was Sie erwarten, bevor Sie einen Key anhängen.

Eval- / Red-Team-Harness

Der Tab Eval führt ein Guardrail gegen einen Korpus von Inputs aus und berichtet, wie es abschnitt — nützlich, um eine Judge-Rubric zu tunen oder zu beweisen, dass eine Policy bekannte Angriffe abfängt, bevor Sie sie ausliefern.

Mitgelieferte Korpora kommen mit dem Gateway — adversariale und Red-Team-Sätze (Prompts zu schädlichem Verhalten, Tool-Injection, mehrsprachiges Red-Teaming) plus harmlose Sätze, um Fehlalarme zu messen.
Benutzerdefinierte Korpora — laden Sie Ihr eigenes JSONL hoch, um gegen Ihre realen Traffic-Formen zu testen.
Runs werden mit ihren Scores aufgelistet; öffnen Sie einen Run, um die Fehlschläge Sample für Sample zu inspizieren.

9. External vendors

Eine external-Regel delegiert die Prüfung an einen verbundenen Anbieter. Verbinden Sie einen Anbieter einmal unter Integrations (die Header-CTA auf der Guardrails-Seite), referenzieren Sie dann die Verbindung aus einer Regel.

Unterstützte Anbieter

Anbieter	Was es ist
Aporia Guardrails (`aporia`)	SLM-Ensemble-Policy-Engine für Prompts und Antworten.
Averta (`averta`)	Generischer SLM-Klassifizierer-Endpunkt (POST von Text → safe / unsafe + optionales Rewrite).
BYO Webhook (`webhook`)	Ihre eigene URL — empfängt Prompts und gibt Allow-/Block-/Mask-/Flag-Urteile zurück.

Aporia und Averta erwarten eine Basis-URL + API-Schlüssel; der Webhook erwartet eine URL + Auth-Header + HMAC-Secret.

Regelfelder

Feld	Bedeutung
`connection_id`	Die zu verwendende verbundene Integration (empfohlener Pfad — Anbieter + Secrets werden zur Laufzeit aus der Integration des Workspaces aufgelöst).
`timeout_ms`	Begrenzt den einzelnen Anbieter-Aufruf. `0` → Standard.
`fail_open`	`true` (Standard) → ein Anbieter-Fehler wird beobachtet, aber die Anfrage fährt fort; `false` → behandelt Transportfehler / Timeout / unbekannten Provider als Block.

Secrets werden verschlüsselt gespeichert und beim Lesen maskiert. Der Prüf-Aufruf trägt die Stornierung des Relay-Requests, sodass eine stornierte Anfrage keinen Anbieter-Aufruf hängen lässt.

10. Observability

Guardrails hinterlassen Brotkrumen, auf die Sie reagieren können.

Matches-Feed

Jede Regel, die feuert, zeichnet einen Match auf — Regeltyp, Action, ein Detail-String, die Stage und (wenn aktiviert) den gematchten Teilstring. Der Tab Matches auf der Guardrails-Seite ist der workspace-weite Feed: listen, gruppieren, filtern, in einen einzelnen Match eintauchen, als CSV exportieren und Fehlalarme markieren.

Die Erfassung von Rohinhalten ist opt-in. Der Toggle Log raw content eines Guardrails ist standardmäßig aus — die datenschutzfreundliche Haltung. Mit ihm aus zeichnet der Matches-Feed auf, dass eine Regel gefeuert hat, plus ihren Detail-Meta-String, aber nicht den tatsächlich gematchten Teilstring (z. B. die E-Mail-Adresse selbst). Schalten Sie ihn pro Guardrail ein, wenn Sie den Teilstring zum Triage brauchen; die Einstellung ist nicht rückwirkend.

Stats

Der Matches-Feed speist die Statistiken pro Guardrail — jede Guardrail-Karte zeigt eine 7-Tage-Match-Sparkline und einen Zähler, und der Tab Matches trägt eine Workspace-Gesamtzahl. Um die Aktivität nach Policy aufzuschlüsseln, verwenden Sie die gruppierte Ansicht und die Filter des Matches-Feeds (nach Guardrail, Regeltyp, Action) — dort leben Nutzung pro Guardrail, Action-Mix und Fehlalarmrate.

Versionshistorie und Audit

Jedes Erstellen, Aktualisieren und Löschen schreibt eine versionierte Historie-Zeile in derselben Transaktion wie die Änderung. Öffnen Sie History auf einer Guardrail-Zeile, um:

Jede Version mit dem Wer und Wann der Änderung zu sehen.
Beliebige zwei Versionen zu diffen.
Auf eine ältere Version zu reverten (wird als neue Version aufgezeichnet — die Historie wird nie mutiert).

11. Verhältnis zum restlichen Gateway

Oberfläche	Wie komponiert sie mit Guardrails?
Modelle	Guardrails sind modellunabhängig. Dieselbe Policy fährt über GPT-5, Claude, Gemini — sie prüft Text, nicht die Modellwahl.
Routing	Unabhängig. Das Routing entscheidet, welches Modell bzw. welcher Channel die Anfrage bedient; Guardrails prüfen denselben Request-/Response-Text unabhängig davon und überschreiben die Modellwahl nie. Die Input-Prüfung läuft vor dem Upstream-Call, die Output-Prüfung nachdem das Modell geantwortet hat. Judge- und Grounding-Regeln lösen ihr eigenes Modell über Ihre Workspace-Channels auf, getrennt vom Routing der Anfrage.
Prompts	Unabhängig und ergänzend. Prompts injizieren eine System-Message; Guardrails inspizieren und gaten Inhalte. Beides kann auf eine Anfrage zutreffen, und Guardrails laufen immer. Die Reihenfolge ist entscheidend: Input-Regeln prüfen den Request des Callers bevor ein Registry-Prompt injiziert wird (die Injektion erfolgt später, in der Routing-Phase), sodass Input-Regeln die Messages des Callers sehen, nicht den injizierten System-Prompt; Output-Regeln prüfen die Response des Modells in jedem Fall.
API-Keys	Ein Key hängt sich via `guardrail_id` an ein Guardrail. Die Bindung lebt am Key im Gateway, sodass das Bearbeiten des Guardrails alle angehängten Keys auf einmal verschiebt; keine Bindung fällt auf den Workspace-Default zurück.
Matches-Feed	Jede Regel, die feuert, landet im Matches-Feed des Workspaces (ein eigener Speicher, getrennt vom Request-Log). Gruppieren und filtern Sie ihn nach Guardrail, Regeltyp und Action, um Nutzung, Action-Mix und Fehlalarmrate pro Guardrail zu sehen.

12. API-Referenz

Alle Routen sind workspace-bezogen über den Header X-Workspace-Id. RBAC wird konsistent durchgesetzt: Lesen und die Test-Sandbox sind für jedes Mitglied offen; Schreiben erfordert Developer+ (und die guardrails:write-Berechtigung); Änderungen des Produktions-Traffics (Löschen, Revert, Anbieter-Konfiguration) sind entsprechend gegated.

Methode & Pfad	Rolle	Zweck
`GET /api/guardrail/`	Member	Listet Guardrails (mit Zählern angehängter Keys).
`GET /api/guardrail/meta`	Member	Engine-Vokabular — Regeltypen, Stages, Actions, PII-Entities, Presets, Preset-Kategorien.
`GET /api/guardrail/my-permissions`	Member	Die Guardrail-Berechtigungen des Aufrufers (für UI-Gating).
`GET /api/guardrail/:id`	Member	Detail eines einzelnen Guardrails.
`GET /api/guardrail/:id/tokens`	Member	An dieses Guardrail angehängte API-Keys (begrenzt, mit echter Gesamtzahl).
`POST /api/guardrail/test`	Member	Sandbox — eine Policy über Beispieltext an einer Stage evaluieren. Nichts wird persistiert.
`POST /api/guardrail/`	Developer+	Ein Guardrail erstellen.
`PUT /api/guardrail/`	Developer+	Ein Guardrail aktualisieren (schreibt eine neue Historie-Version).
`DELETE /api/guardrail/:id`	Developer+	Ein Guardrail löschen.

History

Methode & Pfad	Rolle	Zweck
`GET /api/guardrail/:id/history`	Member	Versionshistorie (neueste zuerst).
`GET /api/guardrail/:id/history/diff`	Member	Zwei Versionen diffen.
`GET /api/guardrail/:id/history/:version`	Member	Eine einzelne historische Version.
`POST /api/guardrail/:id/revert`	Developer+	Eine ältere Version als neue Version wiederherstellen.

Eval und Korpora

Methode & Pfad	Rolle	Zweck
`POST /api/guardrail/:id/eval`	Member	Eine Eval über einen Korpus ausführen (mitgelieferter Name oder hochgeladenes JSONL).
`GET /api/guardrail/:id/eval/runs`	Member	Listet Eval-Runs für ein Guardrail (paginiert).
`GET /api/guardrail/eval/runs/:run_id`	Member	Detail eines einzelnen Eval-Runs.
`GET /api/guardrail/eval/corpora`	Member	Listet Workspace-Korpora + mitgelieferte Korpora.
`POST /api/guardrail/eval/corpora`	Developer+	Einen JSONL-Korpus hochladen.
`GET /api/guardrail/eval/corpora/:id`	Member	Korpus-Detail.
`DELETE /api/guardrail/eval/corpora/:id`	Developer+	Einen Korpus löschen.

Matches

Methode & Pfad	Rolle	Zweck
`GET /api/guardrail/match`	Member	Listet Matches (workspace-bezogen).
`GET /api/guardrail/match/grouped`	Member	Gruppierte Matches (z. B. nach Regel oder Guardrail).
`GET /api/guardrail/match/stats`	Member	Match-Statistiken (unterstützt `?days=` und `?group_by=`).
`GET /api/guardrail/match/export`	Member	Matches als CSV exportieren.
`GET /api/guardrail/match/:id`	Member	Detail eines einzelnen Matches.
`POST /api/guardrail/match/:id/mark-fp`	Admin	Einen Match als Fehlalarm markieren (rate-limited).
`DELETE /api/guardrail/match/:id/mark-fp`	Admin	Eine Fehlalarm-Markierung aufheben (rate-limited).

Einen Key anhängen

Setzen Sie guardrail_id auf dem API-Key (über den Key-Editor oder die Token-API). 0/null bedeutet keine explizite Bindung — der Key fällt auf das Default-Guardrail des Workspaces zurück, sofern eines gesetzt ist.

13. FAQ

Was, wenn auf einer Anfrage kein Guardrail aufgelöst wird?

Das Verhalten ist byte-identisch zu einem Workspace, der das Feature nie aktiviert hat. Wenn der Key nicht gebunden ist und kein Workspace-Default gesetzt ist, nimmt das Gateway null Änderungen vor. Nichts wird blockiert, maskiert oder in den Matches-Feed geloggt.

Kostet ein blockierter Request Kontingent?

Nein. Ein Block der input-Stage feuert, bevor die Nutzung gemessen wird; ein Block der output-Stage erstattet das vorab verbrauchte Kontingent zurück, nachdem die Antwort abgelehnt wurde. In beiden Fällen zahlt der Aufrufer kein Kontingent, erhält HTTP 400 guardrail_blocked, und die Anfrage wird als skip-retry markiert (das erneute Ausführen desselben Prompts gegen einen anderen Channel würde einfach wieder blockieren).

Werden Output-(Response-)Regeln beim Streaming durchgesetzt?

Das hängt von der Aktion ab. Block wird in beiden Fällen durchgesetzt: Bei einer nicht-streamenden Response wird die Antwort vor der Rückgabe geprüft, und bei einer streamenden Response unterbricht ein Scanner den Stream mittendrin und sendet eine Ersatznachricht, bevor blockierte Inhalte den Client erreichen. Mask auf dem Output gilt derzeit nur für nicht-streamende Responses — bei einer streamenden Response wird der ursprüngliche Chunk unmaskiert durchgereicht (In-Band-Stream-Rewriting ist eine geplante Erweiterung). Für Output-Masking heute verwenden Sie nicht-streamende Requests oder verlassen Sie sich auf das Masking in der Input-Stage. Beweisen Sie Ihre spezifische Stage/Stream-Kombination in der Sandbox und mit einem Eval-Run, bevor Sie sich darauf verlassen.

Was ist der Unterschied zwischen mask und block?

Mask redigiert den Treffer (z. B. jane@acme.com → [EMAIL]) und lässt die Anfrage mit dem bereinigten Text durch — das Upstream-Modell sieht das Original nie. Block lehnt die gesamte Anfrage mit HTTP 400 ab. Flag ändert nichts am Traffic und zeichnet nur einen Match auf — verwenden Sie es, um eine Regel zu messen, bevor Sie sie durchsetzen.

Werden injizierte Prompt-Tokens und Judge-Tokens abgerechnet?

Eine eingebaute Regel (keyword / regex / PII / max_chars) tätigt keinen Modell-Aufruf und rechnet nichts ab. Eine llm_judge- oder grounding-Regel ruft ein Modell über die Channels Ihres Workspaces auf, sodass diese Tokens abgerechnet und als Judge-Sub-Zeile zugeordnet werden.

Wie sehe ich, was eine Regel tatsächlich gematcht hat?

Schalten Sie Log raw content für das Guardrail ein. Mit ihm aus (dem Standard) zeichnet der Matches-Feed auf, dass eine Regel gefeuert hat, plus ihren Detail-Meta-String, aber nicht den gematchten Teilstring — die datenschutzfreundliche Haltung. Der Toggle ist nicht rückwirkend: Er betrifft nur Matches, die nach dem Aktivieren aufgezeichnet werden.

Kann ich eine Guardrail-Änderung zurückrollen?

Ja. Öffnen Sie History auf dem Guardrail, diffen Sie die Versionen und reverten Sie auf die gewünschte. Revert kopiert den Inhalt jener Version als neue Version nach vorne — die Historie wird nie mutiert — und die Änderung wirkt sich auf die nächste Anfrage aus.

Was passiert, wenn ein externer Anbieter oder Judge ein Timeout hat?

Standardmäßig failen erweiterte Regeln open: ein Timeout oder Transportfehler wird als Telemetrie aufgezeichnet, und die Anfrage fährt fort. Setzen Sie fail_open (external) oder judge_fail_open (judge) auf false, um fail closed zu sein — den Fehler als Block zu behandeln — für Policies, bei denen eine verpasste Prüfung inakzeptabel ist.

​1. Was ist die Guardrail-Engine

​2. Schnellstart — prüfen Sie Ihren ersten Request in 5 Schritten

​3. Konzepte: Guardrails, Regeln, Stages, Actions

​Scoping und der Workspace-Default

​Wie ein Block aussieht

​4. Regeltypen

​5. PII detection im Detail

​Benutzerdefinierte Entities

​Pro-Entity-Action-Overrides

​6. LLM judge

​7. Contextual grounding

​8. Templates, die Sandbox und das Eval-Harness

​Template-Bibliothek

​Die Test-Sandbox

​Eval- / Red-Team-Harness

​9. External vendors

​Unterstützte Anbieter

​Regelfelder

​10. Observability

​Matches-Feed

​Stats

​Versionshistorie und Audit

​11. Verhältnis zum restlichen Gateway

​12. API-Referenz

​Guardrails

​History

​Eval und Korpora

​Matches

​Einen Key anhängen

​13. FAQ

1. Was ist die Guardrail-Engine

2. Schnellstart — prüfen Sie Ihren ersten Request in 5 Schritten

3. Konzepte: Guardrails, Regeln, Stages, Actions

Scoping und der Workspace-Default

Wie ein Block aussieht

4. Regeltypen

5. PII detection im Detail

Benutzerdefinierte Entities

Pro-Entity-Action-Overrides

6. LLM judge

7. Contextual grounding

8. Templates, die Sandbox und das Eval-Harness

Template-Bibliothek

Die Test-Sandbox

Eval- / Red-Team-Harness

9. External vendors

Unterstützte Anbieter

Regelfelder

10. Observability

Matches-Feed

Stats

Versionshistorie und Audit

11. Verhältnis zum restlichen Gateway

12. API-Referenz

Guardrails

History

Eval und Korpora

Matches

Einen Key anhängen

13. FAQ