Datenmaskierung im AI Gateway: Was wirklich funktioniert

Was Datenmaskierung tatsächlich ist

Datenmaskierung ersetzt einen sensiblen Wert durch einen Ersatzwert, der sicher offengelegt werden kann, während die umgebenden Daten nutzbar bleiben. Konzeptuell stammt dies aus der Datenbankwelt: Man gibt der QS eine Kopie der Produktion, in der jede Kartennummer als 4111-****-****-1234 dargestellt wird. So können realistische Strukturen getestet werden, ohne echte PII offenzulegen. Wendet man dies auf ein LLM Gateway an, ändert sich die Dynamik: Sie maskieren Freitext auf dem Weg zu einem Drittanbieter innerhalb einer Konversation, die weiterhin Sinn ergeben muss.

Diese Begriffe werden ständig als Synonyme verwendet. Es sind jedoch keine Synonyme.

Reversibel vs. irreversibel ist die entscheidende Unterscheidung. Tokenisierung, FPE und Verschlüsselung erlauben einen Round-Trip – jemand besitzt einen Vault oder einen Schlüssel, also ein neues Asset, das geschützt werden muss. Maskierung, Schwärzung und Anonymisierung sind Einwegverfahren: einfacher, sicherer und nutzlos, sobald ein nachgelagertes System den echten Wert benötigt.

Pseudonymisierung ist keine Anonymisierung. Unter der DSGVO gelten pseudonymisierte Daten weiterhin als personenbezogene Daten und fallen in den Anwendungsbereich; nur echt anonymisierte Daten fallen nicht unter die Verordnung (Erwägungsgrund 26). Das Ersetzen jedes Namens durch eine stabile User-8812-ID ist Pseudonymisierung, und diese als Anonymisierung zu bezeichnen, wird einer rechtlichen Prüfung nicht standhalten.

Eine dritte Dimension wird leicht übersehen: Konsistenz ist unabhängig von der Reversibilität. Ein Maskierer kann deterministisch sein – dieselbe Eingabe erzeugt immer denselben Platzhalter –, ohne reversibel zu sein. Und Genauigkeit/Determinismus ist das, was es einem Modell ermöglicht, über eine Konversation hinweg logisch über „dieselbe Person“ zu urteilen.

Was bricht, wenn Sie LLM-Traffic maskieren

Dies ist der Teil, den die meisten Beiträge überspringen, der aber darüber entscheidet, ob Ihr Design in der Praxis besteht.

Die Modell-Ausgabequalität verschlechtert sich ungleichmäßig. Machen Sie aus Rufen Sie unser Büro unter 312-555-1234 an ein Rufen Sie unser Büro unter ************ an, weiß das Modell nicht mehr, dass es sich um eine Telefonnummer handelte – Sternchen tragen keine Typinformationen. Benannte Platzhalter wie [PHONE_NUMBER] bewahren den Typ, allerdings um den Preis, dass jeder, der den Prompt sieht, erfährt, was dort stand. Zusammenfassungen stört das kaum; Extraktionen schlagen fehl; das Korrelieren zweier Entitäten schlägt stillschweigend fehl, was noch schlimmer ist.

Tool Calls benötigen den echten Wert. Das gravierendste Problem: Ein Agent, der customer@acme.com auf dem Hinweg maskiert, kann danach nicht lookup_account(email=...) aufrufen. Das Maskieren des Modellpfads bei gleichzeitigem Offenlassen des Tool-Pfads erzeugt das entgegengesetzte Sicherheitsloch: Das Modell hat die Adresse nie gesehen, aber die Tool-Argumente übertragen sie an einen externen MCP-Server. Entscheiden Sie pro Tool, welchem Pfad Sie mehr vertrauen.

Strukturierte Ausgaben und JSON-Schemas brechen. Wenn Sie Structured Outputs mit JSON Schema nutzen, kann die Maskierung einen Wert erzeugen, der das eigene Feld nicht mehr erfüllt: Ein format: email-Feld kann [REDACTED EMAIL] nicht aufnehmen, und ein Integer-Feld kann keine Sternchen enthalten. Längenerhaltende Maskierung ist verträglicher, da sie die Form wahrt. Das Maskieren des Ausgabe-Strangs ist besonders problematisch – das Modell hat gültiges JSON erzeugt, der Maskierer hat einen Wert darin umgeschrieben, und Ihr Parser wirft einen Fehler bei einer Antwort, die das Modell korrekt generiert hat.

