Offenlegung sensibler Daten und PII

Jeder Prompt, den Ihre App an ein Modell sendet, kann persönliche Daten tragen, die er nicht enthalten sollte — eine in ein Support-Ticket eingefügte E-Mail, eine SSN in einer CRM-Notiz, eine Kartennummer, die ein Nutzer in ein Chat-Feld getippt hat. Sobald dieser Text einen Upstream-Anbieter erreicht, ist er außerhalb Ihrer Kontrolle: geloggt, gecacht, vielleicht zum Training genutzt. Die Antwort des Modells kann PII ebenfalls zurückleaken, indem sie Details wiederholt oder ableitet, die dann in Ihren Anwendungs-Logs landen. Diese Seite zeigt, wie Sie ein LLM-PII-Leck am Gateway mit einem PII-Guardrail stoppen — einer workspace-bezogenen Regel, die sensible Entitäten auf dem Request maskiert oder blockiert, bevor das Modell sie je sieht. Es ist das Inhaltsebenen-Pendant zur Agent-Firewall und erfordert keine Änderung an Ihrem Anwendungscode.

Ein PII-Guardrail screent den Text von Prompts und Antworten. Um die Aktionen zu steuern, die ein Agent mit Daten vornimmt — Fetch-Tools, Egress-Hosts — siehe Datenexfiltration. Die beiden Ebenen komponieren; die meisten Teams betreiben beide.

1. Wie die Offenlegung passiert

PII erreicht einen Upstream-Anbieter durch ganz gewöhnlichen, gut gemeinten Traffic:

Ein Nutzer fügt seine eigenen Kontaktdaten in einen Chat ein, und Ihre App leitet die gesamte Nachricht wortwörtlich weiter.
Eine RAG-Pipeline ruft ein Dokument mit Kundendatensätzen ab und stopft es als Kontext in den Prompt.
Ein Agent liest eine Datenbankzeile und nimmt Rohfelder in ein Tool-Argument oder einen Folge-Prompt auf.
Die Antwort des Modells wiederholt oder schlussfolgert PII, die Ihre App dann in ihre eigenen Logs schreibt.

Nichts davon ist ein Angriff — es ist die normale Form von LLM-Apps. Die Abhilfe ist eine Policy, die jeden Request und jede Antwort an einem einzigen Engpass screent, statt jede Aufrufstelle in Ihrem Code zu auditieren.

2. Das LLM-PII-Leck mit einem PII-Guardrail abwehren

Ein Guardrail ist eine workspace-bezogene, benannte Inhalts-Policy. Eine pii-Regel darin erkennt sensible Entitäten und wendet eine Aktion auf jeden Treffer an:

Aktion	Effekt
`mask`	Jeden Treffer durch ein typisiertes Tag ersetzen — `jane@acme.com` → `[EMAIL]` — und den bereinigten Text weiterleiten. Das Modell sieht das Original nie.
`block`	Den gesamten Request mit HTTP 400 `guardrail_blocked` ablehnen. Verwenden Sie dies, wenn PII den Anbieter überhaupt nie erreichen darf.
`flag`	Nichts am Traffic ändern; einen Treffer aufzeichnen. Messen Sie die Exposition, bevor Sie durchsetzen.

Das Detektor-Set ist eingebaut und deterministisch — reines Pattern-Matching, kein Netzwerkaufruf, sicher auf dem Hot Path. Eingebaute Entitäten: email, phone, credit_card, ssn, ip, iban, mac_address, jwt, aws_access_key, api_key_openai, bitcoin_address, plus die checksummen-gesicherten regionalen Identifier jp_mynumber, kr_rrn und cn_resident_id. Bei einer mask-Aktion rendert jeder Treffer als sein typisiertes Tag — [EMAIL], [SSN], [CREDIT_CARD] und so weiter — sodass die Struktur des Prompts überlebt, während der Wert verschwunden ist.

Brauchen Sie einen Detektor, der nicht eingebaut ist (eine interne Mitarbeiter-ID, eine Kontonummer)? Fügen Sie eine benutzerdefinierte Entität hinzu — eine Regex mit optionaler Luhn-Prüfsumme, bis zu 25 pro Regel — direkt neben den eingebauten. Siehe die Guardrails-Referenz.

3. Konkretes Beispiel — PII auf dem Request maskieren

Der schnellste Start ist das PII-Shield-Preset: eine einzelne pii-Regel, die email, phone, ssn, credit_card und ip maskiert. Konfigurieren Sie es in der Konsole — keine Code-Änderungen, kein Key in diesem Schritt.

Das Guardrail erstellen

Öffnen Sie in der Konsole Guardrails und klicken Sie auf New guardrail. Wählen Sie das PII-Shield-Preset aus der pii-Kategorie, oder verfassen Sie von Hand eine pii-Regel mit der Aktion mask über den obigen Entitäten. Speichern. (Schreibvorgänge erfordern die Developer-Rolle oder höher.)

In der Sandbox beweisen

Öffnen Sie den Test-Tab, fügen Sie „reply to jane@acme.com” ein, wählen Sie die input-Stage und führen Sie aus. Die Sandbox gibt reply to [EMAIL] zurück — lokal, ohne Upstream-Aufruf und ohne verbrauchtes Kontingent.

An einen Key anhängen

Bearbeiten Sie unter API Keys einen Key und wählen Sie das Guardrail aus dem Guardrail-Dropdown, oder setzen Sie das Guardrail als Workspace-Default, sodass jeder nicht angehängte Key es erbt. Die Bindung lebt am Key im Gateway.

Das Gateway wie gewohnt aufrufen

Mit diesem Key ist Ihr Relay-Aufruf unverändert:

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": "Draft a reply to jane@acme.com"}
    ]
  }'

