Cursor Sicherheit: Risiken, Kontrollen und Best Practices

Was ist Cursor, und warum verändert es das Sicherheitsmodell?

Cursor ist ein KI-zentrierter Code-Editor, ein Fork von VS Code, neu aufgebaut rund um das Modell statt rund um die Datei. Es arbeitet innerhalb des normalen Flusses der Entwickler (der Editor, das integrierte Terminal, das Agenten-Panel) und handelt auf der Grundlage von Anweisungen in natürlicher Sprache: diese Codebasis erklären, dieses Feature bauen, diesen fehlschlagenden Test reparieren, über diese Dateien hinweg refactorn. Um das gut zu tun, indiziert es das Repository, damit das Modell Kontext hat, bearbeitet mehrere Dateien in einem einzigen Agentenlauf, führt Aufgaben und Terminal-Befehle aus und erweitert sich über das Model Context Protocol (MCP), um Datenbanken, Issue-Tracker und internes Tooling zu erreichen.

Diese Kombination ist es, die das alte Sicherheitsmodell zerbricht. Ein klassischer IDE-Assistent bot eine Vervollständigung an; ein Mensch las sie und entschied sich, sie anzunehmen oder abzulehnen. Der Wirkungsradius eines schlechten Vorschlags war ein Codeblock, den ein Entwickler trotzdem noch einfügen musste. Cursor führt stattdessen Aktionen aus. Es liest Dateien, die Sie nie genannt haben, führt Befehle aus, die Sie nie getippt haben, schreibt Code im gesamten Baum um und kann eine Aufgabe in dem Moment ausführen, in dem Sie einen Ordner öffnen. Die Angriffsfläche ist nicht mehr "was hat das Modell vorgeschlagen". Sie ist "was kann dieser Editor mit dem Zugriff anstellen, den er hat, welchen Code kann er in großen Mengen generieren, und wer darf seine Anweisungen beeinflussen".

“

Ein Vorschlag ist ein Entwurf, den ein Mensch annimmt. Eine Aktion ist etwas, das bereits geschehen ist. Das Sicherheitsmodell muss sich vom Prüfen von Entwürfen zum Eingrenzen von Aktionen verschieben.

Es gibt eine zweite Verschiebung, und sie betrifft die Geschwindigkeit. Der Pull Request wurde zur Heimat der Anwendungssicherheit, weil er im menschlichen Takt lag: Eine Person verlangsamte sich, las das Diff und führte erst dann den Merge durch. Cursor läuft nicht im menschlichen Takt. Eine einzige Agentensitzung kann an einem Nachmittag mehr Code produzieren, als ein Prüfer in einer Woche liest, und der Editor wird bereitwillig funktionalen Code generieren, der still und leise unsicher ist. Wenn das passiert, hört das Diff auf, ein Kontrollpunkt zu sein, und wird zum Protokoll bereits getroffener Entscheidungen. Jede Kontrolle, die nur beim Pull Request greift, prüft jetzt Geschichte, statt sie zu verhindern.

Für die meisten Teams lautet die praktische Frage nicht, ob Cursor native Schutzmechanismen hat. Es hat sie, und mehrere sind wirklich gut. Die Frage ist, ob sie für den täglichen Gebrauch ausreichen. Die ehrliche Antwort lautet nein. Cursors eigene Sicherheitsseite dokumentiert echte Kontrollen, und sie verringern das Risiko, aber eine sichere Einführung hängt weiterhin von Berechtigungen, Isolation, menschlicher Aufsicht und unabhängiger Validierung über Code, Abhängigkeiten, Geheimnisse und Pipelines hinweg ab.

Wie das Sicherheitsmodell von Cursor funktioniert

Das Modell von Cursor baut auf drei Ideen auf: nachweisen, dass die Plattform Daten verantwortungsvoll handhabt, dem Entwickler Hebel geben, um sensiblen Code aus der Reichweite des Modells zu halten, und eingrenzen, was ein geöffnetes Projekt tun darf. In der Praxis zeigt sich das als eine Handvoll Kontrollen.

