PII-Maskierung

PII-Maskierung für KI-Agenten — Sensitivitätsklassifikation auf Feldebene

Auf dem Agenten-Ergebnispfad ersetzt FutrixData sensible Ergebniswerte durch secret-basierte, gesalzene Hash-Strings, bevor die Zeile an MCP-, Skill- oder CLI-Aufrufer zurückgeht. Die Substitution ist ein secret-basierter deterministischer Hashing-Algorithmus; der Schlüssel wird aus einem im OS-Secret-Store abgelegten lokalen Secret abgeleitet. Determinismus ist der Punkt: Agenten können weiterhin joinen, gruppieren und zählen, ohne je Rohwerte zu sehen.

macOS herunterladen Zur Dokumentation

Was PII-Maskierung im KI-Kontext bedeutet

Klassische Maskierung schreibt einen Wert vor der Speicherung oder vor der Anzeige in einer UI um. PII-Maskierung für KI-Agenten verschiebt das Umschreiben an den Datenausgang — auf den Moment, in dem eine Zeile Ihre Datenbank in Richtung LLM-Kontext verlässt. Der Agent erhält weiterhin eine Zeile mit dem richtigen Datenformat, den richtigen Joins und stabiler Gleichheitssemantik; er bekommt nur masked:v1:8f3a1c9b72e04d11 statt alice@example.com.

Das ist wichtig, weil Daten, sobald sie im Kontext eines Agenten sind, an externe Modelle, Plugins, Log-Systeme, Debug-Captures und Token-Relay-Dienste weiterfließen können — Orte, an die Enterprise-Governance nicht reicht.

Fünfstufige Sensitivitätsklassifikation (erweiterbar)

FutrixData liefert ein L1–L5-Klassifikationsmodell. Die Stufen sind konfigurierbar; Standardwerte sind unten.

Stufe	Bedeutung	Beispiele
L1 Public	Nicht-sensible Geschäftsdaten	`id`, `status`, `created_at`
L2 Internal	Interne Identifikatoren und Metadaten	`user_id`, `session_id`, `request_id`
L3 Confidential	Indirekte personenbezogene Daten, Verhalten, Standort	`ip_address`, `user_agent`, `device_id`
L4 Sensitive	Direkte personenbezogene Daten, Finanzen, Gesundheit	`email`, `phone`, `salary`, `date_of_birth`
L5 Critical	Credentials, Zahlungsmittel, hochsensible PII	`password`, `credit_card`, `api_secret`, `home_address`

Standardmäßig erhalten Agenten L1–L3 im Klartext. L4 und L5 werden durch stabile Hashes ersetzt, bevor sie den Agenten erreichen. Der für Agenten zugängliche Bereich ist editierbar — Sie können selbst festlegen, dass nur L1–L2 für den Agenten freigegeben sind.

Wie FutrixData auf dem Agenten-Ergebnispfad maskiert

Die Maskierung wird pro Wert deterministisch berechnet:

Den rohen Feldwert in einen String konvertieren.
Aus einem lokalen Secret im OS-Secret-Store einen HMAC-Schlüssel pro (Datenquelle, Feld) ableiten. Das lokale Secret wird beim ersten Start erzeugt, bleibt auf dem Host und verlässt ihn nie; derselbe Rohwert in einer anderen Datenquelle oder einem anderen Feld ergibt einen anderen Hash.
Mit diesem abgeleiteten Schlüssel HMAC-SHA256 über den Rohwert berechnen.
Die ersten 16 Hex-Zeichen nehmen.
masked:v1: voranstellen und den maskierten Wert an den Agenten zurückgeben.

Derselbe Eingabewert ergibt innerhalb einer Installation immer denselben Schlüssel, sodass Agenten weiterhin joinen, gruppieren, COUNT DISTINCT ausführen und über Gleichheit räsonieren können — ohne je den Rohwert zu sehen. Die Abbildung ist ohne das lokale Secret einseitig. Deterministische Maskierung reduziert die Leak-Fläche — sie ist keine vollständige Anonymisierung. Siehe Maskierungs-Limitations zur Umkehrung.

Zwei Klassifikationswege

FutrixData unterstützt zwei Wege, Sensitivitätsstufen zuzuweisen — beide schreiben in denselben Klassifikations-Store.

Externe Agenten-Klassifikation. Claude Code, Cursor oder ein beliebiger MCP-/Skill-Client liest das Schema, klassifiziert Felder und schreibt den Bericht per Tool-Call zurück. Es werden keine Zeilendaten gesendet — nur Spaltennamen und Typen.
Eingebauter AI-Scan zur Klassifikation. Die Desktop-App liest das Schema, sendet Spaltennamen + Typen (niemals Zeilenwerte) an Ihr konfiguriertes, individuell wählbares Modell und legt das Ergebnis zur menschlichen Zweitprüfung vor. Manuelle Korrekturen und externe Agenten-Schreibvorgänge bleiben über Re-Scans hinweg erhalten.

Compliance-Sicht

DSGVO Art. 5 Abs. 1 lit. c verlangt Datenminimierung — nur das verarbeiten, was nötig ist. Der Europäische Datenschutzausschuss hat klargestellt, dass pseudonymisierte Daten personenbezogene Daten bleiben, solange sie über Zusatzinformationen rückverknüpfbar sind. PII-Maskierung „löst Compliance“ nicht in Luft auf; sie reduziert die Leak-Fläche und macht den Datenausgang besser auditier- und steuerbar. Das Audit-Log protokolliert, welche Spalten bei jeder Query maskiert wurden — das gibt dem Security-Team etwas Konkretes, dem es attestieren kann.

Beispiele

Zeile vor und nach Maskierung

