Ist Windsurf sicher? Risiken, Kontrollen und Best Practices

Was sich 2026 geändert hat. Am 2. Juni 2026 hat Cognition, das Unternehmen hinter Devin, Windsurf in Devin Desktop umbenannt und Devin Local als Nachfolger von Cascade vorgestellt. Version 3.9.19 vom 8. September 2026 hat den Wechsel abgeschlossen: Cascade wurde entfernt, Devin Local ist jetzt der einzige Agent im Editor. windsurf.com leitet auf devin.ai weiter. Weil fast alle weiterhin nach "Windsurf" suchen, behält dieser Leitfaden den Namen; wo sich eine Kontrolle mit dem Agenten geändert hat, beschreibt er die aktuelle.

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

Windsurf ist ein KI-nativer Code-Editor, gebaut um einen Agenten (erst Cascade, heute Devin Local), der nicht nur eine Zeile vervollständigt, sondern eine Aufgabe ausführt. Sie beschreiben die Absicht in natürlicher Sprache (baue dieses Feature, behebe diesen fehlschlagenden Test, refaktoriere über diese Module) und der Agent indiziert das Repository für Kontext, bearbeitet mehrere Dateien in einem einzigen Lauf, führt Terminal-Befehle aus und erweitert sich über das Model Context Protocol (MCP), um die Systeme zu erreichen, mit denen Ihr Code spricht. Es ist Teil der breiteren Bewegung hin zur Sicherheit von KI-Coding-Agenten als Disziplin, weil der Editor jetzt ein Akteur ist, kein Assistent.

Diese Kombination ist es, die das alte Sicherheitsmodell zerbricht. Ein klassischer IDE-Assistent bot eine Vervollständigung an; ein Mensch las sie und entschied, sie anzunehmen oder abzulehnen. Der Wirkungsradius eines schlechten Vorschlags war ein Codeblock, den ein Entwickler trotzdem noch einfügen musste. Der Agent dagegen handelt. Er liest Dateien, die Sie nie genannt haben, führt Befehle aus, die Sie nie getippt haben, schreibt Code im gesamten Baum um und ruft MCP-Tools auf, die Sie vor Wochen eingerichtet und vergessen haben. Die Angriffsfläche ist nicht mehr "was hat das Modell vorgeschlagen". Sie ist "was kann dieser Agent mit dem Zugriff anstellen, den er hat, welchen Code kann er in Masse 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. Der Agent 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 stillschweigend 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. Dieselbe Dynamik zeigt sich in Cursor und Claude Code; Windsurfs Besonderheit ist, wie stark sich sein Agent für seine Arbeit auf MCP stützt.

Für die meisten Teams lautet die praktische Frage nicht, ob Windsurf eingebaute 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. Die Kontrollen von Windsurf 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 Windsurf funktioniert

Das Modell von Windsurf baut auf drei Ideen auf: nachweisen, dass die Plattform mit Daten verantwortungsvoll umgeht, dem Entwickler Hebel geben, um sensiblen Code aus der Reichweite des Modells zu halten, und die Aktionen eingrenzen, die der Agent ausführen darf. In der Praxis zeigt sich das als eine Handvoll Kontrollen, und sie sind eine vernünftige Grundlage für einen Editor dieser Mächtigkeit.

Die Falle besteht darin, diese Liste als fertige Sicherheitsgrenze zu lesen. Zero Data Retention schützt Ihre Daten, sagt aber nichts über die Sicherheit des Codes, den der Agent schreibt. Eine Ignore-Datei funktioniert nur, wenn Sie sie pflegen. Berechtigungsregeln helfen nur, wenn Sie sie eng halten, und in dem Moment, in dem Sie ein breites Allow hinzufügen (oder den Agenten in den Bypass-Modus schalten, der jeden Aufruf freigibt), ist der Genehmigungsschritt, der sie sicher machte, weg. Compliance attestiert, wie Windsurf seinen Dienst betreibt, nicht, wie sicher sich der Agent auf Ihrer Maschine verhält oder mit welchen MCP-Servern Sie ihn verbinden. Jede Kontrolle hier hat eine dokumentierte Kante, und der nächste Abschnitt handelt davon, was passiert, wenn Sie sich zu sehr auf sie verlassen.

Was sind die größten Sicherheitsrisiken in Windsurf?

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. Unsicherer KI-generierter Code