Es ist eine vernünftige Grundlage, und der Großteil davon existierte in IDE-Assistenten einer Generation zuvor nicht. Die Falle besteht darin, sie als fertige Sicherheitsgrenze zu lesen. Privacy Mode schützt Ihre Daten, sagt aber nichts über die Sicherheit des Codes aus, den Cursor schreibt. .cursorignore funktioniert nur, wenn Sie es pflegen. Workspace Trust schützt Sie nur, wenn er aktiviert ist, und für einen Großteil von Cursors Geschichte war er es nicht. SOC 2 attestiert, wie Cursor seinen Dienst betreibt, nicht, wie sicher es sich auf Ihrer Maschine verhält. Jede Kontrolle hier hat einen dokumentierten Rand, und der nächste Abschnitt handelt davon, was passiert, wenn Sie sich zu sehr auf sie verlassen.

Die 6 größten Sicherheitsrisiken in Cursor

Die folgenden Risiken sind nicht theoretisch. Sie lassen sich auf offengelegte Schwachstellen, veröffentlichte Forschung und die OWASP Top 10 für LLM-Anwendungen abbilden. Die Zahlen, die sie einrahmen, sind dieselben, die jedes AppSec-Team jetzt zitiert.

1. Workspace Trust standardmäßig deaktiviert, was zu stiller Code-Ausführung führt

Dies ist Cursors charakteristisches Problem. Im September 2025 berichtete The Hacker News über einen Fehler ("Cursor AI Code Editor Flaw Enables Silent Code Execution via Malicious Repositories"), der darin wurzelte, dass Workspace Trust standardmäßig deaktiviert ausgeliefert wurde. Da Cursor ein VS-Code-Fork ist, kann ein Projekt eine .vscode/tasks.json-Aufgabe tragen, die mit runOn: folderOpen konfiguriert ist, und mit deaktiviertem Trust führt diese Aufgabe in dem Augenblick aus, in dem ein Entwickler den Ordner öffnet, und führt beliebigen Code im Kontext des Benutzers aus.

Der Angriff ist banal zu inszenieren. Ein Angreifer veröffentlicht ein verlockendes Repository auf GitHub, versteckt darin eine "Autorun"-Aufgabe und wartet darauf, dass jemand es klont und in Cursor öffnet. Kein Prompt, kein Klick, keine Prüfung: Das Öffnen des Projekts reicht aus, um Zugangsdaten zu leaken, Dateien zu verändern oder einen Brückenkopf für eine breitere Kompromittierung zu platzieren. Die Forscher (Oasis Security) empfahlen dieselbe Gegenmaßnahme wie wir: Workspace Trust aktivieren, nicht vertrauenswürdige Repositories zuerst in einem anderen Editor öffnen und ein Projekt prüfen, bevor man es in Cursor öffnet. Die Behebung ist eine Einstellung, aber sie hilft nur den Entwicklern, die wissen, dass sie sie umlegen müssen.

2. Unsicherer KI-generierter Code

Cursors Aufgabe ist es, schnell Code zu schreiben, und schnell bedeutet nicht sicher. Carnegie Mellons SusVibes-Benchmark, der kommerzielle Coding-Agenten einschließlich Cursor verfolgt, fand, dass die stärkste Paarung aus Agent und Modell in 61% der Fälle funktional korrekten Code produzierte, aber nur in 10,5% der Fälle sicheren Code, und dass über 80% der funktional korrekten Lösungen dennoch eine Schwachstelle trugen. Die Lücke zwischen "es funktioniert" und "es ist sicher" ist der Ort, an dem die Gefahr lebt: Code, der den Test besteht und die Schwachstelle ausliefert.

