Cursor SpaceX Privacy Mode: Datenschutz-Checkliste

Am 14.08.2026 bestätigte Cursor offiziell den Abschluss der Übernahme durch SpaceX; gleichzeitig wurde Grok 4.6 als neues Modell in Cursor genannt. (cursor.com) Der Gewinner bei der Datenschutzprüfung ist deshalb nicht ein bestimmtes Modell, sondern eine dokumentierte Abnahme: Privacy Mode im aktuellen Konto prüfen, die Teamrichtlinie festhalten und eine Testanfrage bis zum Zielendpunkt verfolgen. Privacy Mode kann den Einsatz für Training ausschließen, verhindert aber nicht automatisch die Verarbeitung über das Cursor-Backend. Wer Code vollständig außerhalb dieses Backends halten muss, benötigt ein Werkzeug mit direkter lokaler Modellanbindung.

Für wen diese Anleitung gedacht ist: Entwickler, die private Repositories, Kundencode oder Unternehmensprojekte in Cursor bearbeiten. Ebenso für technische Verantwortliche, die Einstellungen, Modelle und Datenwege revisionsfähig dokumentieren müssen. Teams mit Ollama oder einem anderen selbst gehosteten Modell erhalten außerdem eine klare Entscheidungshilfe zwischen Cursor, einem kontrollierten Remote-Endpunkt und vollständig lokaler Nutzung.

Letzte Aktualisierung: 19.08.2026. Die Angaben wurden gegen die aktuelle Cursor-Datennutzungserklärung, die Cursor-Produktdokumentation, die Übernahmeankündigung und die SpaceXAI-Dokumentation geprüft.

Drei Datenschutz-Ziele, drei unterschiedliche Prüfungen

Die häufigste Fehlentscheidung entsteht, wenn drei Anforderungen unter dem Wort „privat“ zusammengefasst werden:

1. Kein Training: Eingaben und Ausgaben sollen nicht zum Training von Cursor oder Modellanbietern verwendet werden.
2. Eigener Inferenzdienst: Die Anfrage soll mit einem eigenen API key oder einem selbst kontrollierten Modell verarbeitet werden.
3. Kein Cursor-Backend: Quellcode und Prompts sollen den Server von Cursor überhaupt nicht erreichen.

Diese Ziele sind nicht gleichwertig. Die offizielle Data-Use-Erklärung sagt, dass aktivierter Privacy Mode Kundendaten nicht zum Training durch Cursor verwendet. Gleichzeitig weist Cursor ausdrücklich darauf hin, dass auch Anfragen mit eigenem API key weiterhin über das Cursor-Backend laufen, weil dort die endgültige Prompt-Zusammenstellung erfolgt. (cursor.com)

Für eine belastbare Abnahme sollte der Prüfer vor dem Öffnen der Einstellungen vier Werte notieren:

• Cursor-Version und Betriebssystem;
• Kontotyp und Arbeitsbereich;
• Name des Teams sowie mögliche Administratorrichtlinien;
• aktuell ausgewähltes Modell, zum Beispiel Grok 4.6.

Das ist keine Formalität. Ein persönlicher Schalter kann durch eine Teamrichtlinie gesperrt oder überschrieben werden. Außerdem kann ein erfolgreich angezeigtes Modell im Chat nur für Standardanfragen gelten. Tab Completion, Agent-Aufgaben oder Unterprozesse können eine andere Modellroute verwenden. Die API-Key-Dokumentation grenzt eigene Schlüssel ebenfalls auf bestimmte Chat-Szenarien ein. (docs.cursor.com)

Wird der Code nach der Übernahme durch SpaceX für Training verwendet?
Nach der aktuell herangezogenen offiziellen Data-Use-Erklärung gilt: Ist Privacy Mode aktiviert, wird Customer Data durch Cursor nicht für Training verwendet. Die Übernahme vom 14.08.2026 und die Einführung von Grok 4.6 ändern diese Aussage nicht automatisch. Für die konkrete Arbeitsumgebung zählt jedoch der sichtbare Status im Konto oder Team, nicht eine Diskussion in einem Forum. Die offizielle Erklärung nennt außerdem Ausnahmen für Sicherheits- und Missbrauchsprüfungen, wenn ein Risiko-Klassifikator eine Anfrage auslöst. (cursor.com)

Privacy Mode gegen Teamrichtlinie: zuerst die Einstellung beweissicher machen