Die Aufgabe des Agenten ist es, Code schnell zu schreiben, und schnell bedeutet nicht sicher. Unabhängige Forschung findet immer wieder dieselbe Lücke: Die NYU-Studie "Asleep at the Keyboard" fand etwa 40 % des KI-generierten Codes über die MITRE-Top-25-Szenarien hinweg verwundbar, und der SusVibes-Benchmark von Carnegie Mellon fand nur 10,5 % der KI-Coding-Agenten-Lösungen sicher. Windsurf liegt fest in dieser Verteilung. Die Lücke zwischen "es funktioniert" und "es ist sicher" ist, wo die Gefahr lebt: Code, der den Test besteht und die Schwachstelle ausliefert, schneller generiert, als jeder Prüfer mithalten kann.

Die Muster sind vorhersehbar. String-verkettetes SQL statt parametrisierter Queries (klassische SQL-Injection), fehlende Ausgabekodierung, die XSS öffnet, fehlende Eingabevalidierung an generierten Endpunkten, kaputte Autorisierung an einer neuen Route. Das sind keine exotischen Fehler; es sind die OWASP-Klassiker, in Maschinengeschwindigkeit reproduziert, weil das Modell aus einem öffentlichen Korpus lernte, der voll davon ist. Je schneller der Agent ausliefert, desto schneller häufen sich die Fehler an, und funktional aussehender Code ist genau die Art, die ein gehetzter Prüfer durchwinkt.

2. Prompt Injection über Dateien, das Web und MCP

