Zum Hauptinhalt springen
Wenn Sie sensible Daten maskieren müssen, die ein LLM-Prompt trägt — E-Mails, Kartennummern, nationale IDs, Secrets — schreibt das Gateway jeden Treffer an Ort und Stelle um, bevor das Modell ihn sieht. Ein maskierter Wert wird zu einem typisierten Tag (jane@acme.com → [EMAIL]), sodass das Modell weiterhin einen kohärenten Prompt liest, während der Rohwert Ihren Workspace nie verlässt. Diese Seite ist der fokussierte Blick darauf, was Masking rendert, wie man den Tag ändert und wie man auf einer einzelnen Regel manche Entities maskiert, während man andere blockiert. Für die vollständige Engine — jeder Regeltyp, jede Stage, jede Route — siehe die Guardrails-Referenz, und für Masking speziell auf der Anfrage Input-Stage-Regeln.

​
1. Sensible Daten in LLM-Prompts mit typisierten Tags maskieren

Eine pii-Regel mit der mask-Action erkennt eine Entity und ersetzt jeden Treffer durch einen typisierten Redaktions-Tag — ein großgeschriebenes Label in Klammern, das benennt, was entfernt wurde, ohne den Wert preiszugeben:
EntityGerenderter Tag
email[EMAIL]
credit_card[CREDIT_CARD]
ssn[SSN]
Der vollständige eingebaute Detektor-Satz — email, phone, credit_card, ssn, ip, iban, mac_address, jwt, aws_access_key, api_key_openai, bitcoin_address, plus die regionalen jp_mynumber, kr_rrn und cn_resident_id — rendert jeweils seinen eigenen Klammer-Tag ([PHONE], [IBAN], [JP_MYNUMBER] und so weiter). Der Tag ist deterministisch: dieselbe Entity rendert immer dasselbe Label, sodass nachgelagerte Prompts stabil bleiben und Ihre Logs sich sauber lesen.
Typisierte Tags schlagen ein pauschales [REDACTED] für die Modellqualität. Das Modell weiß weiterhin, dass es eine E-Mail vs. eine Kontonummer vs. eine Telefonnummer ansieht, sodass es weiter über die Form der Daten schlussfolgern kann — „reply to [EMAIL]” bleibt eine umsetzbare Anweisung — ohne je den echten Wert zu halten.
Input-Masking ist vollständig live — das Gateway schreibt den Prompt um, bevor er das Modell erreicht, streamend oder nicht. Output-Masking ist bei nicht-streamenden Responses ebenfalls live: eine mask-Regel an der Output-Stage schreibt die Completion um, bevor sie zurückkehrt. Nur streamendes Output-Masking ist auf der Roadmap; bei einer gestreamten Antwort bevorzugen Sie block an der Output-Stage. Siehe Streaming-Abdeckung für die exakte Stage/Stream-Matrix.

​
2. Ein konkretes Beispiel

Verfassen Sie die Regel in der Konsole unter Ihrer eigenen Session — Guardrail-Config erfordert Developer+, keinen Relay-Key. Fügen Sie einem Guardrail namens pii-shield eine einzelne pii-Regel hinzu: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ssn"]
}
Hängen Sie es an einen Key an (setzen Sie guardrail_id oder markieren Sie es als Workspace-Default — siehe An einen Key anhängen), rufen Sie dann das Gateway mit diesem sk-orca-...-Relay-Key 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 about her SSN 123-45-6789"}
    ]
  }'
Das Gateway schreibt den Prompt vor dem Weiterleiten zu “Reply to [EMAIL] about her SSN [SSN]” um. Das Upstream-Modell sieht weder die Adresse noch die Nummer. Beweisen Sie das exakte Rendering zuerst im Tab Test des Editors (kein Upstream-Aufruf, kein Kontingent) — siehe Testing & Eval.

​
3. Den Tag mit mask_with überschreiben