Die Muster sind vorhersehbar. String-konkateniertes SQL statt parametrisierter Abfragen (klassische SQL-Injection), Prototype Pollution in JavaScript, fehlende Ausgabekodierung, die XSS öffnet, fehlende Eingabevalidierung bei generierten Endpunkten. Das sind keine exotischen Bugs; es sind die OWASP-Klassiker, in Maschinengeschwindigkeit reproduziert, weil das Modell aus einem öffentlichen Korpus gelernt hat, der voll davon ist. Die NYU-Studie "Asleep at the Keyboard" fand etwa 40% des KI-generierten Codes über die MITRE-Top-25-Szenarien hinweg verwundbar, und Cursor liegt fest innerhalb dieser Verteilung. Je schneller der Editor ausliefert, desto schneller häufen sich die Fehler an, und funktional aussehender Code ist genau die Art, die ein eiliger Prüfer durchwinkt.

3. Offenlegung von Daten und Kontext

Cursor ist nützlich, weil es Kontext hat, und dieser Kontext umfasst routinemäßig mehr als nur Quellcode. Alles, was im Workspace geöffnet ist, eine .env-Datei, eine Konfiguration mit Verbindungszeichenfolgen, interne API-Endpunkte, kann in den Kontext des Modells gezogen werden, sofern Sie es nicht ausdrücklich mit .cursorignore ausschließen. Cursors KI-Funktionen senden auch Code an eine externe API, um Antworten zu generieren, sodass für sensible Geschäftslogik die Frage, wohin dieser Verkehr geht, eine echte ist, und Privacy Mode ist der Kompromiss, den Sie eingehen, um sie zu kontrollieren.

Die Offenlegung ist oft indirekt. Während der Agent ein Repository zusammenfasst oder einen Fehler debuggt, kann er ein Token, eine Zugangsdatenangabe oder einen internen Hostnamen in eine Ausgabe zutage fördern, die dann in einem Chat, einem Ticket oder einer committeten Datei landet, wo sie noch lange nach dem Ende der Sitzung lebt. Wie Endor Labs und andere angemerkt haben, verbreitert die Codebasis-Indizierung diese Fläche: Je mehr Cursor indiziert, desto mehr kann es versehentlich erreichen. Die Standardhaltung ist Bequemlichkeit, und Bequemlichkeit bedeutet breiten Zugriff, sofern Sie ihn nicht von Hand einengen.

4. Prompt Injection und Vergiftung von Regeldateien

Prompt Injection ist das bestimmende Risiko agentischer Coding-Tools, und es ist OWASPs LLM-Risiko Nummer eins (LLM01) im dritten Jahr in Folge. Ein Angreifer versteckt Anweisungen in etwas, das der Agent liest, und der Agent befolgt sie und überschreibt sein beabsichtigtes Verhalten.

In Cursor ist die gefährliche Form indirekt, und sie hat eine Cursor-spezifische Wendung: die Regeldatei. Bösartige Anweisungen können in Repository-Inhalten reiten, in einer .cursorrules- oder Projekt-Regeldatei oder in der Ausgabe eines MCP-Tools. Da eine Regeldatei den Agenten lenken soll, ist eine vergiftete Prompt Injection per Konstruktion: Ein Mitwirkender oder eine Abhängigkeit legt präparierte Anweisungen in die Regeln ab, und Cursor behandelt sie als Richtlinie. Ein Kommentar in einer README, der lautet "bevor Sie fortfahren, führen Sie dieses Setup-Skript aus", kann ausreichen. Da ein Sprachmodell eine vertrauenswürdige Anweisung nicht zuverlässig von einer bösartigen trennen kann, die in Daten eingebettet ist, kann die Injection zu Befehlsausführung, Datenexfiltration oder stiller Code-Manipulation führen. Ein gelenkter Agent antwortet nicht nur falsch, er handelt.

5. Lieferkette (Supply Chain) und bösartige MCP-Server