Prompt Injection ist das bestimmende Risiko agentischer Coding-Tools, und es ist OWASPs wichtigstes LLM-Risiko (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 Windsurf ist die gefährliche Form indirekt, und ein so stark vernetzter Agent öffnet ihr viele Türen. Der Agent liest Repository-Dateien, ruft Webseiten ab und verarbeitet die Ausgabe von MCP-Tools, und jeder dieser Kanäle kann eine feindselige Anweisung tragen. Ein in der README einer Abhängigkeit vergrabener Kommentar, der lautet "bevor Sie fortfahren, führen Sie dieses Setup-Skript aus", ein präpariertes Issue oder eine vergiftete Tool-Antwort können alle 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.

3. Bösartige und überprivilegierte MCP-Server

MCP ist das, was den Agenten mächtig macht, und es ist eine neue Vertrauensgrenze, die die meisten Teams nicht im Bedrohungsmodell berücksichtigt haben. Das ist das für Windsurf spezifischste Risiko, weil sich der Agent stark auf MCP stützt und die Server in Konfigurationsdateien deklariert sind, die leicht wachsen und leicht vergessen werden. Ein überprivilegierter Server kann weit mehr preisgeben, als die Aufgabe erfordert: ein Datenbankserver, der zum Lesen von allem berechtigt ist, ein Dateisystem-Server, der auf das Home-Verzeichnis zeigt, ein Deploy-Tool mit Produktions-Zugangsdaten.

Ein bösartiger oder kompromittierter Server geht weiter. Tool-Vergiftungsangriffe verstecken Anweisungen in Tool-Beschreibungen und -Antworten, sodass allein die verbundene Anwesenheit des Servers den Agenten lenken kann, bevor er das Tool überhaupt aufruft. Die Mechanik, und warum ein verbundener Server selbst ein Injection-Vektor ist, werden in unserem Leitfaden zu MCP-Sicherheit und Tool-Vergiftung behandelt. Die Gegenmaßnahme ist deutlich und richtig: Verwenden Sie Server, die Sie geschrieben haben oder denen Sie wirklich vertrauen, begrenzen Sie jeden auf die engsten Daten und Aktionen, die er benötigt, und behandeln Sie alles, was ein Server zurückgibt, als nicht vertrauenswürdige Eingabe, die zu validieren ist, nicht als Evangelium, auf das das Modell handeln kann.

4. Lieferkette und typosquattete MCP-Pakete

Der Agent installiert Pakete, klont Repositories und verdrahtet Tools als Teil der normalen Arbeit. Wenn er eine kompromittierte Bibliothek einzieht oder einen feindseligen MCP-Server verbindet, 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 bösartige MCP-Server und zielte gezielt auf KI-Coding-Assistenten ab, darunter Windsurf, Cursor und Claude Code.

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. Eine vergiftete package.json, ein bösartiger Post-Install-Hook oder ein typosquattetes MCP-Paket kann einen routinemäßigen "richte dieses Repo ein"-Prompt in Diebstahl von Zugangsdaten verwandeln.

5. Offenlegung von Geheimnissen und sensiblem Kontext

Windsurf ist nützlich, weil sein Agent Kontext hat, und dieser Kontext umfasst routinemäßig mehr als nur Quellcode. Alles, was im Workspace erreichbar ist, eine .env-Datei, eine Konfiguration mit Verbindungsstrings, interne API-Endpunkte, kann in den Kontext des Modells gezogen werden, sofern Sie es nicht ausdrücklich mit einer Ignore-Datei ausschließen. Windsurfs KI-Funktionen senden Code auch an eine externe API, um Antworten zu generieren, sodass für sensible Geschäftslogik die Frage, wohin dieser Verkehr geht, real ist, und Zero Data Retention ist zusammen mit dem Trainings-Opt-out der Hebel, mit dem Sie ihn steuern.

Die Offenlegung ist oft indirekt. Während der Agent ein Repository zusammenfasst oder einen Fehler debuggt, kann er ein Token, eine Zugangsdatei oder einen internen Hostnamen in eine Ausgabe fördern, die dann in einem Chat, einem Ticket oder einer committeten Datei landet, wo sie noch lange nach dem Ende der Sitzung lebt. Die Standardhaltung ist Bequemlichkeit, und Bequemlichkeit bedeutet breiten Zugriff, sofern Sie ihn nicht von Hand einengen.

6. Befehlsausführung und automatische Freigabemodi

Der Agent führt Shell-Befehle aus und verändert Systeme, sodass ein manipulierter Agent schädliche ausführen kann. Berechtigungsregeln und der Genehmigungs-Prompt pro Befehl sind die Kontrollen, die das sicher halten, und sie erodieren auf zwei vertraute Arten. Die erste ist Genehmigungsmüdigkeit: Wenn der Agent dutzendmal pro Stunde fragt, hören die Leute auf zu lesen und fangen an, "immer erlauben" zu klicken, und innerhalb einer Woche ist der sorgfältige Standardwert leise zu einer pauschalen Freigabe geworden. Die zweite ist der Bypass-Modus (zu Cascade-Zeiten Turbo), in dem der Agent jeden Aufruf ausführt, ohne für eine Genehmigung innezuhalten, und so den einzelnen Schritt entfernt, der zwischen einer injizierten Anweisung und einem destruktiven Befehl steht.

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 Befehls-Gating, geringste Rechte und isolierte Umgebungen wichtig, und genau deshalb ist die zu fürchtende Kombination die häufige: ein nicht vertrauenswürdiges Repo oder ein MCP-Server, ein freizügiges Setup zur Vermeidung von Reibung und eine injizierte Anweisung, die der Agent als legitim behandelt.

Was deckt die eingebaute Sicherheit von Windsurf ab 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. Die eingebauten Kontrollen von Windsurf sind in Richtung Datenschutz und Anbieter-Compliance gewichtet, wo die ersten Fragen eines Käufers landen. Sie wurden nie entworfen, um einen entschlossenen Gegner zu stoppen, der die Eingaben des Agenten kontrolliert (eine Datei, eine Webseite, ein MCP-Tool), und sie sagen fast nichts über die Sicherheit des Codes, den der Agent schreibt. Alles, was "Windsurf ist installiert" in "Windsurf wird gesteuert" verwandelt, liegt in den folgenden Praktiken.

Ist Windsurf im Unternehmen sicher zu verwenden?

Windsurf ist sicher im Unternehmen einzusetzen, wenn es konfiguriert und eingegrenzt ist, und riskant, wenn es das nicht ist. Seine SOC-2- und FedRAMP-Attestierung, Zero Data Retention und die Ignore-Dateien nehmen die Beschaffungshürde und verhindern eine echte Klasse von Datenlecks. Das Restrisiko lebt im Verhalten des Agenten, nicht in der Compliance des Anbieters.

Für eine regulierte Organisation beantwortet die Compliance-Geschichte die Anbieter-Risikofrage (wie Windsurf Daten auf seiner Seite verarbeitet), lässt aber die Anwendungs-Risikofrage offen (was der Agent schreibt, was er ausführt und mit welchen MCP-Servern er spricht). Das sind getrennte Probleme, und eine Attestierung schließt das zweite nicht. Eine praktische Unternehmenseinführung behandelt Windsurf als mächtigen Agenten, der Leitplanken braucht: Zero Data Retention und Trainings-Opt-out für sensible Repositories geprüft, .devinignore als Sicherheitsartefakt gepflegt, enge Berechtigungsregeln auf Team-Ebene (sie haben Vorrang vor jeder Nutzer- oder Projektregel), eine geprüfte und inventarisierte Menge von MCP-Servern, isolierte Umgebungen für nicht vertrauenswürdige Arbeit und obligatorische menschliche Prüfung plus SAST für alles, was der Agent produziert. Das Compliance-Abzeichen bringt Sie durch die Tür; die Governance ist, was verhindert, dass die Tür zum Schwachpunkt wird.

Wie sichert man MCP-Server in Windsurf ab?

Behandeln Sie jeden MCP-Server als Vertrauensgrenze, nicht als Bequemlichkeit. Verwenden Sie Server, die Sie geschrieben haben oder die von Anbietern stammen, denen Sie wirklich vertrauen, begrenzen Sie jeden auf die engsten Daten und Aktionen, die er benötigt, und validieren Sie alles, was ein Server zurückgibt, statt den Agenten direkt darauf handeln zu lassen. Die MCP-Konfigurationsdatei ist ein Sicherheitsartefakt und verdient dieselbe Prüfdisziplin wie die Zugriffskontrolle.

Konkret: Prüfen Sie die MCP-Konfiguration so, wie Sie IAM prüfen. Führen Sie ein Inventar jedes verbundenen Servers, damit sich kein bösartiges oder typosquattetes Paket (wie die "SANDWORM_MODE"-Server) unbemerkt einschleicht, und entfernen Sie Server, die nicht mehr verwendet werden. In den Plänen Teams und Enterprise blockiert eine MCP-Allowlist jeden Server, der nicht darauf steht. Verbinden Sie niemals einen Server mit Produktions-Zugangsdaten mit einer Umgebung, die auch nicht vertrauenswürdigen Code ausführt, weil eine einzige Tool-Vergiftungs-Nutzlast diese Verbindung in Exfiltration verwandeln kann. Begrenzen Sie Datenbankserver auf schreibgeschützt und auf die spezifischen Tabellen, die eine Aufgabe benötigt; richten Sie Dateisystem-Server auf ein Projektverzeichnis, niemals den Home-Ordner; und geben Sie Deploy-Tools kurzlebige, eng begrenzte Token statt dauerhafter Produktionsschlüssel. Da eine vergiftete Tool-Beschreibung von Natur aus Prompt Injection ist, ist die Verbindung selbst Teil Ihrer Angriffsfläche, noch bevor ein Tool aufgerufen wird, weshalb eine unabhängige Kontrolle zum Zeitpunkt des Prompts, die eine gefährliche Aktion blockieren kann, wichtig ist, selbst wenn jeder Server legitim aussieht.

Was sind die Best Practices zur sicheren Nutzung von Windsurf?

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. Zero Data Retention für sensible Arbeit prüfen und den Tradeoff verantworten. Seit dem Wechsel zu Devin dürfen Ihre Daten zum Training verwendet werden, solange ein bezahlter Plan nicht auf der Seite Data Controls widerspricht (bei Teams erledigt das ein Admin). Behandeln Sie den Widerspruch als Standard für jedes Repository mit echter Geschäftslogik, regulierten Daten oder proprietärem Code. Wo ein Team davon abweicht, machen Sie das zu einer expliziten, dokumentierten Entscheidung, begrenzt auf Arbeit geringer Sensibilität, nicht zu einem stillen Standard, den niemand geprüft hat.

2. .devinignore wie ein Sicherheitsartefakt kuratieren. Schließen Sie .env-Dateien, Zugangsdatenspeicher, Infrastrukturkonfiguration, Verbindungsstrings und jedes sensible Modul sowohl von der Indizierung als auch von der Reichweite des Agenten aus, und ergänzen Sie eine Deny-Regel Read(**/.env*): Bei aktiver Sandbox verbirgt sie diese Pfade auch vor Shell-Befehlen. Prüfen Sie es so, wie Sie die Zugriffskontrolle prüfen: planmäßig, nach jedem neuen Geheimnis oder Dienst und als Teil des Onboardings eines neuen Repos. Eine veraltete Ignore-Datei ist der häufigste Weg, auf dem ein Geheimnis im Kontext eines Modells landet.

3. Berechtigungsregeln eng halten und der automatischen Freigabe widerstehen. Setzen Sie Deny-Regeln für destruktive und zugangsdatenberührende Befehle (ein Deny gewinnt immer), lassen Sie Ask auf allem, was echte Daten erreicht, und bleiben Sie in jeder Umgebung mit Zugriff auf echte Daten oder Produktionshosts aus dem Bypass-Modus heraus. Bypass entfernt den einen Genehmigungsschritt, der zwischen einer injizierten Anweisung und einem destruktiven Befehl steht.

4. Jeden MCP-Server vetten und inventarisieren. Verbinden Sie nur Server, die Sie geschrieben haben oder denen Sie wirklich vertrauen, begrenzen Sie jeden auf die engsten Daten und Aktionen, die er benötigt, führen Sie ein Inventar in der MCP-Konfiguration und verdrahten Sie niemals einen Server mit Produktions-Zugangsdaten in eine Umgebung, die nicht vertrauenswürdigen Code ausführt. Behandeln Sie Tool-Beschreibungen und -Antworten als nicht vertrauenswürdige Eingabe.

5. Einen Menschen in der Schleife für generierten Code behalten. Behandeln Sie die Ausgabe des Agenten als Entwurf, nicht als finale 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-Queries und privilegierten Pfaden. Ein Agent, der tausende Zeilen pro Tag produziert, erzeugt subtile Fehler schneller, als sie von selbst auftauchen.

6. KI-generierten Code mit SAST in der CI scannen. Da nur ein 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, fehlende Autorisierung) und speisen Sie Ergebnisse zurück, damit dieselben Klassen aufhören wiederzukehren. Funktionale Tests werden einen verwundbaren-aber-funktionierenden Endpunkt nicht abfangen; nur eine sicherheitsbewusste Prüfung tut das.

