Zum Hauptinhalt springen
Jede Guardrail-Regel beantwortet drei Fragen — wonach gesucht wird (ein Type), wo gesucht wird (eine Stage) und was damit zu tun ist (eine Action). Diese Seite handelt von dieser dritten Wahl. Die Action einer Regel ist das folgenreichste Feld an ihr: sie entscheidet, ob ein Match die Anfrage stoppt, sie still umschreibt oder nur eine Brotkrume hinterlässt. Der Rule-Builder bringt insgesamt fünf Actions an die Oberfläche — block, mask, flag, annotate und spotlight. Diese Seite behandelt die drei Durchsetzungs-Wahlen, zu denen Sie zuerst greifen: block, mask und flag. Wählen Sie eine pro Regel (oder routen Sie bei einer PII-Regel verschiedene Entities an verschiedene Actions; siehe §5). Die anderen beiden sind prompt-formende, nicht-blockierende Actions: annotate injiziert eine Sicherheitsnotiz nach Upstream (siehe Code-Sicherheit), und spotlight fasst gematchten nicht vertrauenswürdigen Input in Delimiter ein, sodass das Modell ihn als Daten behandelt, nicht als Anweisungen. Die vollständige Liste lebt im Guardrails-Überblick. Für die breitere Engine — Regeltypen, Stages, eine Policy an einen Key anhängen — beginnen Sie beim Guardrails-Überblick oder der vollständigen Guardrails-Referenz.

​
1. Die Entscheidung block, mask, flag in einer Zeile

block

Lehnt den Aufruf mit HTTP 400 guardrail_blocked ab. Das Modell läuft nie (Input-Stage) oder seine Antwort kehrt nie zurück (Output-Stage).

mask

Redigiert jeden Treffer — z. B. jane@acme.com → [EMAIL] — und lässt den bereinigten Text durch. Die Anfrage fährt fort.

flag