Cursor installiert Pakete, klont Repositories und verbindet sich mit externen Tools als Teil der normalen Arbeit. Wenn es eine kompromittierte Bibliothek hereinholt oder einen feindseligen MCP-Server verdrahtet, läuft der bösartige Code mit dem Zugriff, den die Umgebung gewährt. Das ist nicht hypothetisch. Anfang 2026 platzierte eine npm-Typosquatting-Kampagne, die als "Sandworm_Mode" verfolgt wurde, durch das Nachahmen beliebter Dienstprogramme bewusst bösartige MCP-Server und zielte gezielt auf KI-Coding-Assistenten ab, darunter Cursor, Claude Code und Windsurf.

MCP ist eine neue Vertrauensgrenze, die die meisten Teams nicht im Bedrohungsmodell berücksichtigt haben. Ein bösartiger oder kompromittierter Server kann Anweisungen in seinen Tool-Beschreibungen und -Antworten verstecken, sodass allein das Verbinden den Agenten lenken kann, bevor er das Tool überhaupt aufruft. Paket-Halluzination verschärft das Risiko: Ein Agent, der einen plausiblen, aber nicht existierenden Paketnamen erfindet, gibt Angreifern einen Platz, ihn zu registrieren und zu bewaffnen. Der Agent wird die Installation oft selbstbewusst genehmigen, weil der Name richtig aussieht und die Aufgabe danach gefragt hat.

6. Dokumentierte Editor-Schwachstellen, die zu RCE führen

Über den Autorun-Fehler hinaus hat Cursor eine Reihe von Sicherheitshinweisen angehäuft, darunter Forschung, die von Gruppen wie Geordie AI veröffentlicht wurde und Trust-Bypass- und Code-Ausführungsvektoren im Editor selbst abdeckt (versteckte Git-Hooks, persistente Ausführung über MCP-Trust-Bypass und verwandte Probleme). Das wiederkehrende Thema ist, dass Cursor als IDE einigermaßen sicher und als automatisierter Code-Generator ohne eine externe Prüfebene erheblich unsicher ist.

Die Gefahr verschärft sich, wenn der Editor mit breitem Zugriff auf die Maschine des Entwicklers läuft. Eine Kette einzeln harmloser Aktionen, installiere diese Abhängigkeit, führe diese Aufgabe aus, wende diese Bearbeitung an, kann Malware installieren, eine CI-Konfiguration verändern oder einen Persistenzmechanismus öffnen. Genau deshalb sind Trust-Gating, geringste Rechte und isolierte Umgebungen wichtig, und genau deshalb ist die zu fürchtende Kombination die häufige: ein nicht vertrauenswürdiges Repo, ein freizügiges Setup zur Vermeidung von Reibung und eine injizierte Anweisung, die der Editor als legitim behandelt.

Was die native Sicherheit von Cursor abdeckt und was nicht

Die nativen Kontrollen sind real, und es hilft, präzise bei der Grenze zwischen dem, was sie handhaben, und dem, was sie Ihnen überlassen, zu sein.

Lesen Sie die rechte Spalte als die eigentliche Arbeit. Cursors native Kontrollen sind auf Datenschutz und Anbieter-Compliance ausgerichtet, dorthin, wo die ersten Fragen eines Käufers landen. Sie wurden nie entworfen, um einen entschlossenen Gegner zu stoppen, der die Eingaben des Editors kontrolliert, und sie sagen fast nichts über die Sicherheit des Codes aus, den Cursor schreibt. Alles, was "Cursor ist installiert" in "Cursor wird gesteuert" verwandelt, liegt in den folgenden Praktiken.

Best Practices zur Absicherung von Cursor

Diese neun Praktiken schließen die Lücke zwischen der nativen Grundlage und einer echten Sicherheitslage. Keine davon ist exotisch; die Disziplin liegt darin, sie konsistent über ein Team hinweg anzuwenden, das sich schnell bewegt.