Das Gateway schreibt die E-Mail zu [EMAIL] um, bevor es weiterleitet. Das Upstream-Modell erhält die Adresse nie.

PII-Shield ist eine both-Stage-Regel, aber das live ausgelieferte Verhalten ist heute die Maskierung auf der Request-Stage — das Gateway maskiert den Prompt, bevor er zum Modell aufbricht. Die Maskierung auf der Output-Stage (Antwort) auf dem Live-Relay ist auf der Roadmap. Um zu verifizieren, wie sich eine Regel auf der Output-Stage verhält, werten Sie sie im Test-Tab aus. Für Streaming siehe §5.

4. Das meiste maskieren, das Schlimmste blockieren — Pro-Entität-Overrides

Eine einzelne Regel kann via entity_actions unterschiedliche Aktionen auf unterschiedliche Entitäten anwenden. Maskieren Sie risikoarme Identifier, aber hart-blockieren Sie die Entitäten, die Sie nie weitergeleitet haben wollen — eine Regel statt dreier überlappender:

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

Hier werden E-Mails, Telefonnummern und IPs maskiert und durchgelassen; ein Prompt, der eine Kartennummer oder SSN trägt, wird stattdessen mit HTTP 400 guardrail_blocked abgelehnt. Ein blockierter Request kostet kein Kontingent — ein Block auf der Input-Stage feuert vor der Messung — und ist als skip-retry markiert. Jeder entity_actions-Key muss eine auf der Regel deklarierte Entität sein (eingebaut oder benutzerdefiniert); seine Aktion wird gegen das Aktions-Set der Regel validiert.

5. Was heute beim Streaming funktioniert

Aktion und Stage interagieren unterschiedlich mit dem Streaming — kennen Sie die Matrix, bevor Sie sich darauf verlassen:

Input-Stage mask oder block (jeder Antwortmodus)

Vollständig live. Der Prompt wird vor dem Upstream-Aufruf gescreent, sodass Maskieren und Blockieren identisch funktionieren, ob die Antwort streamt oder nicht. Das ist die Surface, die PII-Shield heute durchsetzt.

Output-Stage block

Durchgesetzt auf streamenden und nicht-streamenden Antworten. Bei einem Stream schneidet ein Scanner den Stream mitten im Flug und gibt eine Ersatznachricht aus, bevor blockierter Inhalt den Client erreicht; ein Output-Block erstattet das vorab verbrauchte Kontingent.

Output-Stage mask

Derzeit nur nicht-streamend. Bei einer gestreamten Antwort passiert der ursprüngliche Chunk unmaskiert — In-Band-Stream-Umschreibung ist eine geplante Erweiterung. Für Antwort-Maskierung heute verwenden Sie nicht-streamende Requests oder verlassen Sie sich auf die Maskierung auf der Input-Stage. Beweisen Sie Ihre exakte Stage/Stream-Kombination zuerst im Test-Tab.

6. Sehen, was abgefangen wurde

Jede Regel, die feuert, zeichnet einen Match auf — Typ, Aktion, Stage und einen Detail-String — sichtbar auf dem Workspace-Matches-Feed (GET /api/guardrail/match, für jedes Mitglied offen). Von dort aus können Sie gruppieren, filtern, nach CSV exportieren und Falsch-Positive markieren.

Rohwerte werden standardmäßig nicht geloggt. Der Log raw content-Schalter eines Guardrails ist aus — die datenschutzkonservative Haltung — sodass der Matches-Feed aufzeichnet, dass eine PII-Regel gefeuert hat und welche Entität, aber nicht den gematchten Teilstring (die E-Mail-Adresse selbst). Schalten Sie ihn pro Guardrail nur ein, wenn Sie den Wert für die Triage brauchen; die Einstellung ist nicht rückwirkend. PII in Ihrem eigenen Audit-Trail zu erfassen, um ein PII-Leck zu debuggen, wäre selbstzerstörerisch.

7. Weitergehen

Für vollständige Residency-, Retention- und Recht-auf-Löschung-Kontrollen — einschließlich der Installation eines Compliance-Packs, das diese Guardrails für GDPR, HIPAA oder PCI DSS materialisiert — starten Sie von den Referenzseiten unten.

Guardrails-Referenz

Jeder Regeltyp, jede Stage, jede Aktion, benutzerdefinierte Entitäten, Versionierung und das Eval-Harness — die tiefe Referenz hinter dieser Seite.

Secret-Leakage

Das anmeldedaten-förmige Geschwister — AWS-, OpenAI-, GitHub-Tokens — abgefangen vom Secrets-Blocker-Guardrail.

Unsichere Ausgabe

Screenen, was das Modell zurücksendet, nicht nur, was es empfängt.

Guardrails vs. Firewall

Wann Text zu screenen und wann Aktionen zu steuern sind — und warum Sie meist beides wollen.

​1. Wie die Offenlegung passiert

​2. Das LLM-PII-Leck mit einem PII-Guardrail abwehren

​3. Konkretes Beispiel — PII auf dem Request maskieren

​4. Das meiste maskieren, das Schlimmste blockieren — Pro-Entität-Overrides

​5. Was heute beim Streaming funktioniert

​6. Sehen, was abgefangen wurde

​7. Weitergehen

Guardrails-Referenz

Secret-Leakage

Unsichere Ausgabe

Guardrails vs. Firewall

1. Wie die Offenlegung passiert

2. Das LLM-PII-Leck mit einem PII-Guardrail abwehren

3. Konkretes Beispiel — PII auf dem Request maskieren

4. Das meiste maskieren, das Schlimmste blockieren — Pro-Entität-Overrides

5. Was heute beim Streaming funktioniert

6. Sehen, was abgefangen wurde

7. Weitergehen