Konsistenz über mehrere Dialogschritte (Multi-Turn). Schritt eins: „Priya Raman ist die Kontoinhaberin.“ Schritt vier: „Ist sie immer noch die Inhaberin?“ Wenn Schritt eins zu Sternchen wurde, hat das Modell keinen Anhaltspunkt mehr. Deterministische Pseudonymisierung löst dies, aber nur, wenn der Maskierer den Zustand über mehrere Schritte hinweg aufrechterhält – was eine zustandslose Guardrail nicht tut.

RAG-Retrieval auf maskiertem Text. Maskieren Sie Dokumente vor der Indizierung, enthält das Embedding die Entität nicht mehr. Eine Suchanfrage danach wird den betreffenden Chunk nicht finden. Indizieren Sie unmaskiert und maskieren erst beim Retrieval, speichert Ihr Vektorstore den unmaskierten Korpus – genau das, was Sie vermeiden wollten.

Gezielt eingesetzt ist Maskierung wertvoll. Global angewendet verschlechtert sie schleichend das Produkt, ohne dass jemand den Zusammenhang erkennt.

Wo Teams Fehler machen

Die Annahme, dass Maskierung automatisch reversibel ist. Ein Team maskiert PII auf dem Weg zum Modell, nimmt an, dass auf dem Rückweg eine Demaskierung stattfindet, und baut darauf auf. Sofern Sie kein reversibles Schema gewählt haben und Schlüssel verwaltet werden, sieht auch der Aufrufer nur den maskierten Wert.

Den Prompt maskieren, aber den Tool-Pfad vergessen. Daten bewegen sich an vier Stellen: in das Modell, aus dem Modell, in ein Tool, aus einem Tool. Nur einen Bereich abzudecken, ist ein häufiger Fehler. Leaks entstehen dann über ein Tool-Ergebnis, das niemand überprüft hat.

Log-Schwärzung als Datenflusskontrolle betrachten. Das Schwärzen gespeicherter Logs schränkt lediglich ein, wer in Ihrem Unternehmen Prompts lesen kann. Der Provider hat den ursprünglichen Text trotzdem erhalten.

Irreversible Maskierung für ein reversibles Problem wählen. Wenn ein nachgelagertes System den ursprünglichen Wert zurückbenötigt, ist Maskierung die falsche Technik. Sie benötigen Tokenisierung oder FPE, was wiederum einen Vault oder Schlüssel erfordert.

Wie Maskierung in TrueFoundry funktioniert

Maskierung ist hier kein einzelnes, separates Produkt. Jede Guardrail verfügt über zwei Einstellungen – Operation Mode und Enforcement Strategy – wobei Maskierung ein Wert der ersten Einstellung ist.

Mutate vs. Validate

Die Priorität bestimmt das gesamte Ausführungsmodell für die Maskierung. Drei Mutate-Guardrails an einem Hook laufen der Reihe nach ab, wobei jede das Ergebnis der vorherigen sieht: Eine Secrets-Maskierung bei Priorität 1 und eine Regex-Maskierung bei Priorität 2 bedeutet, dass die Regex-Guardrail auf Text trifft, der bereits ***REDACTED*** enthält.

Eingabe-Mutation blockiert und läuft zuerst – die Modellanfrage kann erst starten, wenn der Prompt final ist. Die Eingabe-Validierung läuft anschließend im Hintergrund parallel dazu. Schlägt die Validierung während des Aufrufs fehl, bricht das Gateway die Modellanfrage ab, sodass keine unberechtigten Kosten entstehen. Ausgabe-Mutation und -Validierung laufen synchron ab, nachdem die Antwort eingetroffen ist – zu diesem Zeitpunkt sind die Modellkosten bereits angefallen.

MCP-Tool-Calls fügen zwei synchrone Hooks hinzu: Pre-Invoke (ein Fehler verhindert die Ausführung des Tools) und Post-Invoke (ein Fehler hält das Ergebnis zurück). Guardrails werden für jeden Tool Call separat ausgeführt – fünf Tools bedeuten fünf Prüfdurchläufe.