7. Abhängigkeiten und Pakete 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. Lassen Sie den Agenten keine obskuren Pakete automatisch installieren, so selbstbewusst er sie auch vorschlägt, und verifizieren Sie, dass ein vorgeschlagenes Paket tatsächlich existiert, bevor es hinzugefügt wird.

8. 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 die Indizierung sie erreichen kann. Wenn ein Geheimnis jemals in einem Protokoll, einer generierten Datei oder einem Commit auftaucht, rotieren Sie es sofort und untersuchen Sie, wie es dorthin gelangt ist.

9. Riskante Arbeit in isolierten Umgebungen mit geringsten Rechten ausführen und Richtlinien nach Sensibilität festlegen. Verwenden Sie Container oder Sandbox-VMs für KI-gestützte Arbeit an nicht vertrauenswürdigem Code, führen Sie Windsurf ohne erhöhte Rechte aus und blockieren Sie nicht genehmigte ausgehende Verbindungen, damit eine kompromittierte Sitzung nicht exfiltrieren kann. Die Sandbox von Devin Local begrenzt auf Betriebssystemebene, welche Dateien und Domains seine Befehle erreichen, und Enterprise-Admins können sie erzwingen. Klassifizieren Sie Repositories (öffentlich, intern, reguliert, Produktion) und wenden Sie strengere Kontrollen auf die sensiblen an, wobei kritische Systeme von jedem direkten Pfad zu Produktions-Zugangsdaten ferngehalten werden.

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