Die Prüfung beginnt in Cursor Settings. Suchen Sie im allgemeinen Einstellungsbereich nach Privacy Mode beziehungsweise nach der Datenschutzoption, die in der aktuell installierten Version angezeigt wird. Die genaue Position und Bezeichnung können sich ändern; alte Screenshots sollten deshalb immer mit Cursor-Version und Aufnahmedatum archiviert werden.

Die Kontrolle besteht aus zwei Ebenen:

1. Persönlichen Status ablesen

Der Schalter muss eindeutig aktiviert sein. Nicht ausreichend sind:

• eine allgemeine Zusicherung des Anbieters;
• ein ausgewähltes Modell mit dem Hinweis „private“;
• ein eigener API key;
• ein leerer Verlauf;
• die Tatsache, dass bisher kein Training beobachtet wurde.

Der Status sollte mit einem Screenshot dokumentiert werden. Im Screenshot müssen Arbeitsbereich und Einstellung erkennbar sein, während sensible Kontodaten geschwärzt werden.

2. Teamvorgabe prüfen

Unternehmensnutzer sollten zusätzlich kontrollieren, ob der Privacy-Mode-Schalter gesperrt ist. Eine lokale Änderung ohne Wirkung ist ein Abnahmefehler. Der Nachweis gehört in das Protokoll:

• Datum und Uhrzeit;
• Arbeitsbereich;
• Name oder Rolle des Administrators;
• sichtbarer Status;
• ausgewähltes Modell;
• Hinweis, ob die Einstellung bearbeitbar oder gesperrt ist.

Cursor beschreibt Privacy Mode als Einstellung, die durch einen Teamadministrator aktiviert werden kann. Die Sicherheitsdokumentation erklärt außerdem, dass Anfragen je nach Privacy-Status unterschiedlich verarbeitet werden. (cursor.com)

Wichtig: „Nicht für Training verwendet“ bedeutet nicht „niemals verarbeitet“. Cursor kann Anfragen zur Bereitstellung der Funktion, zur Missbrauchserkennung oder zur technischen Fehleranalyse verarbeiten. Bei besonders geschützten Daten sollte die eigene DSGVO-Bewertung deshalb zusätzlich Datenkategorien, Auftragsverarbeitung, Speicherorte und Löschfristen erfassen. Die Datenschutzinformationen von ProxyMac können als ergänzende Checkliste für diese organisatorische Prüfung dienen: Datenschutz und Datenverarbeitung.

Was bedeutet ein deaktivierter Privacy Mode?

Die Data-Use-Erklärung beschreibt für den deaktivierten Zustand eine deutlich weitere Nutzung: Codebasisdaten, Prompts, Editoraktionen, Codeausschnitte und andere Code-Daten können zur Verbesserung von KI-Funktionen und zum Training verwendet werden. Darüber hinaus können einige Inferenzanbieter Eingaben und Ausgaben vorübergehend zur Verbesserung der Inferenzleistung speichern. (cursor.com)

Für ein Team mit Kundencode lautet die Konsequenz daher nicht „Der Anbieter wurde übernommen, also alles sperren“. Die korrekte Maßnahme ist: Schalter prüfen, Teamrichtlinie verifizieren, Beleg speichern und erst danach eine nicht sensible Testanfrage ausführen.

API key ist Kontensteuerung, aber keine direkte Privatroute

Ein eigener Cursor API key oder ein Schlüssel eines Modellanbieters löst mehrere praktische Probleme:

• Abrechnung kann beim eigenen Anbieter liegen;
• Modellzugriff und Kontingent lassen sich zentral verwalten;
• ein Team kann bestimmte Modelle oder Endpunkte kontrollieren;
• Anbieterwechsel ist möglich, ohne das gesamte Editor-Setup zu ersetzen.

Er löst aber nicht automatisch das Problem „Code darf Cursor nicht erreichen“. Cursor dokumentiert ausdrücklich, dass eigene Schlüssel weiterhin über das eigene Backend verwendet werden. Dort wird der finale Prompt aufgebaut, bevor die Anfrage an den gewählten Dienst weitergeleitet wird. (cursor.com)

Bleibt eine Anfrage mit eigenem API key auf dem Gerät?
Nein. Nach der offiziellen Beschreibung ist der API key kein Beweis für eine lokale Direktverbindung. Er belegt lediglich, welcher Anbieter oder welches Konto für die Modellanfrage verwendet wird. In das Abnahmeprotokoll gehören deshalb zwei getrennte Aussagen:

• Training ausgeschlossen: Ja oder Nein, abhängig vom nachgewiesenen Privacy-Mode-Status.
• Übertragung an Cursor ausgeschlossen: Nein, solange Cursor als Client und Prompt-Assembler eingesetzt wird.