Enforce vs. Enforce But Ignore On Error

Die zweite Einstellung unterscheidet zwischen zwei Fehlerfällen: Die Guardrail hat etwas gefunden versus die Guardrail ist selbst abgestürzt.

Strategie

Bei Verstoß

Bei Guardrail-Fehler

Enforce

Blockieren

Blockieren (Fail-Closed)

Enforce But Ignore On Error

Blockieren

Durchlassen (Graceful Degradation)

Audit

Durchlassen, nur protokollieren

Durchlassen

Die Dokumentation bezeichnet Enforce But Ignore On Error als den „sichersten Standardwert“ und empfiehlt die schrittweise Einführung: Audit → Enforce But Ignore On Error → Enforce.

Welche integrierten Guardrails tatsächlich maskieren können

Aussagen wie „Wir haben eine PII-Guardrail“ verraten noch nichts darüber, ob sie auch maskieren kann.

PII / PHI Detection ist eine Ausnahme: Sie kann nicht blockieren, sondern nur maskieren. Wenn die Anforderung lautet „jede Anfrage mit einer Sozialversicherungsnummer ablehnen“, ist dies die falsche Guardrail.

Die dokumentierten Optionen für die Durchsetzungsstrategie sind hierbei nur enforce und enforce_but_ignore_on_error – Audit ist nicht aufgeführt, im Gegensatz zu Secrets, Regex und SQL Sanitizer. Die schrittweise Einführung über den Audit-Modus ist bei den integrierten Optionen somit nicht einheitlich.

Regex Pattern Matching erzeugt benannte Platzhalter anstelle von Sternchen. Es enthält 46 vordefinierte Vorlagen – Sozialversicherungsnummern, Kreditkarten, Reisepässe für zehn Länder, Cloud-Keys, GitHub- und Slack-Tokens, IPs – sowie benutzerdefinierte Muster wie EMP-\d{6} → [REDACTED EMPLOYEE ID].

Unter den Guardrail-Integrationen von Drittanbietern gehören zu den Mutate-fähigen Optionen: Google Model Armor, CrowdStrike AIDR, F5 AI Security, TrojAI, Enkrypt AI, Pillar Security, Lasso (classifix), HiddenLayer (/redact-*), DeepKeep und Noma – die letzten beiden erfordern zwingend Mutate. Nur Validate unterstützen: Cisco AI Defense, Gray Swan Cygnal, Patronus, NVIDIA NeMo, Guardrails AI, Arthur AI. Ein Anforderungsprofil zur Maskierung an einen reinen Validate-Anbieter zu stellen, führt nicht zum Ziel.

Google Model Armor birgt eine Falle bei der Einrichtung: Mutate benötigt in der Google Cloud sowohl ein SDP Inspect Template als auch ein De-Identify Template, die mit dem Model Armor Template verknüpft sind, wobei die Transformation auf „Replace with infoType name“ gesetzt sein muss. Fehlt eines von beiden, schlägt die Mutation fehl.

Die Frage nach der Demaskierung klar beantwortet

Die eigenen Maskierungs-Guardrails von TrueFoundry arbeiten in eine Richtung (Einweg). Das Modell sieht den maskierten Wert, und der Aufrufer sieht ihn ebenfalls. Für PII / PHI Detection, Secrets Detection und Regex Pattern Matching gibt es keinen dokumentierten Weg zur Wiederherstellung des Originals. Es existiert auf Gateway-Ebene derzeit kein Token-Vault oder Rehydrierungsschritt.

Es gibt genau einen dokumentierten Round-Trip, und dieser stammt von einem Drittanbieter. CrowdStrike AIDR unterstützt formaterhaltende Verschlüsselung (FPE): Wenn die Operation auf Mutate steht und die Eingabeseite Werte mit FPE verschlüsselt hat, übergibt das Gateway den resultierenden fpe_context auf der Ausgabeseite als input_fpe_context an AIDR zurück und ruft POST {baseUrl}/v1/unredact auf. Dadurch werden durchgehend dieselben Schlüssel verwendet. Dies ist ein echter reversibler Pfad – er erfordert jedoch CrowdStrike, den Mutate-Modus und einen fpe_context aus dem Eingabestrang.