Eingebaute Entities rendern einen festen Tag. Benutzerdefinierte Entities — Ihre eigenen Regex-Detektoren, über den eingebauten Satz geschichtet — lassen Sie den Ersatztext selbst mit mask_with setzen: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "custom_entities": [
    {
      "name": "employee_id",
      "pattern": "EMP-[0-9]{6}",
      "mask_with": "[STAFF_ID]"
    }
  ]
}
mask_with ist der wortwörtliche Ersatz-String für die Treffer dieser Entity. EMP-004217 wird zu [STAFF_ID]. Lassen Sie es leer, und der Treffer rendert den Standard-Tag [<UPPERCASE_NAME>] — hier, [EMPLOYEE_ID] — sodass ein benutzerdefinierter Detektor selbst ohne Override immer eine lesbare, typisierte Redaktion produziert.
name (Kleinbuchstaben-ASCII / Ziffern / Unterstrich, muss mit einem Buchstaben beginnen), pattern (eine Go-RE2-Regex — lineare Zeit, keine Backreferences), optionale checksum (luhn validiert kartenförmige Nummern) und optionales mask_with. Bis zu 25 benutzerdefinierte Entities pro Regel — jede ist ein Scan über den vollständigen Text, sodass das Limit den heißen Pfad linear hält. Siehe Benutzerdefinierte PII-Entities.
Ein name fließt unquoted in Audit-Logs und den Matches-Feed, halten Sie ihn also auf Kleinbuchstaben-ASCII-Buchstaben, Ziffern und Unterstriche, mit einem Buchstaben beginnend (z. B. employee_id, internal_ticket). Der Validator lehnt alles andere ab.

​
4. Manche Entities maskieren, andere blockieren — entity_actions

Eine einzelne pii-Regel kann verschiedene Actions auf verschiedene Entities anwenden, via entity_actions, statt drei überlappende Regeln zu stapeln. Die klassische Form: niedrigsensible Kontaktdaten maskieren, aber die hochsensiblen Felder rundheraus blockieren. 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
Hier folgen email, phone und ip der Top-Level-mask der Regel und rendern [EMAIL] / [PHONE] / [IP]; ein credit_card- oder ssn-Treffer blockiert stattdessen die gesamte Anfrage mit HTTP 400 guardrail_blocked.
FeldRegel
KeysMuss eine auf der Regel deklarierte Entity sein (eingebaut oder benutzerdefiniert).
Werteblock, mask, flag oder annotate.
Ein blockierter Request kostet kein Kontingent — ein Block der Input-Stage feuert vor der Messung. Ein maskierter Request geht mit dem bereinigten Text durch. So kann eine Regel die routinemäßigen Felder still redigieren und die regulierten hart stoppen, mit einer einzigen Bindung und ohne Änderung in der Anwendung.

​
5. Mask vs. block vs. flag

Masking ist eine der Actions, die eine Regel (oder ein Pro-Entity-Override) ergreifen kann. Wählen Sie danach, wie sehr Sie den Traffic stören möchten:

mask

Den Treffer zu einem typisierten Tag redigieren und die Anfrage mit dem bereinigten Text durchlassen. Das Modell sieht den Rohwert nie.

block

Die gesamte Anfrage mit HTTP 400 guardrail_blocked ablehnen. Nichts erreicht das Modell. Verwenden Sie es für Daten, die nie transitieren dürfen.

flag

Nichts am Traffic ändern — nur einen Match aufzeichnen. Messen Sie, wie oft eine Regel feuern würde, bevor Sie sie durchsetzen.
Ein guter Rollout ist flag → mask → block: flag, um den Impact zu dimensionieren, mask, sobald Sie dem Detektor vertrauen, und block reservieren Sie für die Felder, die Sie gar nicht durchlassen können. Siehe Actions und Fehlalarme tunen.

​
6. Verifizieren, was maskiert wurde

Jede Regel, die feuert, zeichnet einen Match im Workspace-Matches-Feed auf — Regeltyp, Action, Stage und einen Detail-String. Der gematchte Teilstring selbst (die rohe E-Mail, die tatsächliche Kartennummer) wird nur aufgezeichnet, wenn Log raw content an ist, was standardmäßig aus ist — die datenschutzfreundliche Haltung, da der ganze Sinn ist, Rohwerte aus Ihren Logs herauszuhalten.
Schalten Sie Log raw content nur ein, wenn Sie den Teilstring wirklich zum Triage brauchen, und nur pro Guardrail. Mit ihm aus beweist der Feed, dass eine [CREDIT_CARD] maskiert wurde, ohne je die Nummer zu speichern. Der Toggle ist nicht rückwirkend. Siehe Logging & Datenschutz.

​
7. Wohin als Nächstes

Lesen Sie die Guardrails-Referenz für die vollständige Engine oder PII-Exposition und Secret-Leakage für die Bedrohungen, die Masking eindämmen soll.