Auch die Nutzungsanzeige muss kontrolliert werden. Nach der Eingabe des Schlüssels sollte der Prüfer eine harmlose Anfrage senden und anschließend beim jeweiligen Anbieter oder im Abrechnungssystem kontrollieren, ob ein Verbrauchseintrag entstanden ist. Ein fehlender Eintrag kann allerdings auch auf Caching, ein nicht unterstütztes Modell oder eine Fallback-Route hinweisen. Er ist allein kein Beweis für den tatsächlichen Datenweg.

Eigener Endpunkt gegen lokales Ollama: der entscheidende Architekturunterschied

Die Konfiguration eines eigenen Base URL wirkt auf den ersten Blick wie eine lokale Lösung. In Cursor ist sie jedoch typischerweise eine kontrollierte externe Route, nicht zwingend eine direkte Verbindung vom Mac zum Modell.

Die Prüfung sollte in dieser Reihenfolge erfolgen:

1. Models öffnen. Das gewünschte Standardmodell auswählen.
2. API Keys öffnen. Den Schlüssel des vorgesehenen Anbieters eintragen und mit „Verify“ oder der aktuellen Prüfaktion validieren.
3. OpenAI Base URL überschreiben. Nur dann ändern, wenn der eigene Dienst die erwartete API-Struktur und Authentifizierung unterstützt.
4. Benutzerdefiniertes Modell eintragen. Modellname exakt aus dem Serverprotokoll übernehmen.
5. Endpoint-Schutz aktivieren. HTTPS, Authentifizierung, Zugriffsliste und Protokollierung einrichten.
6. Fallbacks prüfen. Nicht unterstützte Funktionen dürfen nicht still auf ein eingebautes Cursor-Modell zurückfallen.

Kann Cursor direkt mit dem Ollama-Prozess auf dem eigenen Mac sprechen?
Für den hier geprüften Architekturpfad lautet die Antwort: nicht als verlässliche lokale Direktverbindung. Der Cursor-Backend-Dienst muss den konfigurierten Endpunkt erreichen können. Ein Dienst, der nur unter localhost auf dem Entwickler-Mac lauscht, ist aus Sicht dieses Backends nicht erreichbar. Community-Rückmeldungen beschreiben genau diese Einschränkung: Für BYOK-Modelle wird eine von Cursor erreichbare öffentliche URL benötigt; lokale Portweiterleitungen sind dafür nicht als Standardlösung vorgesehen. (forum.cursor.com)

Damit wird aus „Ollama in Cursor“ meist folgendes Modell:

Cursor-Client → Cursor-Backend → authentifizierter HTTPS-Endpunkt → Ollama oder eigener Inferenzserver

Das unterscheidet sich klar von:

Lokaler Editor oder Proxy → Ollama auf demselben Gerät

Der zweite Weg ist für die Anforderung „Code darf Cursor nicht erreichen“ die passendere Architektur. Ein öffentlicher Tunnel zum privaten Mac ist dagegen kein automatischer Sicherheitsgewinn. Er bringt zusätzliche Risiken:

• gestohlene oder falsch verteilte Zugangsdaten;
• fehlende IP- oder Netzwerkbegrenzung;
• dauerhafte Request- und Fehlerprotokolle;
• nicht kontrollierte Wiederholungsversuche;
• neue Angriffsfläche am Entwicklergerät;
• unklare Verantwortlichkeit bei Logs und Backups.

Ein selbst gehosteter Endpunkt sollte deshalb eher auf einer isolierten Maschine laufen. Für Teams, die Ollama dauerhaft benötigen, aber lokale Betriebszeit, Rechenleistung oder Netzwerkisolierung nicht zuverlässig bereitstellen können, kann ein gemieteter Remote-Mac sinnvoller sein als ein dauerhaft exponierter Entwickler-Mac. Das ist jedoch nur dann passend, wenn Endpoint-Schutz, Zugriffskontrolle und Datenklassifizierung vorab geklärt sind.

Die Testanfrage muss den gesamten Weg sichtbar machen

Eine erfolgreiche Antwort im Chat beweist nur, dass irgendeine Route funktioniert hat. Für eine echte Abnahme braucht es eine nicht sensible, wiederholbare Probe.

Geeignet ist zum Beispiel eine Anfrage mit:

• erfundenem Projektnamen;
• künstlicher Funktion;
• eindeutigem Testmarker;
• keinem Kundencode;
• keinem Zugriff auf das private Repository;
• keinem echten Geheimnis oder Token.

Der Marker sollte nur in dieser Testphase verwendet werden, etwa als zufällige Zeichenfolge. Im Log des eigenen Endpunkts werden dann vier Werte verglichen:

1. Zeitstempel der Anfrage;
2. erwarteter Modellname;
3. HTTP-Status und Antwortstatus;
4. Request-ID oder Korrelations-ID.

Danach folgen getrennte Tests:

• normale Chat-Anfrage;
• Code-Completion;
• Agent-Aufgabe;
• Unteraufgabe oder automatische Tool-Aktion, sofern im Team aktiviert.

Diese Trennung ist wichtig. Die Cursor-Dokumentation weist darauf hin, dass eigene API keys nicht alle Funktionen abdecken. Spezialisierte Funktionen können weiterhin auf integrierte Modelle zurückgreifen. (docs.cursor.com)

Wie lässt sich belegen, dass Cursor tatsächlich den eigenen Endpunkt verwendet?
Nur durch die Kombination aus Cursor-seitigem Modellnamen, Endpunkt-Log, Zeitstempel, Response-Status und Request-ID. Ein ausgewählter Modellname ohne passenden Servereintrag gilt als „nicht bestanden“. Gleiches gilt für eine Antwort, die zwar korrekt aussieht, aber im eigenen Log nicht auftaucht.

Bei einem Fehler werden folgende Informationen gespeichert:

• Request-ID;
• genaue Fehlermeldung;
• ausgewähltes Modell;
• Base-URL-Konfiguration;
• Uhrzeit mit Zeitzone;
• Server-Log;
• Hinweis auf mögliche Fallbacks.

Abnahmeprotokoll zum direkten Abhaken

• [ ] Cursor-Version und Betriebssystem dokumentiert
• [ ] Konto, Arbeitsbereich und Teamrichtlinie erfasst
• [ ] aktuelles Modell, einschließlich Grok 4.6, notiert
• [ ] Privacy Mode im aktuellen Einstellungsbereich geöffnet
• [ ] Screenshot des Status mit Datum gespeichert
• [ ] geprüft, ob der Schalter durch einen Administrator gesperrt ist
• [ ] Trainingsausschluss separat von Übertragungsverbot bewertet
• [ ] eigener API key einem Anbieter und Modell zugeordnet
• [ ] Testverbrauch beim vorgesehenen Anbieter kontrolliert
• [ ] Base URL und benutzerdefinierter Modellname dokumentiert
• [ ] HTTPS und Authentifizierung am eigenen Endpunkt aktiviert
• [ ] Zugriff von Cursor auf den Endpunkt technisch bestätigt
• [ ] harmlose Testanfrage mit eindeutiger Request-ID ausgeführt
• [ ] Zeit, Modellname, Status und Herkunft im Endpunkt-Log abgeglichen
• [ ] Chat, Completion und Agent-Aufgabe getrennt getestet
• [ ] Fallback-Verhalten bei nicht unterstützten Funktionen geprüft
• [ ] bei Unklarheit Fehlerdaten statt einer Erfolgsbehauptung archiviert

Drei Wege nach einem fehlgeschlagenen Test

Ziel der Organisation	Cursor mit Privacy Mode	Eigener Endpunkt mit Ollama	Direkte lokale Modellnutzung
Training ausschließen	Geeignet, wenn Status und Teamrichtlinie belegt sind	Zusätzlich möglich	Möglich
Eigenes Modell kontrollieren	Teilweise geeignet	Geeignet, wenn HTTPS und Logs kontrolliert werden	Geeignet
Cursor-Backend vollständig vermeiden	Nicht geeignet	Nicht zuverlässig, wenn Cursor den Endpunkt aufruft	Erforderlich
Agent- und Completion-Funktionen	Je nach Modell und Plan prüfen	Vorab für jede Funktion testen	Vom lokalen Werkzeug abhängig
Betriebsaufwand	Niedrig	Mittel bis hoch	Auf dem eigenen Gerät oder einer isolierten Umgebung
Hauptnachweis	Privacy-Mode-Screenshot und Richtlinie	Endpunkt-Logs und Request-ID	Lokaler Prozess- und Netzwerkpfad

Die Tabelle ist keine Produktwertung. Sie beantwortet die eigentliche Architekturfrage: Soll nur Training ausgeschlossen werden, soll die Modellwahl kontrolliert werden oder darf der Code den Cursor-Server überhaupt nicht erreichen?

Fall A: Nur Training verhindern

Wenn das Ziel lediglich lautet „Code nicht zum Training verwenden“, bleibt Cursor grundsätzlich eine Option. Der Privacy Mode muss aktiv sein. Die Teamrichtlinie muss dazu passen. Die Fassung der Datenschutz- und Vertragsunterlagen sollte zum Prüfdatum archiviert werden. Bei Änderungen an der Produktbeschreibung oder an den Modellrichtlinien wird die Abnahme wiederholt.