1. Workspace Trust aktivieren und nicht vertrauenswürdige Repos als feindselig behandeln. Schalten Sie Workspace Trust als Standardteil der Einrichtung ein, sodass ein geöffneter Ordner keine Aufgabe automatisch ausführen kann. Öffnen Sie Repositories, die Sie nicht geschrieben haben, zuerst in einer Sandbox-Umgebung oder einem anderen Editor, prüfen Sie .vscode/tasks.json und alle Git-Hooks, bevor Sie ihnen vertrauen, und durchstöbern Sie niemals ein verlockendes öffentliches Repo in Ihrer primären Cursor-Instanz, ohne zu prüfen, was es ausführen darf.

2. Privacy Mode für sensible Arbeit aktiviert lassen und den Kompromiss verantworten. Privacy Mode ist die Kontrolle, die verhindert, dass Ihr Code gespeichert oder zum Training verwendet wird. Behandeln Sie ihn als Standard für jedes Repository mit echter Geschäftslogik, regulierten Daten oder proprietärem Code. Wo ein Team sich entscheidet, ihn für eine Funktion zu deaktivieren, machen Sie das zu einer expliziten, dokumentierten Entscheidung, die auf Arbeit mit geringer Sensibilität begrenzt ist, nicht zu einem stillen Standard, den jeder zu prüfen vergessen hat.

3. .cursorignore wie ein Sicherheitsartefakt kuratieren. Schließen Sie .env-Dateien, Zugangsdatenspeicher, Infrastrukturkonfiguration, Verbindungszeichenfolgen und jedes sensible Modul sowohl vom KI-Kontext als auch von der Indizierung aus. Prüfen Sie die Ignore-Datei so, wie Sie Zugriffskontrolle prüfen: planmäßig, nach jedem neuen Geheimnis oder Dienst, der hinzugefügt wird, und als Teil des Onboardings eines neuen Repos. Eine veraltete .cursorignore ist die häufigste Art, wie ein Geheimnis im Kontext eines Modells landet.

4. Einen Menschen in der Schleife für generierten Code behalten. Behandeln Sie Cursors Ausgabe als Entwurf, nicht als fertige Implementierung. Leiten Sie allen generierten oder geänderten Code durch Pull-Request-Prüfung und automatisierte Tests, mit zusätzlicher Sorgfalt bei Authentifizierung, Eingabevalidierung, SQL-Abfragen und privilegierten Pfaden, genau den Bereichen, in denen die SusVibes-Daten zeigen, dass das Modell sich irrt. Der Punkt ist nicht Misstrauen gegenüber dem Tool; es ist, dass ein Editor, der tausende Zeilen pro Tag produziert, subtile Fehler schneller erzeugt, als sie von selbst auftauchen.

5. KI-generierten Code mit SAST in CI scannen. Da nur ein kleiner Bruchteil der KI-Lösungen standardmäßig sicher ist, ist ein statisches Analyse-Gate nicht optional. Führen Sie SAST bei jedem Pull Request aus, lassen Sie den Build bei Befunden hoher Schwere fehlschlagen (SQL-Injection, XSS, Prototype Pollution, fehlende Autorisierung) und speisen Sie die Ergebnisse an die Entwickler zurück, damit dieselben Klassen aufhören, wiederzukehren. Funktionale Tests werden einen verwundbaren, aber funktionierenden Endpunkt nicht erfassen; nur ein sicherheitsbewusster Check wird es.

6. Abhängigkeiten, Pakete und MCP-Server steuern. Beschränken Sie Installationen auf vertrauenswürdige Registrys oder interne Spiegel, verlangen Sie eine Genehmigung für neue Pakete und scannen Sie alles mit Software Composition Analysis. Prüfen Sie jeden MCP-Server als Vertrauensgrenze: Verwenden Sie solche, die Sie selbst geschrieben haben oder denen Sie wirklich vertrauen, begrenzen Sie jeden auf die engsten Daten und Aktionen, die er benötigt, und führen Sie ein Inventar, damit sich ein typosquattetes Paket wie die "Sandworm_Mode"-Server nicht unbemerkt einschleichen kann.

