Was Cursor in den KI-Kontext lädt
Cursor lädt JSON- und YAML-Konfigurationsdateien standardmäßig in den KI-Kontext. Diese Dateien enthalten oft Cloud-Token, Datenbankpasswörter und Deployment-Einstellungen.
Das Risiko liegt nicht in unachtsamer Nutzung. Es liegt in der Standardkonfiguration. Jede KI-gestützte Coding-Sitzung mit Konfigurationsdateien kann diese Dateien an Anthropic- oder OpenAI-Server senden.
Die Absicht des Entwicklers ist legitim. Er bittet die KI, eine Datenbankabfrage zu optimieren. Die Abfrage enthält einen Connection-String. Die KI sieht ihn. Das ist das Leck. Es ist ein Nebeneffekt normaler Arbeit. Richtlinien allein können das nicht zuverlässig verhindern.
Deshalb stieg die Nutzung von Model Context Protocol-Werkzeugen in Q4 2025 um 340% in Unternehmensumgebungen. Teams brauchen eine technische Lösung. Ein neues Richtliniendokument reicht nicht aus.
Die 12-Millionen-Dollar-Folge
Ein Finanzdienstleister verlor die Kontrolle über proprietäre Handelsalgorithmen. Die Algorithmen gelangten während einer Code-Review-Sitzung auf die Server eines KI-Assistenten.
Die geschätzten Kosten: 12 Mio. USD (IBM Cost of Data Breach 2025, Unternehmen mit >10.000 Mitarbeitern). Das Unternehmen konnte die Daten nicht rückgängig machen. Es musste jeden übertragenen Datensatz prüfen. Es engagierte Rechtsanwälte für das Geschäftsgeheimnis-Risiko. Es führte eine Schadensbewertung durch.
Das ist der schlimmste Fall. Der Normalfall ist kleiner, summiert sich aber schnell. API-Schlüssel werden rotiert, nachdem sie in KI-Chat-Protokollen auftauchen. Datenbankpasswörter werden gewechselt, nachdem sie in Tool-Verläufen erscheinen. OAuth-Token werden widerrufen, nachdem Bildschirmaufnahmen sie erfassen. Jeder Schritt kostet Mitarbeiterzeit. Die Kosten sind real und werden selten erfasst.
Wie die Anonymisierungsschicht funktioniert
Model Context Protocol (MCP) fügt eine Schicht zwischen dem KI-Client und der KI-Modell-API ein. Jede Anfrage durchläuft eine Anonymisierungs-Engine, bevor sie das Modell erreicht.
Ohne Schutz: Ein Entwickler schreibt ein Migrationsskript. Es enthält einen Connection-String: postgres://admin:password@host:5432/db. Das KI-Modell erhält diesen String unverändert.
Mit der Anonymisierungsschicht: Die Engine erkennt den String. Sie ersetzt ihn durch ein Token — [DB_CONN_1]. Das Modell sieht die Struktur und Logik des Skripts. Die Zugangsdaten bleiben lokal.
Die reversible Verschlüsselungsoption geht weiter. Kunden-IDs und Produktcodes werden verschlüsselt und durch deterministische Token ersetzt. Die KI gibt eine Antwort mit diesen Token zurück. Der Server entschlüsselt die Antwort und tauscht die Token gegen echte Werte. Der Entwickler liest tatsächliche Bezeichner. Das KI-Modell hat sie nie gesehen.
Einrichtung und Entwicklererfahrung
Für Entwicklungsteams ist die Einrichtung eine einmalige Aufgabe. Cursor und Claude Code werden so konfiguriert, dass sie über einen lokalen Proxy-Server weitergeleitet werden. Die Serverkonfiguration legt fest, welche Entitätstypen abgefangen werden:
- API-Schlüssel
- Datenbank-Connection-Strings
- Auth-Token
- AWS-, Azure- und GCP-Anmeldedaten
- Private-Key-Header
Teams können eigene Muster für interne Dienstnamen oder proprietäre Bezeichner hinzufügen.
Aus Entwicklersicht ändert sich nichts. Autovervollständigung, Code-Review, Debugging-Hilfe und Dokumentationsgenerierung funktionieren wie zuvor. Der Proxy läuft still im Hintergrund.
Die Analyse von Checkpoint Research aus dem Jahr 2025 identifizierte die Offenlegung von Entwickleranmeldedaten als das risikoreichste Problem bei KI-Coding-Tools. Das ist genau das Problem, das diese Architektur löst. Es ist eine technische Lösung, kein Richtlinien-Hinweis.
Mehr dazu in unserem Sicherheitsüberblick und in der Compliance-Dokumentation. Weitere Informationen zu abgefangenen Datentypen finden Sie in unserem Entitäts-Erkennungshandbuch.