Die meisten autonomen Agenten in der Produktion leiten heute PII im Klartext direkt an MCP-Tool-Server Dritter weiter — Namen, E-Mail-Adressen, Sozialversicherungsnummern, Zahlungsdaten — ganz ohne Tokenisierung und ohne Audit-Trail. Die Lösung ist kein Richtlinien-Memo. Es ist eine Interceptions-Schicht, die zwischen dem Agenten und jedem externen Tool sitzt, die Daten tokenisiert, bevor sie Ihren Perimeter verlassen, und jede Berührung in einem unveränderlichen Ledger protokolliert. So handhabt VeriSwarm Guard das.
PII-Schutz für KI-Agenten ist die Praxis, zu verhindern, dass personenbezogene Daten über den Datenpfad austreten, den ein Agent durchläuft — Prompt-Eingabe, LLM-Kontext, MCP-Tool-Aufrufe, Drittanbieterdienste und ausgehende Antworten —, während Tools weiterhin sinnvolle Arbeit mit den Daten leisten können. Es ist eine Obermenge der LLM-Eingaberedaktion: Der Leck-Punkt, der in der Produktion am meisten schadet, ist nicht das LLM, sondern der Tool-Aufruf, nachdem das LLM entschieden hat, ihn auszuführen.
Ein typischer Agenten-Workflow: Ein Nutzer gibt seinen Namen, seine E-Mail-Adresse, Telefonnummer und eine Kreditkarte an. Das LLM verarbeitet sie. Der Agent ruft dann ein Tool auf — eine Kalender-API, ein CRM, einen Zahlungsdienstleister — und leitet diese Daten im Klartext über MCP weiter. Die MCP-Spezifikation trägt von sich aus keinen Nutzerkontext; der Tool-Server kann Nutzer nicht unterscheiden oder nutzerspezifische Kontrollen durchsetzen. Jede Datenkategorie — PII, Anmeldedaten, Finanzdaten — kann standardmäßig in einem einzigen Workflow mit Maschinengeschwindigkeit nach außen weitergeleitet werden.
Die Schritt-für-Schritt-Mechanik zum Schließen dieser Lücke finden Sie unter wie man ein Datenleck bei einem KI-Agenten verhindert.
Die Zahlen für 2026 sind wenig schmeichelhaft:
Data Loss Prevention wurde für eine Welt entwickelt, in der Menschen Dateien kopierten und E-Mails versendeten. Tool-Aufrufe von Agenten brechen jede Annahme, auf der DLP beruht:
Ein Agent kann Hunderte von Tool-Aufrufen pro Minute ausführen. Herkömmliche DLP-Prüfung kann damit nicht Schritt halten, ohne zu einem Flaschenhals zu werden, der den Zweck der Automatisierung zunichtemacht.
DLP-Richtlinien klassifizieren Daten im Ruhezustand oder bei der Übertragung über bekannte Kanäle. MCP-Tool-Aufrufe sind dynamisch, programmatisch und laufen über Endpunkte, von denen das Sicherheitsteam möglicherweise nichts weiß.
Mustererkennung erfasst bekannte Formate (Kartennummern, Sozialversicherungsnummern), übersieht aber kontextabhängige PII wie Krankheitsbilder oder Kennungen, die auf mehrere Tokens verteilt sind. Genau da braucht man NER auf strukturierten Daten.
Die Architektur, die funktioniert, ist eine Laufzeit-Interceptions-Schicht zwischen dem Agenten und seinen Tools. Guard Proxy sitzt an dieser Stelle. Presidio (Microsofts Open-Source-NER-Engine) erkennt und tokenisiert PII-Kategorien — Namen, E-Mail-Adressen, Telefonnummern, Sozialversicherungsnummern, Kreditkarten, IP-Adressen sowie finanzielle oder behördliche Ausweisnummern (Bankkonten, Führerscheine, Reisepässe) —, bevor der Tool-Aufruf den Perimeter verlässt. Der Tool-Server sieht [PERSON_1] statt „Jane Smith“. Das LLM denkt über den Token nach. Der Originalwert wird erst in der finalen Antwort an den autorisierten Nutzer wiederhergestellt. Es ist kein nachträgliches Scannen; es ist eine Inline-Transformation.
Die Transformer-Pipeline führt vier eingebaute Transformer in fester Reihenfolge aus — zuerst PII-Tokenisierung, dann Kontext-Injektion, Feldmaskierung und Schemavalidierung. Die vollständige Aufschlüsselung, was jeder davon tut, was ihn auslöst und wie man eigene Transformer hinzufügt, finden Sie unter Die vier Guard-Proxy-Transformer: Was jeder Einzelne abfängt, in Reihenfolge.
Drei Bereitstellungsmodi (cloudgehostet, On-Prem-Docker, lokales stdio) decken die gesamte Bandbreite ab, von „richten Sie Ihren Agenten auf eine URL“ bis „Daten verlassen niemals Ihre VPC“.
Tokenisierung ist Pseudonymisierung, keine Anonymisierung. Nach Artikel 4(5) der DSGVO bleiben pseudonymisierte Daten personenbezogene Daten — der Token plus die Zuordnungstabelle können die Person weiterhin re-identifizieren, und mehrere tokenisierte Felder können kombiniert werden, um die Identität selbst ohne die Zuordnungstabelle offenzulegen. Das bedeutet, dass eine von Guard tokenisierte Payload weiterhin in den Anwendungsbereich der DSGVO fällt; sie verschiebt lediglich die erforderlichen Kontrollen.
In der Praxis reduziert die Tokenisierung den Explosionsradius einer Offenlegung und demonstriert die nach Artikel 32 geforderten Kontrollen nach dem „Stand der Technik“ — aber sie beseitigt weder die Betroffenenrechte noch die Meldepflichten bei Verstößen noch die Anforderungen an das Verzeichnis von Verarbeitungstätigkeiten. Ein Anbieter, der behauptet, Tokenisierung mache PII „nicht mehr zu personenbezogenen Daten“, irrt sich entweder oder verkauft Ihnen etwas. Wir tun das nicht.
Jede PII-Interception wird im hash-verketteten Ledger von Vault protokolliert — was gesendet wurde, was tokenisiert wurde, was zurückgegeben wurde, wann, von welcher Agentenidentität, gegen welches Tool. Wenn ein Prüfer fragt „Wohin sind die Daten dieses Kunden gegangen?“, lautet die Antwort eine kryptografisch verifizierbare Zeitachse, kein Screenshot eines Überwachungstools. Die Kettenverifizierung erkennt Manipulationen; Exporte entsprechen direkt den Anforderungen an das Verzeichnis von Verarbeitungstätigkeiten nach Artikel 30 der DSGVO.
Das Runbook für den Tag, an dem die Kettenverifizierung fehlschlägt — der Endpunkt, die Antwortform, die Untersuchungsschritte — finden Sie unter Eine Vault-Kette verifizieren: Ein Runbook für den Tag, an dem die Integrität bricht.
Das Gesundheitswesen ist der anspruchsvollste Anwendungsfall für PII-Schutz an der Grenze zwischen Agent und Tool. Die OCR-Durchsetzungsbilanz von 2025 zeigt, dass Risk-Analysis-Feststellungen die Vergleiche im Verhältnis 3:1 dominieren, mit durchschnittlichen Bußgeldern von rund 291.000 $, zuzüglich zweijähriger Überwachungspflichten. Die Tokenisierung von Guard, das Ledger von Vault und die Bewertungsschleife auf Agentenebene ergeben zusammen eine Haltung, die diese Prüfung übersteht — eingebunden in die vertikale Gesundheitswesen-Oberfläche mit standardmäßig aktivierten, HIPAA-konformen Voreinstellungen.
Tokens. Guard Proxy tokenisiert PII an der Interceptions-Grenze — Namen, E-Mail-Adressen, Telefonnummern, Sozialversicherungsnummern, Kreditkarten, IP-Adressen, finanzielle und behördliche Ausweisnummern (Bankkonten, Führerscheine, Reisepässe) —, und das LLM denkt über den Token nach. Tool-Server erhalten den Token. Der Originalwert wird erst in der finalen Antwort an den autorisierten Nutzer wiederhergestellt; nichts nachgelagert sieht Klartext.
Die Zuordnung lebt innerhalb der Guard-Proxy-Bereitstellung des Mandanten und wird niemals zusammen mit der tokenisierten Payload über die Leitung gesendet. Im cloudgehosteten Modus liegt sie hinter mandantenspezifischer Verschlüsselung; im On-Prem-Docker-Modus verlässt sie niemals Ihr Netzwerk. Das Token-Format ist nur mit diesem Schlüssel umkehrbar, sodass ein abgefangener Tool-Aufruf den Token preisgibt, nicht den dahinterliegenden Wert.
Es ist eine der Kontrollen. Tokenisierung an der Tool-Aufruf-Grenze hält PHI aus dem LLM-Kontext, aus MCP-Tool-Servern, die Sie nicht kontrollieren, heraus und bringt sie in das hash-verkettete Ledger von Vault, sodass der Datenfluss-Nachweis eine Prüfung übersteht. Die vollständige HIPAA-Haltung erfordert außerdem BAAs mit nachgelagerten Tool-Servern, signierte Manifeste auf den Agenten selbst (Passport) und Betriebsprozesse rund um die Reaktion auf Verstöße. Die Laufzeit-Tokenisierung schließt die größte technische Lücke; der Rest ist Papierkram und Betrieb.
Redaktion zerstört den Wert (irreversibel) — gut für Telemetrie und Protokolle, nutzlos, wenn das Tool die Daten zum Funktionieren braucht. Maskierung verdeckt teilweise (letzte 4 Ziffern einer Karte) — gut für menschenlesbare Oberflächen. Blockierung unterbindet den Aufruf komplett — richtig bei harten Richtlinienverstößen. Tokenisierung erhält den Nutzen, während das Geheimnis entfernt wird — als einzige der vier kann der Tool-Server weiterhin sinnvolle Arbeit leisten, ohne den Originalwert zu sehen. Guard unterstützt alle vier; die Wahl erfolgt pro Datenkategorie und pro Richtlinie.
Ja — das ist seine primäre Oberfläche. Guard Proxy ist eine transparente MCP-Interceptions-Schicht mit drei Bereitstellungsmodi (cloudgehostet, On-Prem-Docker, lokales stdio). Der MCP-Client Ihres Agenten zeigt auf Guard Proxy anstatt direkt auf den Tool-Server; Guard Proxy leitet den Aufruf ohne die PII weiter und gibt die Antwort zurück. Keine Änderungen am Agentencode.
Ja — dieselbe Tokenisierungsmaschinerie deckt beides ab. Neben personenbezogenen Daten erkennt der Detektor Anmeldedatenformate — GitHub-Tokens, OpenAI-Schlüssel, AWS-Schlüssel, Slack-Tokens, GCP-Schlüssel, Stripe-Schlüssel, JWTs und Private-Key-Blöcke — und tokenisiert sie genauso, wie er einen Namen oder eine Sozialversicherungsnummer tokenisiert. Ein durchgesickerter API-Schlüssel auf dem Weg zu einem Tool-Aufruf wird abgefangen, bevor er Ihren Perimeter verlässt — nicht nur eine durchgesickerte Sozialversicherungsnummer.
Tokens laufen nach einer konfigurierbaren TTL ab — standardmäßig eine Stunde — und sind auf einen bestimmten Mandanten und eine bestimmte Sitzung beschränkt, sodass ein für ein Gespräch geprägter Token nicht in einem anderen wiederverwendet werden kann. Die Originalwerte werden im Ruhezustand verschlüsselt (symmetrische Fernet-Verschlüsselung), und jede Rehydrierung zurück zu Klartext wird für die Prüfung protokolliert. Ein Token, der für sich allein durchsickert, ist ohne den Verschlüsselungsschlüssel und eine aktive, eingegrenzte Sitzung nutzlos.
Sie durchläuft die gesamte Struktur. Der Tokenizer von Guard durchläuft rekursiv jedes Dict und jede Liste in den Argumenten eines Tool-Aufrufs — und im Antwortkörper —, sodass PII, die bei `data.customer.email` oder in einer Liste von Datensätzen verborgen ist, genauso tokenisiert wird wie ein Feld auf oberster Ebene. Eine frühere Version prüfte nur die oberste Ebene, wodurch verschachtelte PII in typischen MCP-Payload-Formen unredigiert durchrutschen konnte; diese Lücke wurde als kritischer Fix geschlossen.
Guard Proxy erfordert keinerlei Änderungen an Ihrem Agentencode. Richten Sie Ihren MCP-Client auf Guard Proxy statt auf den Tool-Server; Guard Proxy leitet den Aufruf ohne die PII weiter und gibt die Antwort zurück. Die kostenlose Stufe von Gate gibt Ihnen zuerst Einblick in das Inventar und den Ereignisfluss — damit Sie das Problem sehen können, bevor Sie die Lösung aktivieren.