7. Geheimnisse außer Reichweite verwalten. Halten Sie Klartext-Geheimnisse aus dem Workspace heraus, den der Agent sehen kann. Verwenden Sie einen Vault und injizieren Sie zur Laufzeit, schwärzen Sie sensible Werte in Logs und Ausgaben und lassen Sie niemals Zugangsdatendateien dort, wo Cursors Indizierung sie erreichen kann. Wenn ein Geheimnis jemals in einem Protokoll, einer generierten Datei oder einem Commit erscheint, rotieren Sie es sofort und untersuchen Sie, wie es dorthin gelangt ist.

8. Riskante Arbeit in isolierten Umgebungen mit geringsten Rechten ausführen. Verwenden Sie Container oder Sandbox-VMs für KI-gestützte Arbeit an nicht vertrauenswürdigem Code, führen Sie Cursor ohne erhöhte Rechte aus und blockieren Sie nicht genehmigte ausgehende Verbindungen, damit eine kompromittierte Sitzung nicht exfiltrieren kann. Segmentieren Sie Umgebungen nach Sensibilität, sodass risikoreiche Arbeit eingegrenzt ist und der Wirkungsradius jeder einzelnen Kompromittierung klein bleibt.

9. Richtlinien nach Repository- und Umgebungssensibilität festlegen. Klassifizieren Sie Repositories (öffentlich, intern, reguliert, Produktion) und wenden Sie strengere Kontrollen auf die sensiblen an: Privacy Mode aktiviert, Indizierung begrenzt, Egress eingeschränkt, stärkere Prüfung verlangt. Verwenden Sie Cursor für kritische Systeme nur in Umgebungen ohne direkten Pfad zu Produktions-Zugangsdaten und dokumentieren Sie die Richtlinie, damit Entwickler wissen, wo KI-Hilfe erlaubt ist und unter welchen Einschränkungen.

Wo native Kontrollen aufhören: den Agenten zum Zeitpunkt des Prompts absichern

Gehen Sie die Risiken noch einmal durch, und ein Muster zeigt sich. Workspace Trust, Privacy Mode, .cursorignore und SAST wirken alle auf das, was der Editor bereits zu tun beschlossen hat, oder auf Code, den er bereits geschrieben hat. Sie scharen sich um den Pull Request, weil dort AppSec schon immer gelebt hat. Aber der PR war nur deshalb überhaupt ein Kontrollpunkt, weil ein Mensch ihn las, und im Agententakt liest ihn niemand mehr von Anfang bis Ende.

Der Ort, an dem eine Regel durchzusetzen ist, ist nicht mehr das Diff; es ist der Prompt, bevor die unsichere Zeile geschrieben wird. Welche Regel Cursor auch befolgen soll, sie muss in seinen Händen sein in dem Moment, in dem es schreibt, nicht in einem Scanner warten, der eintrifft, sobald der Code auf der Festplatte liegt und der Agent zur nächsten Aufgabe weitergezogen ist.

Das ist die Ebene, die VibeDefend hinzufügt. Es ist eine kostenlose npm-CLI, die in etwa fünf Sekunden installiert ist und Cursor (plus Claude Code, OpenAI Codex, Windsurf und VS Code Copilot) in vier Governance-Ebenen verdrahtet, die innerhalb der Agentenschleife laufen.