Gehen Sie die Risiken noch einmal durch, und ein Muster zeigt sich. Zero Data Retention, die Ignore-Datei, Berechtigungsregeln und SAST wirken alle auf das, was der Agent 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 der Agent auch befolgen soll, sie muss in seinen Händen sein in dem Moment, in dem er 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 mit einem einzigen Befehl installiert ist und Windsurf (plus Claude Code, Cursor, OpenAI Codex und VS Code Copilot) in vier Governance-Ebenen verdrahtet, die innerhalb der Agentenschleife laufen.

Die vier Ebenen behandeln unterschiedliche Fehlermodi. Business Rules sind 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 den Kontext des Agenten. Security Rules bringen OWASP Top 10, SOC 2, DSGVO und ISO 27001 in den Code, während er geschrieben wird, sodass die Framework-Anforderung Teil des Codes wird statt einer Checkbox zum Audit-Zeitpunkt. Action Guard läuft in Windsurf über die Hooks des Editors, die Schreib- und Lesezugriffe auf Dateien sowie Shell-Befehle abdecken: VibeDefend stellt die Regeln vor jeder Bearbeitung bereit, und der Guard kann einen Schreibvorgang, der gegen eine Regel verstößt, stoppen, bevor er auf der Platte landet, ebenso einen rohen Lesezugriff auf eine .env-Datei oder ein sudo rm -rf oder ad-hoc psql gegen einen Produktionshost vor der Ausführung. Je nach Regel warnt oder blockiert er, und jedes Abfangen steht im Audit-Trail. Für Web-Abrufe hat Windsurf keinen Hook, und MCP-Tool-Aufrufe filtert es nicht: Dafür bittet ein Snippet in .windsurfrules den Agenten, vorher zu prüfen, was hält, solange das Modell seiner Regeldatei folgt. Live Findings verdrahtet den Agenten in CybeDefends Plattform für Code-Sicherheit, seinen Scannern (SAST mit Erreichbarkeit, SCA, Secrets, IaC und CI/CD), die kontinuierlich laufen, sodass der Agent nicht nur sicheren Code schreibt, sondern die Schwachstellen triagiert und behebt, die Sie bereits haben. Und wohin Ihr Code geht: Die Action Guards entscheiden auf Ihrem Laptop, bevor eine Aktion ausgeführt wird. Um die Regeln bereitzustellen, die zur gerade geschriebenen Zeile passen, sendet VibeDefend einen kurzen Ausschnitt dieses Codes an das CybeDefend-Backend, und der Scan vor dem Commit sendet die geänderten Dateien, beides in die EU- oder US-Region, die Sie bei der Installation wählen. Die beiden Regionen sind physisch getrennt, und Ihr Code wird nie zum Training eines Modells verwendet.