Wenn Ihre Anwendung den echten Wert auf der Rückroute benötigt, planen Sie nicht ein, diesen vom Gateway zu erhalten. Belassen Sie den Wert in Ihrer Anwendung, übergeben Sie die maskierte Version und führen Sie die Daten über eine von Ihnen verwaltete ID wieder zusammen. Ein verwandtes AIDR-Verhalten überrascht viele: Sobald eine Verletzung festgestellt wird, wandelt Mutate diese nicht in eine bloße Schwärzung um – die Anfrage wird weiterhin mit einem HTTP 400 abgebrochen.

Ein praktisches Beispiel: Ein interner Support-Copilot

Ein Support-Copilot liest Ticket-Texte und ruft Kontodaten über einen MCP-Server ab. Die Tickets enthalten regelmäßig Kunden-E-Mails, Telefonnummern und interne Mitarbeiter-IDs.

Bestimmen Sie, was den Provider niemals erreichen darf. E-Mails und Telefonnummern: maskieren. Mitarbeiter-IDs: mit einem Label maskieren, damit das Modell zwei Mitarbeiter in einem Ticket weiterhin unterscheiden kann. Aus Versehen eingefügte Anmeldedaten: auch auf dem Ausgabeweg maskieren.

Modi und Prioritäten wählen. PII / PHI Detection bei LLM Input, Mutate (der einzige Modus), Priorität 1. Regex Pattern Matching bei LLM Input, Mutate, Priorität 2, benutzerdefiniertes Muster EMP-\d{6} → [REDACTED EMPLOYEE ID]. Secrets Detection bei LLM Output, Mutate. Starten Sie jeweils mit der tolerantesten unterstützten Strategie.

Den Tool-Pfad bewusst festlegen. Die Kontosuche benötigt die echte E-Mail-Adresse, daher zielt die Maskierungsregel auf das Modell ab, nicht auf den MCP-Server. Secrets Detection wird stattdessen bei MCP Post-Invoke ausgeführt, um Anmeldedaten abzufangen, die in einem Tool-Ergebnis zurückgeliefert werden. Der Grund dafür: Der MCP-Server befindet sich in Ihrer VPC, der Modellprovider hingegen nicht.

Über eine Policy zuweisen. Das bloße Registrieren einer Guardrail wendet diese noch nicht auf den Traffic an. Navigieren Sie zu AI Gateway → Policies → Guardrails → Add Rule und grenzen Sie den Bereich nach Targets (Modelle, MCP-Server, optional pro Tool), Subjects (Benutzer, Teams, virtuelle Konten mit IN / NOT IN), Metadaten und Hooks ein. Übereinstimmende Regeln werden pro Hook zusammengeführt.

Überwachen vor dem Produktivbetrieb. Jede Guardrail bildet einen eigenen Span in Monitor → Request Traces ab, inklusive Ausführungszeit, Ergebnis, Scope, Eingabe, Ausgabe und Mutationen. Eine Mutationsrate nahe null an einem stark frequentierten Hook deutet auf fehlerhafte Muster hin; eine Rate nahe 100 % bedeutet, dass Sie in Kürze erfahren werden, wie sich die Maskierung auf die Antwortqualität auswirkt.

Bereit, es auf einer Route zu testen?

Registrieren Sie eine PII-Guardrail, weisen Sie einem Modell eine Policy zu und analysieren Sie die Mutation-Spans.

Kostenlos starten

Wichtige Fallstricke in der Praxis

Maskierung funktioniert nicht bei gestreamter Ausgabe. Ausgabe-Guardrails werden vollständig übersprungen, wenn "stream": true gesetzt ist, da die Evaluierung einer Antwort den vollständigen Text erfordert. Eingabe-Guardrails sind davon nicht betroffen. Da die meisten Chat-Interfaces standardmäßig streamen, ist die ausgabeseitige Maskierung auf der von Benutzern genutzten Oberfläche in diesen Fällen inaktiv.