Ändert nichts am Traffic. Zeichnet einen Match im Feed auf und macht weiter. Nur beobachtend.
Dies sind die drei Durchsetzungs-Actions. Welche auch immer Sie setzen, wird überall dort honoriert, wo die Regel läuft — der Konsolen-Rule-Builder, die Test-Sandbox und der Live-/v1/*-Relay-Pfad lesen alle denselben block- / mask- / flag-Wert.

​
2. Ein konkretes Beispiel — drei Regeln, drei Actions

Hier ist ein einzelnes Guardrail, dessen drei Regeln jeweils eine andere Action wählen. Sie verfassen dies in der Konsole (/console/guardrails) auf Ihrer Session — der sk-orca-...-Relay-Key ist nur für /v1/*-Aufrufe, nie zum Bearbeiten von Policy. Das Erstellen oder Bearbeiten eines Guardrails erfordert die Rolle Developer+. 
{
  "rules": [
    { "type": "keyword", "stage": "input",  "action": "block",
      "keywords": ["internal-only", "do-not-share"] },
    { "type": "pii",     "stage": "input",  "action": "mask",
      "entities": ["email", "phone"] },
    { "type": "regex",   "stage": "output", "action": "flag",
      "pattern": "(?i)acme\\s+confidential" }
  ]
}
Was jede Regel auf einer Anfrage tut:
  • Die block-Regel lehnt jeden Prompt ab, der einen dieser literalen Begriffe enthält — HTTP 400, das Modell läuft nie.
  • Die mask-Regel schreibt E-Mails und Telefonnummern im Prompt zu [EMAIL] / [PHONE] um, bevor das Modell sie sieht.
  • Die flag-Regel beobachtet den Output des Modells auf einen Vertraulichkeitsmarker und zeichnet einen Match auf, ohne die Antwort zu verändern — sodass Sie messen können, wie oft er erscheint, bevor Sie sich zur Durchsetzung entscheiden.
Die Engine führt jede zutreffende Regel aus und fasst die Ergebnisse zu einem Verdikt zusammen. Wenn irgendeine Regel blockiert, wird die Anfrage blockiert.

​
3. block — mit HTTP 400 ablehnen

Eine block-Action lehnt den gesamten Aufruf ab. Der Aufrufer erhält HTTP 400 mit dem Fehlercode guardrail_blocked und einer Nachricht, die das Guardrail und die ausgelöste Regel benennt.
Ein Block der Input-Stage feuert vor der Messung, sodass nichts verbraucht 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 nichts für einen blockierten Aufruf.
Ein guardrail_blocked-Ergebnis ist skip-retry — das erneute Ausführen desselben Prompts gegen einen anderen Channel würde einfach wieder blockieren, sodass das Gateway keinen Retry verschwendet. Siehe den guardrail_blocked-Fehler.
Bei einer nicht-streamenden Response wird die Antwort geprüft, bevor sie zurückkehrt. Bei einer streamenden Response kappt ein Scanner den Stream mittendrin und gibt eine Ersatznachricht aus, bevor blockierter Inhalt den Client erreicht. Siehe Streaming-Abdeckung.
Greifen Sie zu block, wenn ein Match bedeutet, dass die Anfrage nicht fortfahren darf — Secrets in einem Prompt, ein Jailbreak-Versuch, eine harte Compliance-Linie.

​
4. mask — redigieren und fortfahren

Eine mask-Action redigiert jeden Treffer und lässt die Anfrage mit dem bereinigten Text durch. Das Upstream-Modell sieht das Original nie. Bei einer PII-Regel wird jeder Treffer durch einen typisierten Tag ersetzt, der aus der Entity abgeleitet ist — aus einer E-Mail wird [EMAIL], aus einer SSN wird [SSN], aus einer Kreditkarte [CREDIT_CARD] und so weiter. (Sie können den Ersatz-String pro benutzerdefinierter Entity überschreiben; siehe Masking-Formate.)
Input-Stage-Masking ist auf jedem Stream live. Es schreibt die Anfrage vor dem Modelllauf um, streamend oder nicht. Output-Stage-Masking gilt nur für nicht-streamende Responses — der maskierte Text wird weitergeleitet, nachdem die vollständige Antwort geprüft ist. Bei einer streamenden Response berechnet das Gateway die Maske, leitet aber den redigierten Text noch nicht weiter, sodass eine Mask-Regel eine streamende Antwort heute nicht redigiert; In-Stream-Output-Masking ist auf der Roadmap. (Ein Output-block kappt weiterhin einen Stream mittendrin — siehe §3.) Beweisen Sie Ihre exakte Stage/Stream-Kombination zuerst in der Sandbox. Siehe Streaming-Abdeckung.
Greifen Sie zu mask, wenn der Inhalt in Ordnung ist, aber ein Teilstring das Modell nicht erreichen soll — PII-Redaktion ist der kanonische Fall. Der schlüsselfertige Ausgangspunkt ist das PII Shield-Preset; siehe PII Shield.

​
5. flag — nur loggen, nichts ändern

Eine flag-Action ist nur beobachtend: die Anfrage ist byte-identisch zu einer ganz ohne Regel, außer dass ein Match im Matches-Feed aufgezeichnet wird. Nichts wird blockiert, nichts redigiert.
flag ist die Art, wie Sie eine Regel messen, bevor Sie sie durchsetzen. Liefern Sie ein neues Keyword oder eine Regex als flag aus, beobachten Sie den Matches-Feed für ein paar Tage, um die echte vs. Fehlalarm-Rate auf echtem Traffic zu sehen, und promoten Sie sie dann zu mask oder block, sobald Sie ihr vertrauen. Ein lautes Muster mit flag zu tunen schlägt das Entdecken der Fehlalarme in der Produktion mit block. Siehe Fehlalarme tunen.
Ein geflaggter Match zeichnet den Regeltyp, Action, Stage und einen Detail-String auf — und den gematchten Teilstring nur, wenn Log raw content für dieses Guardrail an ist (standardmäßig aus, die datenschutzfreundliche Haltung). Siehe Logging & Datenschutz.

​
6. Pro-Entity-Action-Overrides

Eine einzelne PII-Regel kann verschiedene Entities via entity_actions an verschiedene Actions routen, statt überlappende Regeln zu stapeln. Jeder Override-Wert muss einer von block / mask / flag / annotate sein und muss eine Entity referenzieren, die die Regel bereits deklariert — der Validator lehnt alles andere ab. 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
Diese eine Regel maskiert E-Mails, Telefonnummern und IPs, aber blockiert die Anfrage rundheraus bei einer Kartennummer oder SSN. Siehe benutzerdefinierte PII-Entities dazu, Ihre eigenen Detektoren unter demselben Override-Modell zu schichten.

​
7. Die richtige Action wählen

Wenn Sie … möchtenVerwenden SieEffekt
Die Anfrage ganz stoppenblockHTTP 400, kein Kontingent, skip-retry
Einen Teilstring entfernen, den Aufruf behaltenmaskRedigierter Text weitergeleitet
Beobachten, ohne Traffic anzufassenflagNur Match aufgezeichnet
Actions komponieren mit Stages. Dieselbe Action verhält sich auf Input vs. Output leicht anders — ein Input-Block spart Kontingent im Voraus; ein Output-Block erstattet es zurück; Output-Masking gilt nur für nicht-streamende Responses, während ein Output-Block streamende und nicht-streamende Responses gleichermaßen kappt. Lesen Sie Input-Stage und Output-Stage neben dieser Seite.

​
8. Wohin als Nächstes

Der guardrail_blocked-Fehler

Wie eine 400 aussieht, warum sie kein Kontingent kostet und wie skip-retry funktioniert.

Masking-Formate

Typisierte Tags, benutzerdefinierte Ersatz-Strings und wie sich ein maskierter Prompt für das Modell liest.

Streaming-Abdeckung

Genau welche Action-×-Stage-×-Stream-Kombinationen heute durchgesetzt werden.

Durchsetzungsmodi

Wie block / mask / flag auf das breitere Durchsetzungsmodell des Gateways abgebildet werden, einschließlich des Audit-Verdikts der Firewall.
Die Firewall hat ihr eigenes Verdikt-Vokabular (allow, audit, deny, sanitize und mehr) für Tool-Policy — verschieden von diesen Content-Actions. Siehe Guardrails vs. Firewall.