Business Rules Die Konventionen in Ihrem Repo, die nie aufgeschrieben wurden (Decimal128 für Geld verwenden, Autorisierung läuft über requireOwner). VibeDefend fördert sie aus der Art und Weise zutage, wie Ihr Team bereits codet, und lädt sie vor jeder Bearbeitung in Cursors Kontext. Security Rules OWASP Top 10, SOC 2, DSGVO und ISO 27001, geladen am Tag der Installation. Der Agent liest die zutreffende Erinnerung, bevor er schreibt, sodass die Framework-Anforderung Teil des Codes wird statt einer Checkbox zum Audit-Zeitpunkt. Action Guard Destruktive Aufrufe (ein sudo rm -rf, ein roher Lesezugriff auf eine geheimnisartige Umgebungsvariable, ein ad-hoc psql gegen einen Produktionshost) werden abgefangen, bevor sie ausgelöst werden. Pro Regel warnen oder blockieren, mit jedem Abfangen im Audit-Trail. Live Findings Jedes Ergebnis aus CybeDefends Scannern (SAST mit Erreichbarkeit, SCA, Secrets, IaC und CI/CD) ist live in Cursors Kontext, sodass es nicht nur sicheren Code schreibt, sondern die Schwachstellen triagiert und behebt, die Sie bereits haben.

Entscheidend ist: Nichts über Ihren Code geht über die Leitung. Entscheidungen geschehen lokal neben dem Agenten; nur strukturierte Governance-Metadaten (die ausgelöste Regel, der Dateipfad, die Schwere, ein Zeitstempel) erreichen das Backend. EU- und US-Mandanten sind physisch getrennt, und Sie wählen die Region zum Installationszeitpunkt. Dieses Datenschutzmodell ist es, was eine Kontrolle so nah am Code sitzen lässt, ohne selbst zu einem Datenexfiltrationsrisiko zu werden, dieselbe Sorge, die Cursors eigenen Privacy Mode zu einem Kompromiss macht.

Dies ist kein Ersatz für die obigen Praktiken. Es ist die fehlende Ebene, die sie als gegeben annehmen: diejenige, die Ihre Regeln zum Zeitpunkt des Prompts in Cursors Hände legt, sodass die unsichere Zeile umgeschrieben wird, bevor sie überhaupt vorgeschlagen wird, statt drei Stufen später von einem Scanner erfasst zu werden, der ein Diff liest, das niemand Zeit hatte zu lesen. Workspace Trust hindert den Editor daran, das zu tun, was er nicht tun darf; VibeDefend formt, was er überhaupt erst schreibt.

Häufig gestellte Fragen

Ist Cursor sicher?

Cursor ist sicher zu verwenden, wenn es konfiguriert und eingegrenzt ist, und riskant, wenn es das nicht ist. Seine SOC 2 Type II-Konformität, Privacy Mode, .cursorignore und Workspace Trust verhindern eine echte Klasse von Datenlecks und Unfällen. Das Restrisiko stammt aus den Standardwerten (Workspace Trust historisch deaktiviert, breite Indizierung), aus dem Code, den es generiert (nur ein kleiner Bruchteil ist ab Werk sicher), aus den Eingaben (Prompt Injection, vergiftete Regeldateien, bösartige MCP-Server) und aus der umgebenden Umgebung (offengelegte Geheimnisse, nicht vertrauenswürdige Repos). Behandeln Sie es als mächtigen Agenten, der Trust-Gating, den Ausschluss von Geheimnissen, menschliche Prüfung und SAST benötigt, nicht als ein Tool, das standardmäßig sicher ist.

Sendet Cursor meinen Code in die Cloud?

Ja. Cursors KI-Funktionen senden Code an eine externe API, um Antworten zu generieren, was Dateiinhalte und den umgebenden Kontext Ihrer Aufgabe umfassen kann. Privacy Mode ändert, was mit diesem Code auf Cursors Seite geschieht: Mit aktiviertem Modus wird Ihr Code nicht gespeichert oder zum Trainieren von Modellen verwendet. Halten Sie für sensible Geschäftslogik Privacy Mode aktiviert, schließen Sie Geheimnisse und regulierte Daten mit .cursorignore vom Kontext aus und prüfen Sie Cursors Datenverarbeitungsrichtlinie unter cursor.com/security gegen Ihre eigenen Anforderungen.