System-Prompts werden niemals maskiert. Das Gateway entfernt diese, bevor der Inhalt an Guardrails übergeben wird. Sie werden daher weder geprüft, blockiert noch geschwärzt. Die einzige Ausnahme bildet CrowdStrike AIDR, welches den System-Prompt zwar sieht, aber niemals verändert. Wenn Sie einen Schlüssel in einen System-Prompt einfügen, kann keine Maskierungs-Guardrail dies verhindern.

Log-Schwärzung ist eine andere Steuerung als Mutate. Die regelbasierte Logging Configuration von TrueFoundry schwärzt Muster in gespeicherten Request-Bodies mit Deny-Wins-Semantik – eine einzelne treffende Regel mit deaktiviertem Log unterdrückt den gesamten Body. Die Dokumentation stellt jedoch klar: „Schwärzung wird nur auf die protokollierte Kopie angewendet… Der Live-Request, der an den Modellprovider weitergeleitet wird, wird niemals verändert.“ Dies steuert, wer intern Prompts lesen kann, nicht was das Unternehmen verlässt. Unser Beitrag zu Data Loss Prevention für LLM-Traffic behandelt die Egress-Seite.

Die Reihenfolge kann eine Blockierung verhindern. DeepKeep dokumentiert dies explizit: Es gilt die Priorität der an oberster Stelle aufgeführten Guardrail unter den ausgelösten Regeln, nicht die strengste Aktion. „Wenn PII vor Adversarial aufgeführt ist, wird ein Jailbreak, der auch PII auslöst, maskiert und zugelassen, anstatt blockiert zu werden.“ Dies gilt allgemein für Mutate-Ketten: Platzieren Sie Guardrails, die zwingend blockieren müssen, vor Guardrails, die maskieren.

PII / PHI Detection ist nur TrueFoundry-gehostet verfügbar. Sie läuft auf Azure AI Language und steht in Self-Hosted- oder hybriden Deployments („Gateway Plane only“) nicht zur Verfügung. Verwenden Sie in solchen Fällen Azure PII mit Ihrem eigenen Schlüssel oder CrowdStrike.

Verwandte Artikel

• Data Loss Prevention für LLM-Traffic – die Erkennungs- und Egress-Seite
• PII-Schwärzung: Gateway vs. Anwendung – wo die Kontrolle angesiedelt sein sollte
• TrueFoundry AI Gateway Guardrails erklärt – das vollständige Guardrail-Modell
• LLM Structured Outputs und JSON Schema – warum Maskierung und Schemas kollidieren
• Aufbau eines AI Governance Frameworks – die übergeordnete Richtlinienebene

Fazit

Datenmaskierung ist eine effektive Schutzmaßnahme, die jedoch häufig fehlerhaft angewendet wird. Ursache ist selten der Maskierer selbst, sondern die falschen Annahmen im Umfeld: dass Maskierung automatisch reversibel sei, dass der Tool-Pfad abgedeckt sei, dass Log-Schwärzung dasselbe sei oder dass das Modell mit Sternchen ebenso gut logische Schlüsse ziehen könne.

Vier Entscheidungen sollten Sie vorab definieren: Welche Entitätstypen dürfen das System keinesfalls verlassen? Auf welchem der vier Hooks läuft jede Regel? Benötigt ein nachgelagertes System den ursprünglichen Wert zurück (denn diese Antwort entscheidet zwischen Maskierung und Tokenisierung)? Und welche Einbußen bei der Ausgabequalität sind akzeptabel – gemessen, nicht angenommen.

Bauen Sie das Setup anschließend gezielt auf: Starten Sie im Audit-Modus (sofern von der Guardrail unterstützt), analysieren Sie eine Woche lang die Traces, wechseln Sie zu Enforce But Ignore On Error und nutzen Sie die vollständige Enforce-Strategie für Routen, bei denen ein Fail-Closed-Verhalten zwingend erforderlich ist. Ein Gateway ist der geeignete Ort für diese Aufgaben – als zentraler Durchgangspunkt für jedes Modell, jedes Team und jeden Agenten. Eine Maskierungsregel, die Sie nicht im Betrieb beobachtet haben, ist jedoch eine Regel, die Sie nicht vollständig unter Kontrolle haben.

Richten Sie die Maskierung für eine Route ein und analysieren Sie die Traces

Kostenlos starten