Fall B: Eigenes Modell betreiben

Wenn das Team Inferenz selbst kontrollieren möchte, kann ein eigener API key oder ein selbst verwalteter Base URL sinnvoll sein. Das Backend-Routing von Cursor bleibt dabei Bestandteil der Architektur. Die Sicherheitsprüfung konzentriert sich dann auf Authentifizierung, Endpunktzugriff, Protokollaufbewahrung, Fallbacks und die Frage, welche Daten Cursor vor dem Weiterleiten verarbeitet.

Für die organisatorische Umsetzung sollten Entwickler außerdem die internen Zugänge und Wiederherstellungswege dokumentieren. Die Hilfe- und Kontoverwaltungsseite von ProxyMac ist dafür als ergänzende Betriebscheckliste nutzbar, ersetzt aber keine Prüfung der Cursor-Datenwege.

Fall C: Kein Code darf Cursor erreichen

Dann ist weiteres Ändern des API keys die falsche Maßnahme. Auch ein eigener Base URL ändert nicht automatisch, dass Cursor den Prompt zunächst über das eigene Backend aufbaut. Erforderlich ist ein Editor oder Proxy, der das lokale Modell direkt anspricht und dessen Netzwerkverkehr technisch kontrollierbar ist.

Remote Mac als isolierte Ausweichumgebung

Ein Remote Mac kann für Teams interessant sein, die Ollama oder einen eigenen Inferenzserver dauerhaft betreiben möchten, aber den Dienst nicht auf einem persönlichen Arbeitsgerät veröffentlichen wollen. Der Vorteil liegt nicht darin, dass Cursor dadurch automatisch lokal wird. Der Vorteil liegt in der möglichen Trennung:

• eigener Benutzer und eigene Schlüssel;
• getrennte Arbeitsumgebung;
• kontrollierter Netzwerkzugang;
• klarere Log- und Löschregeln;
• definierte Laufzeit statt eines dauerhaft offenen Entwickler-Macs.

Vor einer Anmietung müssen Modellgröße, Parallelität, Speicherbedarf, erwartete Onlinezeit und Datenklassifizierung feststehen. Ein Remote Mac ist nicht die beste Wahl für jeden Fall. Für dauerhaft hohe Last, spezielle Hardwareanforderungen oder physische Schnittstellen kann ein eigener Server besser passen. Für zeitlich begrenzte Tests, isolierte Entwicklungsumgebungen und wechselnde Projekte ist eine gemietete Umgebung dagegen leichter rückbaubar.

Wer diese Variante prüft, sollte zuerst den eigenen Datenschutzrahmen von ProxyMac und anschließend die konkrete Betriebsanforderung dokumentieren. Entscheidend bleiben die technischen Nachweise: Modellprozess, Endpoint-Log, Zugriffsschutz und Löschkonzept.

Aktuelle Cursor-Route gegen kontrollierte Mac-Umgebung

Cursor mit aktiviertem Privacy Mode hat einen klaren Vorteil: Der Trainingsausschluss ist schnell prüfbar und für normale Entwicklungsarbeit komfortabel. Die Nachteile liegen an anderer Stelle. Der Code wird weiterhin für die Funktion über Cursor verarbeitet, ein eigener API key umgeht das Backend nicht, und Agent- oder Completion-Funktionen können eine andere Modellroute verwenden.

Eine selbst betriebene Mac-Umgebung verursacht dagegen Miet- oder Betriebsaufwand, benötigt Netzwerk- und Schlüsselverwaltung und verlangt eine eigene Überwachung. Dafür lässt sich die Umgebung stärker isolieren, und ein lokaler Modellpfad kann die zentrale Datenschutzanforderung „kein Code durch Cursor“ besser erfüllen. Für temporäre Modelltests oder eine getrennte Entwicklungsumgebung ist es daher oft sinnvoller, einen kontrollierten Remote Mac zu verwenden, statt einen lokalen Ollama-Dienst über einen öffentlichen Tunnel an Cursor anzubinden.

Wenn die Entscheidung auf eine zeitweise isolierte Umgebung fällt, kann ProxyMac als nächster Schritt anhand von Modell, parallelen Nutzern, gewünschter Laufzeit und Datenklassifizierung eine passende Mac-Umgebung prüfen. Der entscheidende Prüfpunkt bleibt dabei unverändert: Erst den Datenweg definieren, dann den Dienst auswählen.