Was ist .cursorignore und warum ist es wichtig?

.cursorignore ist eine Datei (im Geiste ähnlich .gitignore), die Cursor mitteilt, welche Pfade vom Kontext der KI und von der Codebasis-Indizierung auszuschließen sind. Es ist wichtig, weil standardmäßig alles, was im Workspace geöffnet ist, in den Kontext des Modells gezogen werden kann, einschließlich .env-Dateien, Konfigurationen und Verbindungszeichenfolgen. Eine gut gepflegte .cursorignore ist der primäre Hebel, der Geheimnisse und sensible Module aus der Reichweite des Modells hält. Eine veraltete ist die häufigste Art, wie eine Zugangsdatenangabe in einer KI-Anfrage landet.

Sollte ich Workspace Trust in Cursor aktivieren?

Ja. Workspace Trust stellt die code-ausführenden Funktionen eines geöffneten Ordners hinter eine explizite Vertrauensentscheidung. Es ist die direkte Gegenmaßnahme für den Fehler vom September 2025, bei dem ein präpariertes Repository eine Aufgabe automatisch ausführen und Code in dem Moment ausführen konnte, in dem Sie den Ordner öffneten. Da Cursor historisch mit standardmäßig deaktiviertem Workspace Trust ausgeliefert wurde, sollte seine Aktivierung ein Standardteil Ihrer Einrichtung sein. Kombinieren Sie es damit, nicht vertrauenswürdige Repositories zuerst in einer Sandbox oder einem anderen Editor zu öffnen.

Kann Cursor Code aus einem Repository automatisch ausführen?

Es kann, wenn Workspace Trust deaktiviert ist. Als VS-Code-Fork ehrt Cursor Aufgaben, die mit runOn: folderOpen konfiguriert sind, sodass eine bösartige .vscode/tasks.json in einem Repository, das Sie klonen und öffnen, sofort ausgeführt werden kann, ohne Prompt, in Ihrem Benutzerkontext. Dies war die Grundlage des im September 2025 gemeldeten Stille-Code-Ausführungs-Fehlers. Die Aktivierung von Workspace Trust schließt die Lücke, aber das Standardverhalten ist der Grund, warum Sie niemals ein nicht vertrauenswürdiges Projekt in Ihrer primären Cursor-Instanz öffnen sollten.

Macht Cursors Privacy Mode es sicher?

Nein, und es ist wichtig, hier präzise zu sein. Privacy Mode ist eine Datenkontrolle: Er stellt sicher, dass Ihr Code nicht auf Cursors Servern gespeichert oder zum Training verwendet wird. Er sagt nichts über die Sicherheit des Codes aus, den Cursor generiert, ob ein Repo eine Aufgabe automatisch ausführen kann, ob eine Prompt Injection den Agenten lenken kann oder ob ein MCP-Server bösartig ist. Privacy Mode schützt Ihre Daten; er schützt nicht Ihre Anwendung. Sie benötigen weiterhin Workspace Trust, .cursorignore, SAST, menschliche Prüfung und eine Kontrolle zum Zeitpunkt des Prompts.

Wie unterscheidet sich die Cursor-Sicherheit von Claude Code, GitHub Copilot oder Codex?

Die Grundlagen sind gemeinsam (geringste Rechte, Ausschluss von Geheimnissen, menschliche Prüfung, Abhängigkeitsscans), aber die Angriffsflächen unterscheiden sich. Cursors charakteristische Probleme sind der standardmäßig deaktiviert ausgelieferte Workspace Trust und eine hohe Rate unsicheren generierten Codes; Claude Codes ist die tiefe MCP- und Shell-Integration; GitHub Copilots sind unsichere Vorschläge und Geheimnis-Lecks im großen Maßstab; Codex sind Befehls-Injection- und Lieferketten-Vorfälle. Wir behandeln jeden Agenten in einem eigenen Leitfaden: Claude Code, GitHub Copilot und OpenAI Codex.