Häufig gestellte Fragen

Ist Windsurf sicher?

Windsurf ist sicher zu verwenden, wenn es konfiguriert und eingegrenzt ist, und riskant, wenn es das nicht ist. Seine SOC-2- und FedRAMP-Attestierung, Zero Data Retention, Ignore-Dateien und Berechtigungsregeln verhindern eine echte Klasse von Datenlecks und Unfällen. Das Restrisiko stammt aus dem Code, den der Agent generiert (nur ein Bruchteil ist ab Werk sicher), aus den Eingaben (Prompt Injection in Dateien, Webseiten und MCP-Tool-Ausgaben), aus den MCP-Servern, die Sie verbinden, und aus der umgebenden Umgebung (offengelegte Geheimnisse, nicht vertrauenswürdige Repos, automatische Freigabemodi). Behandeln Sie es als mächtigen Agenten, der das Ausschließen von Geheimnissen, Befehls-Gating, Server-Prüfung, menschliche Prüfung und SAST benötigt, nicht als ein Tool, das ab Werk sicher ist.

Sendet Windsurf meinen Code in die Cloud?

Ja. Windsurfs KI-Funktionen senden Code an eine externe API, um Antworten zu generieren, was Dateiinhalte und den umgebenden Kontext Ihrer Aufgabe umfassen kann. Was danach geschieht, hängt von Ihrem Plan ab. Windsurf hielt Code in Teams und Enterprise standardmäßig von seinen Servern fern; seit dem Wechsel zu Devin sagt Cognition, dass Ihre Daten zum Training verwendet werden dürfen, solange ein bezahlter Plan nicht auf der Seite Data Controls widerspricht, was auch Zero Data Retention bei den Modellanbietern aktiviert, und Enterprise-Daten werden ohne schriftliche Zustimmung nie zum Training verwendet. Prüfen Sie für sensible Geschäftslogik diesen Widerspruch, schließen Sie Geheimnisse und regulierte Daten mit .devinignore vom Kontext aus und prüfen Sie die Datenverarbeitungsrichtlinie von Cognition gegen Ihre eigenen Anforderungen. Auch eine Governance-Ebene wie VibeDefend sendet Code, nämlich einen kurzen Ausschnitt, um die Regeln bereitzustellen, und die geänderten Dateien für den Scan vor dem Commit. Beides geht in die EU- oder US-Region, die Sie bei der Installation wählen, und wird nie zum Training eines Modells verwendet.

Was ist Windsurf Cascade, und ist es ein Sicherheitsrisiko?

