Privacy Mode ist eingeschaltet. Was passiert mit deinem Kundencode?
Diese Frage bleibt auch nach dem Klick berechtigt. Du arbeitest in einem lokalen Editor, aber die KI erhält Kontext aus deinem Projekt. Dazu kommen Terminalbefehle, eigene API-Schlüssel und möglicherweise ein Cloud Agent.
Um Cursor datenschutzkonform nutzen zu können, musst du diese Wege auseinanderhalten. Ich zeige dir, welchen Vertrag du prüfen solltest und was Privacy Mode tatsächlich regelt. Danach begrenzt du den Codekontext, prüfst die Agentenrechte und entscheidest über Cloud-Funktionen.
Für eine verbindliche Vorgabe im Team hilft dir außerdem eine KI-Richtlinie fürs Unternehmen.
- Aktiviere Privacy Mode und prüfe den passenden DPA. Die Datenschutzdokumentation unterscheidet Individualpläne und Teamkonten.
- Nutze .cursorignore als Kontextkontrolle. Terminal und MCP können andere Zugriffswege haben. BYOK umgeht das Cursor-Backend nicht.
- Behandle Cloud Agents als eigenen Cloud-Dienst. Repository, Zugänge, Internetzugriff und Aufbewahrung brauchen eine separate Freigabe.
1. Prüfe, welche Inhalte dein Projekt weitergeben darf
Testdaten, Kommentare und Fehlerausgaben können neben dem Quellcode auch personenbezogene Angaben enthalten. Eine Anweisung zur Fehlerbehebung kann genau diese Inhalte in den KI-Kontext bringen.
Ich würde zuerst ein bereinigtes Arbeitsverzeichnis anlegen und echte Kundendatensätze durch erfundene Beispiele ersetzen. Entferne Produktionszugänge und prüfe generierte Logs, um den Datenumfang vor der ersten KI-Anfrage zu verkleinern.
Cursor beschreibt in seiner Datennutzungsübersicht mehrere Verarbeitungswege. Für die Freigabe solltest du sie so auseinanderhalten.
Datenwege bei Cursor. Dokumentationsstand Oktober 2026.
Der lokale Editor beschreibt deinen Arbeitsplatz, während der Vertrag zusätzlich den tatsächlichen Datenempfänger abdecken muss.
2. Wähle den Tarif mit passendem Datenschutzvertrag
Für Kundenprojekte würde ich Konten zentral verwalten, damit klar ist, wer unter welchem Vertrag arbeitet. Ein privates Konto mit eingeschaltetem Privacy Mode beantwortet diese Vertragsfrage noch nicht.
Cursors Privacy-Dokumentation nennt den DPA für Teams und Enterprise. Für Individualpläne gilt er dort ausdrücklich nicht. Prüfe deshalb den tatsächlichen Tarif und die Organisation hinter deinem Login.
Der Cursor-DPA regelt die Auftragsverarbeitung einschließlich Unterauftragsverarbeitern und internationalen Übermittlungen. Er ersetzt nicht die Prüfung deines eigenen Verwendungszwecks.
Anhang 1 des veröffentlichten DPA untersagt Kunden und ihrem Personal unter dem jeweiligen Agreement die Bereitstellung sensibler Daten und besonderer Kategorien personenbezogener Daten. Für die Verarbeitung dennoch bereitgestellter sensibler Daten erklärt die Klausel den Anbieter für nicht haftbar. Privacy Mode ändert diesen Vertragsumfang nicht.
In der Freigabe hältst du fest, welche Daten der Dienst erhalten darf.
Arbeitest du für Dritte, prüfst du zusätzlich deren Kundenvertrag auf Voraussetzungen für die Weitergabe.
Ein AVV schafft keine Rechtsgrundlage für deine eigene Verarbeitung. Dokumentiere Zweck und Rechtsgrundlage und kläre Informationspflichten sowie Verfahren für Auskunft, Berichtigung und Löschung. Die Orientierungshilfe der Datenschutzkonferenz verlangt auch eine Vorabprüfung des Risikos. Bei voraussichtlich hohem Risiko ist grundsätzlich eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO erforderlich.
Für aktuelle Sicherheitsunterlagen und Subprozessorinformationen verweist Cursor auf sein Trust Center. Sammle die relevanten Unterlagen zur konkreten Freigabe. Ein allgemeines Zertifikat bestätigt nicht deine individuelle Konfiguration.
Auch Claude-Modelle in Cursor folgen dem Cursor-Produktweg. Die Claude-Code-Datenschutzanleitung behandelt einen anderen Client und dessen Verträge.
Mit einem passenden Vertragsweg kannst du die Datenverwendung im Produkt einstellen. Dafür ist Privacy Mode der nächste konkrete Schritt.
3. Aktiviere Privacy Mode vor der ersten KI-Anfrage
Öffne die Cursor-Einstellungen und suche nach „Privacy Mode“. Aktiviere ihn, bevor du vertraulichen Code mit KI-Funktionen bearbeitest. In einem Team prüfst du zusätzlich die Vorgaben des Administrators.
Cursor erklärt, dass Privacy Mode die Nutzung deiner Inhalte für sein Training ausschließt. Der Anbieter beschreibt außerdem ZDR-Vereinbarungen mit Modellprovidern. ZDR steht für „Zero Data Retention“ und betrifft eine begrenzte Inhaltsaufbewahrung.
Prompts und benötigter Codekontext werden weiterhin übertragen, damit das externe Modell deinen Auftrag bearbeiten kann.
Temporäre Caches und mögliche Sicherheitsausnahmen musst du gesondert berücksichtigen.
Bestimmte Risiko- oder Missbrauchsprüfungen können Inhalte nach eigenen Regeln speichern. Außerdem gilt die ZDR-Zusage nicht automatisch für jedes verfügbare Modell. Prüfe die Kennzeichnung und Freigabe des konkret verwendeten Modells.
Die Enterprise-Hardening-Anleitung beschreibt zentrale Kontrollen wie verpflichtenden Privacy Mode und Modellvorgaben. Ich würde diese für Kundencode verbindlich festlegen.
Privacy Mode beantwortet damit einen Teil der Datennutzung. Welche Dateien in den Kontext gelangen, begrenzt du zusätzlich im Projekt.
4. Begrenze den Codekontext mit .cursorignore
Lege die .cursorignore im Projektwurzelverzeichnis an, um den Codekontext zu begrenzen. Die offizielle Ignore-Dokumentation beschreibt ihre Wirkung und Ausnahmen. Verschachtelte Ignore-Dateien erfordern die optional aktivierte hierarchische Suche.
Für typische Geheimnisdateien kann dein Ausgangspunkt so aussehen. Ergänze anschließend die Datenverzeichnisse deines Projekts.
.env
.env.*
**/credentials.json
**/secrets.json
**/*.pem
**/id_rsa
private-data/Prüfe danach, welche Dateien Cursor tatsächlich berücksichtigt. Eine Ignore-Datei hilft gegen unnötigen Kontext, ersetzt aber keine Zugriffskontrolle des Betriebssystems.
Produktionsgeheimnisse würde ich außerhalb des Agentenprojekts in einem passenden Secret-Store halten und nur minimale Testzugänge freigeben. Wenn ein Test einen Zugang braucht, darf dieser nicht zugleich deine Produktionsdaten öffnen.
Das betrifft auch Dumps und Archive.
Eine komprimierte Sicherung im Projekt enthält möglicherweise genau die Daten, die du aus dem sichtbaren Code entfernt hast. Prüfe daher den ganzen Arbeitsbaum.
Die Kontextregeln begrenzen einen Datenweg, und als Nächstes kontrollierst du die Werkzeuge, die diese Regeln umgehen könnten.
5. Begrenze Terminalaktionen und externe Integrationen
Über das Terminal kann der Agent Dateien lesen und Programme starten, wobei auch erlaubte Tests weitere Prozesse ausführen. Ein Build-Skript verdient deshalb dieselbe Aufmerksamkeit wie ein direkt vorgeschlagener Befehl.
Die Agent-Run-Modes unterscheiden Ausführungs- und Schutzoptionen. Cursors Hardening-Dokumentation empfiehlt „Auto-review“ statt „Run Everything“ und zusätzlich Sandboxing.
Für sensible Projekte würde ich unbegrenzte automatische Ausführung vermeiden.
Prüfe insbesondere Befehle, die Dateien außerhalb des Projekts lesen oder Daten versenden.
Eine automatische Bewertung ersetzt dabei keine technische Dateigrenze.
Arbeite mit einem abgegrenzten Benutzerkonto, Container oder einer passenden Entwicklungsumgebung, deren Dateien und Zugänge beschränkt sind. Gib neue Rechte nur dann frei, wenn der konkrete Arbeitsschritt sie braucht.
Prüfe jeden MCP-Server und jede Erweiterung darauf, wo der Prozess läuft und welche Daten er erhält. Der Vertrag mit Cursor deckt einen beliebigen externen Toolanbieter nicht automatisch ab.
Dein Team muss die Folgen einer Werkzeugfreigabe verstehen. Die Einordnung zur KI-Kompetenzpflicht unterstützt dich bei der Schulungsplanung.
Diese Rechte musst du im konkreten Projekt testen. Ein eigener API-Schlüssel verändert die Grenzen nicht von selbst.
6. Prüfe BYOK und den gewünschten Datenstandort
Bei BYOK („Bring Your Own Key“) hinterlegst du einen eigenen API-Schlüssel für einen unterstützten Modellanbieter. Das kann den Abrechnungs- und Modellzugang ändern.
Es umgeht das Cursor-Backend nicht. Laut API-Key-Dokumentation erstellt Cursor dort weiterhin den endgültigen Prompt. Cursors ZDR-Vereinbarung gilt außerdem nicht für BYOK-Anfragen.
Prüfe daher beide Dienstleister, denn für Cursor bleibt sein eigener Datenweg relevant.
Beim Modellprovider kommen Vertrag, Region und Aufbewahrung hinzu.
Ein Schlüssel aus einem EU-Projekt verlegt nicht das gesamte Cursor-Produkt in die EU.
Die aktuelle Governance-Dokumentation unterscheidet zwei Angebote. US-only Residency umfasst für unterstützte Funktionen und Modelle Inferenz, Verarbeitung und Speicherung. Für die EU plus Island ist auf Anfrage nur Inferenzresidenz verfügbar. Eine breitere EU-Abdeckung wird noch entwickelt.
Die US-Zusage umfasst unter anderem BYOK, eigene Modellgateways, Authentifizierung und externe Integrationen nicht. Prüfe deshalb die Teilnahme deines Teams, das konkrete Modell und alle Ausnahmen. Europäische Inferenz allein belegt keine vollständig europäische Speicherung und Verarbeitung.
Eine Verarbeitung außerhalb der EU ist nicht automatisch unzulässig, braucht aber einen passenden Rechts- und Schutzrahmen. Wenn dein Kunde ausschließlich europäische Verarbeitung verlangt, musst du diese Grenze jedoch tatsächlich nachweisen.
Falls du OpenAI-Modelle außerhalb von Cursor verwenden möchtest, prüfst du einen anderen Produktweg. Die Codex-Datenschutzanleitung erklärt dessen Kontrollen.
Ein zusätzlicher Cloud Agent erweitert den Datenweg nochmals. Seine Umgebung braucht deshalb eine eigene Entscheidung.
7. Prüfe die gewählte Cloud-Agent-Variante separat
Cursor-gehostete Cloud Agents laufen in entfernten virtuellen Maschinen, für die Cursor das Repository klont und eine Arbeitsumgebung einrichtet. Damit kann deutlich mehr Inhalt betroffen sein als bei einer einzelnen KI-Anfrage.
Bei Self-Hosted Machines laufen Dateiedits, Terminal und lokale MCP-Server auf einer von dir verwalteten Maschine. Cursor betreibt weiterhin Agenten-Loop, Inferenz und Planung. Benötigte Dateiinhalte, Toolausgaben und Artefakte können an Cursor übertragen werden. Das ist kein vollständig lokaler Modellbetrieb.
Für Cursor-gehostete Cloud Agents nennt die ausführliche Sicherheitsdokumentation VM-Snapshots mit Löschung nach 90 Tagen Inaktivität. Gespräche bleiben standardmäßig bis zur Löschung oder einer passenden Enterprise-Retention erhalten.
Die Aufbewahrungs- und Netzwerkkontrollen beschreiben eine wichtige Grenze. Die Delete-Agent-API löscht Transkript und Artefakte, nicht den VM-Snapshot. Dieser lässt sich dort nicht auf Anforderung löschen.
Die Governance-Übersicht beschreibt Repositorykopien dagegen als nach Abschluss gelöscht. Diese Angaben sind für eine Löschzusage zu unklar. Lass den geltenden Umfang und die Fristen für dein Konto schriftlich bestätigen, bevor du entsprechend vertrauliche Repositories freigibst.
Startest du einen Cursor-gehosteten Cloud-Lauf mit deaktiviertem Privacy Mode, gilt diese Einstellung bis zum Ende des Auftrags.
Ein Einschalten während des Laufs ändert sie nicht. Aktiviere den Modus deshalb vor dem Start.
Diese Aufbewahrung erfüllt einen anderen Zweck als Modelltraining. Du kannst Privacy Mode aktiviert haben und trotzdem eine gespeicherte Cloud-Unterhaltung besitzen. Für vertrauliche Projekte musst du beide Regeln kennen.
Cursor-gehostete Cloud Agents können Terminalbefehle automatisch ausführen und haben standardmäßig Internetzugang. Prüfe zusätzlich die Secret- und Netzwerkeinstellungen. Eine Egress-Allowlist begrenzt die erlaubten ausgehenden Verbindungen. Für selbst gehostete Worker musst du die eigene Ausführungsumgebung und deren Netzwerkrechte prüfen.
Vor einer Freigabe klärst du insbesondere diese Fragen.
- Welche Repositories darf die Git-Integration klonen?
- Welche Testzugänge erhält die Umgebung und welche Daten öffnen sie?
- Welche externen Hosts darf der Agent erreichen?
- Wer kann Unterhaltungen und Artefakte einsehen?
- Wie werden Gespräche, Snapshots und Zugänge gelöscht oder widerrufen?
Wenn diese Antworten fehlen, würde ich Cloud Agents für das Kundenprojekt sperren. Du kannst zunächst den lokalen Agenten prüfen. Dessen Modellanfragen bleiben trotzdem ein externer Datenweg.
Für einen separaten Terminal-Agenten kannst du den Vergleich von Claude Code und Codex nutzen. Auch dort bleibt eine eigene Datenschutzprüfung erforderlich.
Ob die festgelegten Kontrollen im Projekt zusammen funktionieren, zeigt erst dein praktischer Test.
8. Teste Kontext, Terminal und Cloud getrennt
Erstelle ein Testprojekt ohne echte Kundendaten, mit einer erlaubten Beispieldatei und einer ignorierten Datei mit erfundenem Inhalt. So kannst du mögliche Übertragungen erkennen, ohne Geheimnisse offenzulegen.
Prüfe anschließend die tatsächlich freigegebenen Funktionen in dieser Reihenfolge.
- Kontrolliere Konto, Organisation, Privacy Mode und ausgewähltes Modell.
- Prüfe, ob die ignorierte Datei im direkten Agentenkontext ausgeschlossen bleibt.
- Teste denselben Zugriff über Terminal und jeden freigegebenen MCP-Server.
- Prüfe die Dateirechte und erlaubten Netzwerkverbindungen der Ausführungsumgebung.
- Teste Cloud Agents separat, einschließlich Git-Rechten, Artefakten und Löschung.
Notiere Einstellung, Client-Version und Ergebnis pro Datenweg. Ein Erfolg bei .cursorignore belegt keine sichere Terminalausführung. Ein sicherer Terminaltest belegt keine passende Cloud-Retention.
Zeigt ein Test die falsche Grenze, sperrst du die Funktion bis zur korrigierten Konfiguration und erneuten Prüfung. Eine zusätzliche Regel im Chat reicht dafür nicht.
Dokumentiere die erlaubten Projekte und Funktionen in deiner betrieblichen KI-Richtlinie. Lege jetzt ein bereinigtes Testrepository an und prüfe es mit dem vorgesehenen Cursor-Konto.
