Zwei Kanäle, zwei Angriffsflächen
Entwickler nutzen KI an zwei Orten. Jeder Ort hat einen anderen Datenfluss. Jeder braucht eine andere Sicherheitsmaßnahme.
IDE-integrierte KI — Cursor, GitHub Copilot, VS Code-Erweiterungen und Claude Desktop können Ihr Projekt lesen. Code-Dateien, Konfigurationsdateien und Umgebungsvariablen sind alle zugänglich. Das KI-Modell bekommt das, was der Entwickler einfügt, oder was der Client aus dem Projektkontext zieht.
Browser-basierte KI — Claude.ai, ChatGPT und Gemini laufen im Browser. Entwickler fügen Code, Stack Traces und Fehlermeldungen über Browser-Textfelder ein. Der Text geht direkt zum KI-Anbieter. Kein Filter liegt dazwischen.
Beide Kanäle geben sensible Daten an KI-Anbieter weiter. Beide brauchen Kontrollen. Aber die richtige Kontrolle ist für jeden Kanal anders. Ein Team, das nur einen Kanal abdeckt, hat nur die Hälfte des Entwickler-Workflows geschützt.
Die IDE-Schicht: MCP Server
Für Claude Desktop- und Cursor-Nutzer ist das Model Context Protocol (MCP) die richtige Sicherheitsschicht.
MCP sitzt zwischen KI-Clients und KI-Modell-APIs. Der MCP Server liest alle Daten in dieser Schnittstelle, bevor sie das Modell erreichen.
Diese Position ermöglicht drei Dinge:
Entfernung von Schlüsseln und Geheimnissen — API-Schlüssel, Datenbank-Strings, Auth-Token und interne URLs werden gefunden und durch sichere Tokens ersetzt, bevor sie gesendet werden. Das Modell bekommt [API_KEY_1] statt dem echten Schlüsselwert.
Eigene Code-Muster — Teams können eigene Erkennungsregeln für interne Produktcodes, Kunden-IDs und Dienstnamen hinzufügen. Standard-PII-Tools kennen diese Muster nicht. Eigene Regeln laufen im MCP Server, bevor Daten das Unternehmen verlassen.
Kein Eingriff in die Entwicklerarbeit — Der Entwickler nutzt Cursor oder Claude Desktop genau wie vorher. Der MCP Server läuft zwischen Client und API. Der Entwickler sieht keine Änderung. Er bekommt dieselbe KI-Hilfe.
Der GitHub Octoverse 2024 verzeichnete 39 Millionen geleakte Secrets auf GitHub — ein Anstieg von 25 % im Jahresvergleich. Dieselbe Gewohnheit, die diese Leaks verursacht, treibt auch IDE-KI-Leaks an. Credentials landen in committed Code. Sie landen auch in eingefügtem Kontext. MCP Server-Interception deckt den KI-Kanal dieses Musters ab.
Siehe auch: MCP Server PII-Sicherheit 2026
Die Browser-Schicht: Chrome Extension
Für browser-basierte KI — Claude.ai, ChatGPT, Gemini — ist eine Chrome Extension die richtige Kontrolle.
Die Extension läuft als Content-Script auf jeder KI-Plattform. Sie liest Text, bevor der Entwickler ihn abschickt. Sie findet sensible Inhalte — Namen, Secrets und Code-Muster, die Sie festlegen — und maskiert sie, bevor der Text den KI-Anbieter erreicht.
Die zwei Schichten decken unterschiedliche Kanäle ab:
MCP Server deckt ab — alle KI-Nutzung über Claude Desktop oder Cursor. Code-Reviews, Debug-Sessions und Projektkontext-Abfragen laufen alle durch diese Schicht.
Chrome Extension deckt ab — alle browser-basierte KI-Nutzung. Claude.ai, ChatGPT, Gemini, Perplexity und jede andere KI-Oberfläche im Browser. Das gilt auch für Entwickler, die Browser-KI für Dokumentationsarbeit oder Fragen nutzen, die sie lieber nicht durch die IDE leiten.
Siehe auch: Blockieren vs. Anonymisierung für Browser-DLP
Wie kombinierte Abdeckung aussieht
Ein Entwicklungsteam, das beide Schichten betreibt, erreicht vollständige Abdeckung. So sieht es in der Praxis aus.
Ein Entwickler nutzt Cursor mit Claude, um ein Live-Problem zu debuggen. Der MCP Server entfernt Secrets aus dem Stack Trace, bevor Claude ihn sieht. Keine Schlüssel werden gesendet.
Derselbe Entwickler öffnet dann Claude.ai im Browser für eine Architekturfrage. Er fügt eine interne Service-URL ein. Die Chrome Extension entfernt die URL, bevor sie gesendet wird. Keine interne URL erreicht Claude.
Ein Kollege nutzt ChatGPT für Dokumentationshilfe. Er fügt Code ein, der einen API-Schlüssel enthält. Die Chrome Extension fängt den Schlüssel ab, bevor er zu OpenAI geht. Kein Schlüssel wird exponiert.
Kein Kanal gibt Secrets oder sensiblen Code an KI-Anbieter weiter. Beide Entwickler nutzen KI für echte Arbeit. Das Sicherheitsteam hat technische Kontrollen auf beiden Kanälen — nicht nur Richtlinien.
CVE-2024-59944 zeigt einen Fall des breiteren Musters. Entwickler-KI-Tools ohne Interception-Schichten sind ein Leak-Kanal. Das Zwei-Schichten-Modell ist die direkte Antwort auf dieses Risiko.
Siehe auch: KI-Coding-Assistent PII-Leaks in der Produktion
Warum eine Schicht nicht ausreicht
Manche Teams blockieren Browser-KI und verlassen sich nur auf IDE-Tools. Andere erlauben Browser-KI, decken aber die IDE nicht ab. Beide Ansätze hinterlassen eine Lücke.
Ein Entwickler, der Cursor bei der Arbeit nutzt, öffnet vielleicht auch ChatGPT in einem Browser-Tab für eine schnelle Frage. Eine reine IDE-Kontrolle fängt das nicht ab. Eine reine Browser-Kontrolle fängt die IDE-Session nicht ab. Beide Kanäle sind in einem echten Entwicklertag aktiv.
Das Zwei-Schichten-Modell deckt beide ab. Es verlässt sich nicht darauf, dass Entwickler einen Kanal meiden. Es läuft still in beiden Bereichen.
anonym.legal bietet beide Schichten: einen MCP Server für IDE-integrierte KI und eine Chrome Extension für browser-basierte KI. Beide nutzen dieselbe Erkennungs-Engine — 285+ Entitätstypen, 48 Sprachen, reversible Verschlüsselung.