Cascade war der Agent von Windsurf: Er las das Repository, bearbeitete mehrere Dateien, führte Terminal-Befehle aus und rief MCP-Tools auf, um eine in natürlicher Sprache beschriebene Aufgabe zu erledigen. Seit dem 8. September 2026 ist er aus dem Editor, heute Devin Desktop, verschwunden; an seine Stelle trat Devin Local, der dieselbe Arbeit unter Allow-, Ask- und Deny-Regeln erledigt. Keiner von beiden ist an sich ein Risiko, aber beide verändern das Risikomodell, weil sie handeln, statt Vorschläge anzubieten, die ein Mensch annimmt. Die Sicherheitsfragen lauten dann, was der Agent ausführen kann, welchen Code er generiert und wer seine Anweisungen beeinflussen kann. Halten Sie seine Berechtigungsregeln eng, seine MCP-Server geprüft, seinen Kontext frei von Geheimnissen und seine Ausgabe unter menschlicher Prüfung und SAST.

Wie sichere ich MCP-Server in Windsurf ab?

Behandeln Sie jeden MCP-Server als Vertrauensgrenze. Verwenden Sie Server, die Sie geschrieben haben oder die von Anbietern stammen, denen Sie wirklich vertrauen, begrenzen Sie jeden auf die engsten Daten und Aktionen, die er benötigt, und validieren Sie alles, was ein Server zurückgibt, statt den Agenten direkt darauf handeln zu lassen. Führen Sie ein Inventar in der MCP-Konfiguration, damit sich kein bösartiges oder typosquattetes Paket unbemerkt einschleicht, verbinden Sie niemals einen Server mit Produktions-Zugangsdaten mit einer Umgebung, die nicht vertrauenswürdigen Code ausführt, und denken Sie daran, dass eine vergiftete Tool-Beschreibung von Natur aus Prompt Injection ist, sodass die Verbindung Teil Ihrer Angriffsfläche ist, noch bevor ein Tool aufgerufen wird.

Kann Windsurf Befehle oder Code automatisch ausführen?

Standardmäßig fragt der Agent nach, bevor er einen Shell-Befehl ausführt oder eine Datei schreibt, und Allow-Regeln lassen ausgewählte Befehle ohne Prompt durch. Das Risiko entsteht, wenn dieser Genehmigungsschritt entfernt wird, entweder durch Genehmigungsmüdigkeit (das Klicken auf "immer erlauben", bis der Standard zu einer pauschalen Freigabe wird) oder durch den Wechsel in den Bypass-Modus, in dem der Agent jeden Aufruf ausführt, ohne innezuhalten (bei Cascade hieß das Turbo). Halten Sie die Regeln eng, verweigern Sie destruktive und zugangsdatenberührende Befehle und halten Sie Bypass in jeder Umgebung mit Zugriff auf echte Daten oder Produktionshosts aus.

Reicht Zero Data Retention, damit Windsurf sicher ist?

Nein, und es ist wichtig, präzise zu sein. Zero Data Retention ist eine Datenkontrolle: Sie begrenzt, wo Ihr Code gespeichert wird und ob er zum Training dient. Sie sagt nichts über die Sicherheit des Codes, den der Agent generiert, ob eine Prompt Injection den Agenten lenken kann oder ob ein MCP-Server bösartig ist. Zero Data Retention schützt Ihre Daten; sie schützt nicht Ihre Anwendung. Sie benötigen weiterhin .devinignore, enge Berechtigungsregeln, geprüfte MCP-Server, SAST, menschliche Prüfung und eine Kontrolle zum Zeitpunkt des Prompts.

Wie unterscheidet sich die Windsurf-Sicherheit von Cursor oder Claude Code?

Die Grundlagen sind gemeinsam (geringste Rechte, Ausschließen von Geheimnissen, menschliche Prüfung, Abhängigkeitsscans), aber die Flächen unterscheiden sich. Windsurfs charakteristische Fläche ist, wie stark sich sein Agent auf MCP stützt, was die MCP-Konfiguration und die Tool-Vergiftung zum zuerst zu modellierenden Risiko macht; Cursor lieferte Workspace Trust standardmäßig deaktiviert aus und generiert eine hohe Rate an unsicherem Code; Claude Code hat eine tiefe MCP- und Shell-Integration mit gestuften Berechtigungen. Alle drei teilen dieselbe Lücke: Eingebaute Kontrollen scharen sich um den Pull Request, während die Regel den Agenten zum Zeitpunkt des Prompts erreichen muss. Die gemeinsame Lösung ist eine Governance-Ebene zum Zeitpunkt des Prompts wie VibeDefend, oder buchen Sie eine Sitzung, um es an Ihrem eigenen Repo zu sehen.