// Raw row from PostgreSQL
{ "id": 1042, "email": "alice@example.com", "phone": "+14155550123", "status": "active" }

// Row delivered to the agent (default L1–L3 access)
{ "id": 1042, "email": "masked:v1:8f3a1c9b72e04d11", "phone": "masked:v1:b219ac74e1d908f2", "status": "active" }

Schema-only-Sensitivitätsklassifikationsanfrage (keine Zeilendaten verlassen den Host)

{
  "data_source": "prod-postgres",
  "table": "users",
  "fields": [
    { "name": "id",       "type": "bigint" },
    { "name": "email",    "type": "varchar(254)" },
    { "name": "phone",    "type": "varchar(20)" },
    { "name": "status",   "type": "varchar(16)" }
  ]
}

Häufig gestellte Fragen

Welche Felder werden standardmäßig maskiert?

L4 (email, phone, salary, date_of_birth usw.) und L5 (password, credit_card, api_secret, home_address) werden vor dem Agenten maskiert. L1–L3 werden im Klartext zurückgegeben. Der zugängliche Bereich ist pro Agent editierbar.

Sind maskierte Werte umkehrbar?

Nicht ohne den lokalen Schlüssel. Maskierung ist ein secret-basierter deterministischer HMAC-SHA256; der HMAC-Schlüssel wird pro (Datenquelle, Feld) aus einem im OS-Secret-Store abgelegten lokalen Secret abgeleitet und verlässt den Host nie. Derselbe Eingabewert ergibt innerhalb einer Installation denselben Hash-Wert — die Umkehrung eines Hash-Werts erfordert den lokalen Schlüssel; zudem nutzt FutrixData nur die ersten 16 Hex-Zeichen des Hashs, womit die Kollisionswahrscheinlichkeit extrem gering und eine praktische Umkehrung ausgeschlossen ist. Wichtiger Vorbehalt: Eingaberäume mit niedriger Kardinalität (Booleans, Geschlecht, Alter in Jahren, kleine Enums) bleiben anfällig für Enumeration — wer bekannte Eingaben durch das Gateway schicken kann oder das lokale Secret hält, kann für solche Felder eine Lookup-Tabelle bauen. Der Console-Pfad (autorisierter Mensch) liefert standardmäßig Rohzeilen; nur der Agenten-Ergebnispfad ist maskiert. Siehe Limitations — deterministische Maskierung reduziert die Leak-Fläche, sie anonymisiert keinen Datensatz für die Veröffentlichung.

Bricht Maskierung Joins und Aggregationen?

Nein. Derselbe Input ergibt denselben maskierten Output — Joins, GROUP BY, COUNT DISTINCT und Gleichheits-Prädikate funktionieren weiterhin auf maskierten Spalten. Sortierung und Teilstring-Operationen auf maskierten Feldern entfallen — die sollten innerhalb des Proxys laufen, nicht im Agenten.

Kann ich Sensitivitätsstufen anpassen?

Ja. Stufen-Namen, Beschreibungen, Beispielfelder und der für Agenten zugängliche Bereich sind editierbar. Sie können auch Overrides pro Quelle oder pro Tabelle ergänzen — z. B. orders.notes in der Produktion als L4 und in der Staging-Kopie als L1 klassifizieren.

Sind gehashte Daten unter der DSGVO weiterhin personenbezogene Daten?

Im Allgemeinen ja. Der Europäische Datenschutzausschuss behandelt pseudonymisierte Daten als personenbezogene Daten, solange sie über Zusatzinformationen rückverknüpft werden können. Maskierung ist eine Reduktion der Leak-Fläche, kein magischer Compliance-Schalter — aber eine vertretbare technische Maßnahme nach DSGVO Art. 32.

Wie hoch ist der Performance-Overhead?

Maskierung pro Zeile bedeutet einen secret-basierten HMAC pro sensiblem Feld — sub-Millisekunde bei typischen Zeilengrößen. Die dominierenden Kosten der meisten Queries sind die Datenbank selbst und der LLM-Round-Trip, nicht der Maskierungsschritt.

Sendet FutrixData Schema-Metadaten an LLM-Anbieter?

Es kann — auf den Pfaden AI-Chat, Schema-Knowledge und Tabellenbeziehungs-Hilfe — und das ist ein separater Pfad von den Query-Result-Zeilen. Schema-Metadaten können Tabellennamen, Spaltennamen, Typen, Indizes und Kommentare enthalten. Die Result-Maskierung deckt Schema-Metadaten nicht automatisch ab, weil das Schema die Struktur ist, die die KI verstehen soll, nicht die Daten selbst. Die Desktop-App bietet pro Datenquelle einen Schalter für die Schema-an-LLM-Übermittlung, und jede Übermittlung wird protokolliert, sodass Sie sie auditieren können. Wenn Ihr Schema selbst Geschäftsgeheimnisse kodiert (KYC-Tabellen, regulatorische Codes, interne Produktnamen), deaktivieren Sie den Schalter für diese Datenquelle. Siehe Trust für die vollständige Datenpfad-Karte.

Gilt die Maskierung auch für die Desktop-Console?

Nein — by design. Die Console ist der Abfragepfad für autorisierte Menschen. Die Person an der Tastatur ist der Inspektor. Maskierung gilt auf dem Agenten-Ergebnispfad (MCP, Skill, Agenten-CLI). Wenn ein bestimmter Nutzer keine Rohwerte sehen soll, steuern Sie den Zugriff an der Datenquelle selbst — nicht an der Console.

Probieren Sie FutrixData mit Ihrer eigenen Datenbank aus

Kostenlose Desktop-App für macOS, Windows und Linux. Self-hosted Enterprise Edition für produktive Deployments.

Desktop-App herunterladen Zur Dokumentation