Warum Netzwerk-DLP an ChatGPT scheitert
Klassische Proxy- und Gateway-DLPs können verschlüsselten Browser-Traffic zu ChatGPT, Claude oder Gemini nicht lesen. Hier ist warum — und was wirklich funktioniert.
Der blinde Fleck, den Ihr DLP-Anbieter nicht bewirbt
Öffnen Sie Ihr SIEM und suchen Sie nach DLP-Vorfällen auf chatgpt.com, claude.ai oder gemini.google.com in den letzten dreißig Tagen. In den meisten Organisationen steht der Zähler bei null. Nicht, weil niemand sensible Daten eingefügt hätte — die Nutzungstelemetrie zeigt, dass eine durchschnittliche Wissensarbeiterin ChatGPT 22 Mal pro Woche aufruft — sondern weil der DLP-Stack physisch nicht in die Sitzung hineinsehen kann. Der TLS-Handshake schließt ab, die Streaming-Antwort kommt an, und der Proxy zählt Bytes, die er nicht parsen kann.
Das ist kein Tuning-Problem. Es ist ein Architektur-Problem. Jede DLP-Kategorie vor 2023 — Symantec, Forcepoint, Microsoft Purview auf Netzwerkebene eingesetzt, Netskope CASB, Zscaler — wurde für ein Web entworfen, das es nicht mehr gibt. Gehen wir Punkt für Punkt durch, warum, und was die Alternativen produktiv tatsächlich liefern.
TLS 1.3, Certificate Pinning und das Ende von MITM
Klassisches Gateway-DLP terminiert TLS in der Mitte. Die Unternehmens-CA wird auf jedes verwaltete Endgerät verteilt, der Proxy zeigt ein gefälschtes Zertifikat für chatgpt.com, der Browser vertraut, weil die Root installiert ist, und der Proxy liest den Klartext. Das hat ein Jahrzehnt funktioniert. Es ist strukturell aus drei Gründen kaputt.
Erstens versteckt TLS 1.3 mit 0-RTT-Wiederaufnahme große Teile des Handshakes — einschließlich SNI in vielen Konfigurationen — hinter Early Data. Zweitens bringen moderne Browser eine fest verdrahtete Liste von Certificate Pins für hochwertige Domains mit, und Chromium erzwingt zunehmend Certificate Transparency mit SCT-Validierung. Ein Proxy, der sein eigenes Zertifikat einschleust, löst auf diesen Domains einen harten Fehler aus, keine wegklickbare Warnung. Drittens rollt Encrypted Client Hello (ECH) gerade über alle Cloudflare-fronted Dienste aus. Sobald ECH verpflichtend ist, sieht der Proxy nicht einmal mehr, welcher Hostname kontaktiert wird, geschweige denn den Body.
Die OpenAI-Desktop-App und die Anthropic-Konsole pinnen ihre First-Party-API-Aufrufe explizit. Ein MITM-Versuch inspiziert nicht leise — er bricht die Verbindung. Sicherheitsteams, die das brutal erzwingen, enden mit einer Welle an Helpdesk-Tickets und null Sichtbarkeit.
WebSocket-Framing tötet die Payload-Inspektion, selbst wenn MITM klappt
Nehmen wir kurz an, Sie schaffen es, TLS auf Ihrem eigenen Proxy zu terminieren. Sie können die Unterhaltung trotzdem nicht lesen. ChatGPT und Claude senden keine Anfrage und erhalten eine JSON-Antwort. Sie öffnen einen persistenten WebSocket (oder einen Server-Sent-Events-Stream) auf demselben TLS-Kanal und tauschen binäre Frames aus, die sowohl den User-Prompt als auch die Streaming-Completion Token für Token transportieren.
Die meisten Proxy-DLP-Engines parsen WebSocket-Frames überhaupt nicht. Die, die es tun, machen Pattern-Matching auf opakem Framing, ohne das Konversationsprotokoll zu verstehen — sie sehen einen Byte-Klumpen, verpassen die Prompt-Grenze, und lassen entweder alles durch oder blockieren alles. Dasselbe gilt für Geminis gRPC-Web-Transport. Streaming ist die Standard-UX moderner KI, und Streaming ist genau das, wofür Gateway-DLP nie gebaut wurde.
Die Falle „dann sperren wir halt die Domain"
Die erste Reaktion eines überlasteten Security-Teams ist die Firewall-Regel: chat.openai.com am Egress blocken. Das ist das Cyber-Äquivalent, die Haustür abzuschließen und alle Fenster offen zu lassen. Drei Dinge passieren innerhalb einer Woche.
- Mitarbeitende wechseln auf mobil. Aus 22 Prompts pro Woche werden 22 Prompts pro Woche auf einem privaten Telefon, außerhalb des Netzes, ohne jedes Log.
- Shadow AI explodiert. Leute legen private Accounts mit privaten E-Mails an und nutzen KI-Tools, von denen das Security-Team nie gehört hat — DeepSeek, Poe, You.com, Mistrals Le Chat, ein Dutzend ChatGPT-Wrapper.
- Der Business verlangt eine Ausnahme. Marketing, Recht, Engineering argumentieren — zu Recht —, dass sie das Tool brauchen. Die IT erteilt Ausnahmen pro Nutzerin, und die Policy kollabiert.
Domain-Sperren erzeugen die Illusion von Kontrolle und machen den tatsächlichen Abfluss schwerer sichtbar. Der BfDI, die CNIL und das ICO haben in Leitlinien betont, dass nicht überwachte Nutzung compliance-rechtlich schlechter ist als überwachte Nutzung, selbst wenn diese technisch eine Grenze überschreitet.
CASB: besser, mit einem Loch in Form von „jedem neuen KI-Tool"
CASB-Plattformen (Netskope, Zscaler, Microsoft Defender for Cloud Apps) haben die Lage verbessert, indem sie cloud-nativ wurden. Sie haben API-Integrationen mit freigegebenen SaaS-Diensten, können Richtlinien auf OpenAI-Enterprise-Tenants anwenden und verstehen mehr vom modernen Handshake als Legacy-Boxen. Für ChatGPT Enterprise und Microsoft Copilot für M365 leistet ein CASB echte Arbeit.
Das Loch ist die Long Tail. CASB setzt voraus, dass der Anbieter einen Connector für genau dieses Tool geschrieben hat. Es gibt keinen Netskope-Connector für Mistrals Le Chat im Free-Tier, keine Zscaler-Richtlinie für eine selbstgehostete Ollama-Instanz auf einem Entwicklerlaptop, keine Defender-Sichtbarkeit auf die siebzehn ChatGPT-Browser-Erweiterungen, die ein Mitarbeiter installiert hat. CASB-Anbieter nennen das „Universal Mode" oder „Any-App-Coverage", und es heißt fast immer Traffic-Pattern-Heuristik, nicht Content-Inspektion. Sie sehen, dass etwas an etwas KI-Ähnliches ging; was im Prompt stand, sehen Sie nicht.
Plus Latenz. CASB Inline routet jede Browser-Session über einen Anbieter-PoP. Für eine Berliner Nutzerin, die Claude auf us-east-1 anspricht, ist das eine messbare Strafe auf einer Streaming-Token-Antwort, die ohnehin latenzempfindlich ist. Die Nutzerinnen merken es. Die Nutzerinnen finden Workarounds.
Browser-Isolation: funktioniert — und kaum jemand nutzt sie zweimal
Cloudflare Browser Isolation, Forcepoint RBI und Menlo lösen das Inspektionsproblem, indem sie den Browser selbst in die Cloud verlagern. Der lokale Bildschirm erhält nur Pixel; Copy-Paste und Datei-Upload werden auf der Isolationsebene abgefangen. Aus reiner DLP-Sicht ist das die stärkste Gateway-Option.
Die Kosten spüren die Nutzerinnen sofort. Copy-Paste-Latenz, kaputtes Markdown-Rendering, gelegentliche WebSocket-Abbrüche bei langen Claude-Completions, Google-SSO-Schleifen, Bildgenerierung, die als flacher Screenshot statt als echte Datei heruntergeladen wird. Adoptionsumfragen zeigen konsistent, dass Isolations-Deployments innerhalb von sechs Monaten kollabieren, wenn das Security-Team nicht akzeptiert, dass 30 bis 50 % der Nutzerinnen einen Workaround finden werden. Die Ökonomie ist brutal: Per-Seat-Preise für RBI liegen typischerweise 4 bis 8 Mal über einem Client-Side-Ansatz.
Browser-Isolation ist die technisch richtige Antwort auf eine Frage, die niemand außerhalb der Sicherheit stellen will. Sie funktioniert im Labor und stirbt im Organigramm.
Der Client-Side-Ansatz: im Browser sitzen, nicht davor
Die einzige Architektur, die TLS 1.3, ECH, WebSocket-Framing, Mobile-Fallback und Shadow AI überlebt, läuft zwischen Nutzerin und Verschlüsselungsschicht: im Browser selbst als Erweiterung, und auf dem Desktop als nativer Agent für Apps, die den Browser umgehen. Das ist der Zeuslock-Ansatz.
Durch Hooks ins DOM und in die WebSocket-API des Browsers wird der Prompt inspiziert, bevor TLS ihn umhüllt. Die dreischichtige Detection-Pipeline — lokale Regex für schnelle offensichtliche Treffer, ein feingetuntes NER-Modell, anschließend Kontext-Heuristik — läuft client-seitig in Millisekunden, mit optionaler Bestätigung über eine in der EU gehostete ML-API. Kein Zertifikat zu installieren. Kein Traffic umzuleiten. Keine Latenz im Antwort-Stream. Die Nutzerin sieht eine Inline-Warnung, eine automatische Anonymisierung (ein echter AWS-AKIA-Schlüssel ersetzt durch eine strukturell gültige Attrappe) oder einen harten Block, je nach Policy-Modus.
Dieselbe Engine erstreckt sich über die Zeuslock-CLI und den Desktop-Agent auf Claude Code, Cursor, Copilot CLI und Aider. MCP-Traffic zwischen Agents und Tools wird an der Protokoll-Grenze inspiziert. Universal Mode deckt Tools ab, von denen das Team nie gehört hat, weil die Detection am Prompt-Inhalt ansetzt, nicht an einer Anbieter-Whitelist.
Ehrlicher Vergleich
| Ansatz | Sieht Prompt-Inhalt | Deckt Shadow AI ab | UX-Impact | Kostenform |
|---|---|---|---|---|
| Legacy Proxy- / Gateway-DLP | Nein (TLS 1.3, Pinning, ECH) | Nein | Niedrig — bis das Pinning bricht, dann hoch | Bereits bezahlt, kein inkrementeller Wert |
| Domain-Blocking | Nein | Nein — verlagert auf mobil | Hoch; Nutzerinnen umgehen | Kostenlos; negativer ROI |
| CASB Inline | Teilweise, nur benannte Apps | Nein (Long Tail) | Mittel (Latenz) | Pro Seat, mittel |
| Browser-Isolation | Ja | Teilweise | Hoch (Copy-Paste, Latenz) | Pro Seat, hoch |
| Client-Side-DLP (Zeuslock) | Ja, vor der Verschlüsselung | Ja, inkl. Universal Mode | Unsichtbar bis zu einem Treffer | Pro Seat, niedrig bis mittel |
Was Sie dieses Quartal tun sollten
- Ziehen Sie einen 30-Tage-Bericht aus Ihrem bestehenden DLP, gefiltert auf chatgpt.com, claude.ai, gemini.google.com und copilot.microsoft.com. Wenn die Vorfallszahl verdächtig niedrig ist, haben Sie den blinden Fleck.
- Messen Sie die tatsächliche Nutzung mit einem zweiwöchigen Browser-seitigen Telemetrie-Piloten. Rechnen Sie mit 5 bis 10 Mal mehr KI-Traffic, als Ihr Gateway sieht.
- Rollen Sie eine Client-Side-Erweiterung in den Wochen 1-2 im Monitor-Modus aus, in den Wochen 3-5 im Anonymize-Modus, ab Woche 6 im Block-Modus für die kritischsten Findings-Typen. Die Stufenfolge steht im Leitfaden zur Policy-Konfiguration.
- Deaktivieren Sie die Proxy-Regeln, die auf KI-Domains zielen. Sie geben Ihnen falsche Sicherheit.
Wenn Ihr DLP gestern die 22 ChatGPT-Prompts Ihres Teams nicht gesehen hat, wird es morgen den AWS-Schlüssel nicht sehen, den jemand einfügt.
Protect your data from AI leaks
Try Zeuslock free — DLP for ChatGPT, Claude, Gemini and more.
Book a demo →