AIREITEREin Worker kann hinter Ihrer Firewall laufen und trotzdem Quellcode-Fragmente, Terminalausgaben, Diffs und Screenshots an Cursor senden. Cursor Self-Hosted Machines hosten die Ausführung selbst – nicht den Agenten und auch keine vollständig vom Netz getrennte Cursor-Installation.
Diese Analyse zeigt, welche Daten die Grenze tatsächlich überschreiten und was die einzelnen Kontrollen bewirken. Grundlage sind Cursors Ankündigung vom 2. September 2026, die Dokumentation zu Self-Hosted Machines und die Richtlinie zur Datennutzung.
Die Datenschutzgrenze auf einen Blick
Cursor teilt einen Cloud-Agent-Lauf zwischen seiner Cloud und einem von Ihnen verwalteten Worker auf. „Self-hosted“ beschreibt dabei den Ort der Ausführung – nicht automatisch jedes beteiligte System und jeden Datenpfad.
| Daten oder System | Wo es ausgeführt wird oder bleibt | Kann es Cursor erreichen? | Relevante Kontrolle oder Einschränkung |
|---|---|---|---|
| Agentenschleife, Inferenz und Planung | Cursor-Cloud | Bereits bei Cursor | Wird durch Self-Hosted Machines nicht verlagert. |
| Dateiänderungen und Terminalbefehle | Ihr Worker | Ergebnisse können zurückgesendet werden | Der Worker führt die Werkzeuge aus. |
| Vollständiger Checkout und Build-Cache | Ihr Worker | Nicht automatisch übertragen | Die vollständige Arbeitskopie bleibt lokal. |
| Lokale Zugangsdaten der Maschine | Ihr Worker | Nicht automatisch übertragen | Halten Sie Geheimnisse aus Befehlen, Ausgaben und Artefakten heraus. |
| Dateiinhalte und Diffs | Ihr Worker, danach Agentenkontext und Ergebnisse | Ja, wenn erforderlich | Der Privacy Mode betrifft die Trainingsnutzung, nicht die Übertragung. |
| Terminalausgaben und lokale MCP-Ergebnisse | Ihr Worker, danach Tool-Ergebnisse | Ja, wenn sie zurückgesendet werden | Ergebnisse können Code oder sensible Daten enthalten. |
| Screenshots und Desktop-Stream | Ihr Worker, danach Cursor, sobald sie erzeugt oder geteilt werden | Ja | Computer-Use-Sitzungen können den Agenten-Desktop streamen. |
| Videos, Screenshots und Verweise auf Logs | Von Cursor verwalteter Artefaktspeicher | Ja, standardmäßig | Durch Sperren des Artefakt-Hosts lassen sich Uploads deaktivieren. |
| Modellanfragen mit API-Schlüssel | Cursors Verarbeitungspfad | Ja | BYOK umgeht Cursors Backend nicht. |
Der entscheidende Unterschied ist schnell erklärt: Das vollständige Repository kann auf Ihrer Maschine bleiben, während ausgewählter Kontext daraus für die Inferenz weiterhin über das Netzwerk läuft. Das ist Kontrolle über die Ausführung – aber keine Garantie für vollständige Datenabschottung.
Was Cursor tatsächlich in Ihre Infrastruktur verlagert
Self-Hosted Machines verlagern die Werkzeugausführung auf eine vom Kunden kontrollierte Maschine. Der Worker kann Dateien bearbeiten, Befehle ausführen, auf interne Dienste zugreifen, einen Browser bedienen und lokale MCP-Server anbinden. Die Agentenschleife, Inferenz, Planung und Sitzungsorchestrierung verbleiben in Cursors Cloud.
Gestartet wird der Worker mit dem Cursor-CLI-Befehl agent worker start. Anschließend baut er eine dauerhafte ausgehende HTTPS-Verbindung zu Cursor auf. Laut Cursor geht die Verbindung ausschließlich vom Worker nach außen aus: Es sind weder ein eingehender Port noch eine öffentliche IP-Adresse oder ein VPN-Tunnel erforderlich.
Der dokumentierte Ablauf einer Sitzung sieht so aus:
- Eine Cloud-Agent-Sitzung startet in der Cursor-Oberfläche.
- Cursors Cloud-Agent-Schleife plant die nächste Aktion.
- Cursor sendet einen Tool-Aufruf über die Worker-Verbindung.
- Der Worker führt den Befehl, die Änderung, die Browser-Aktion oder den MCP-Vorgang aus.
- Der Worker sendet das Ergebnis für den nächsten Inferenzschritt zurück.
Der Worker benötigt weiterhin ausgehenden Zugriff auf api2.cursor.sh und api2direct.cursor.sh. Für CLI-Updates und bestimmte Computer-Use-Einrichtungen kann außerdem downloads.cursor.com erforderlich sein. Das reine Ausgehend-Prinzip verhindert den Zugriff von außen auf Ihr Netzwerk, macht den Worker aber keineswegs zu einer Offline-Laufzeit für Modelle.
Cursor nennt als Einsatzgebiete private Repositories oder Dienste, die gehostete Worker nicht erreichen können, spezielle Hardware wie GPUs oder Macs sowie eigene Betriebssysteme oder Build-Images. Wenn es ausschließlich um private Konnektivität geht, empfiehlt Cursors Leitfaden zur Runtime-Auswahl, zunächst verwaltete Cloud Agents mit Allowlists, Tailscale-ähnliche Netzwerke, AWS PrivateLink oder Cloudflare Tunnel zu prüfen.
Welche Daten den Worker verlassen können – und was der Privacy Mode ändert
In der Dokumentation nennt Cursor ausdrücklich Dateiinhalte, Terminalausgaben, Diffs, Screenshots, lokale MCP-Ergebnisse und Routing-Metadaten als Daten, die der Worker senden kann. Bei der Datenschutzfrage müssen drei Dinge getrennt betrachtet werden: Was wird übertragen, wird es für das Training verwendet und wie lange bleibt es gespeichert?
Der Privacy Mode steuert das Training – nicht den Datenabfluss
Cursors Übersicht zu Datennutzung und Datenschutz, aktualisiert am 28. August 2026, besagt, dass der Privacy Mode verhindert, dass Kundendaten von Cursor für das Training verwendet werden. Außerdem erklärt Cursor, mit seinen Anbietern Vereinbarungen zur Speicherung von null Daten zu unterhalten. Die Seite schränkt diese Aussage jedoch ein: Risikoklassifizierer können Prompts oder Konversationen zur Untersuchung speichern, und aus Gründen der Latenz sowie der Netzwerkeffizienz kann es zu einer vorübergehenden Zwischenspeicherung von Dateien kommen.
Cursor beschreibt die zwischengespeicherten Dateien als mit clientseitig erzeugten Schlüsseln verschlüsselt. Die Schlüssel liegen für die Dauer einer Anfrage auf Cursors Servern. Das ist eine Aussage von Cursor zu Speicherung und Schutz – kein Beleg dafür, dass die Anfrage Cursors Server nie erreicht.
Auch das Thema API-Schlüssel ist wichtig. Cursor erklärt, dass die Verwendung eines eigenen Provider-API-Schlüssels das Backend nicht umgeht, weil die Anfragen für die abschließende Prompt-Erstellung weiterhin durch Cursor laufen. BYOK kann verändern, wer die Modellnutzung autorisiert; als direkter Datenschutzpfad vom Client zum Anbieter sollte es nicht verstanden werden.
Bei der Bewertung der Funktion zog ein Nutzer dieselbe architektonische Grenze:
„Wichtige Grenze: Cursors selbst gehostete Maschinen verlagern die Ausführung, nicht den gesamten Agenten. Laut Cursor bleiben Inferenz und Planung in der Cloud; Tool-Ausgaben fließen zurück und können Code enthalten. Für eine Sicherheitsprüfung sollte man das als selbst gehostete Ausführung behandeln – nicht als selbst gehosteten Agenten.“ — @ham_zax, X
Der Artefakt-Schalter schafft keine Datenlücke
Cursor dokumentiert eine begrenzte Möglichkeit, Artefakt-Uploads zu stoppen: Sperren Sie den ausgehenden HTTPS-Datenverkehr zu cloud-agent-artifacts.s3.us-east-1.amazonaws.com. Tool-Aufrufe und Tool-Ergebnisse funktionieren weiterhin, allerdings erscheinen Screenshots, Videos und Log-Verweise dann nicht in Pull Requests oder im Cursor-Dashboard.
Das ist sinnvoll, wenn eine Organisation keine visuellen Artefakte benötigt. Eine vollständige Datenschutzlösung ist es nicht, denn Dateiinhalte, Terminalausgaben, Diffs, während der Inferenz verwendete Screenshots und MCP-Ergebnisse können weiterhin über die Verbindung der Agentensitzung zurückgesendet werden.
Auch beim MCP-Transport gibt es einen wichtigen Unterschied. Cursors Dokumentation zu Team Pools zufolge laufen befehlsbasierte MCP-Server, also Stdio-Server, auf dem Worker und können private Netzwerke erreichen. HTTP-/SSE-MCP-Server werden für OAuth, Sitzungscaching und Authentifizierung vom Cursor-Backend verarbeitet. Bei einem privaten MCP-Endpunkt muss deshalb der Transport geprüft werden – nicht nur der Standort des Hosts.
Wählen Sie die Runtime nach Ihrer Einschränkung – nicht nach dem Etikett
Cursor bietet drei Runtime-Varianten. Self-Hosting passt dann am besten, wenn die Ausführungsgrenze, die Hardware oder die Umgebung eine festgeschriebene Anforderung und keine bloße Präferenz ist.
| Runtime | Wo Tool-Aufrufe ausgeführt werden | Geeignet für | Hauptverantwortung |
|---|---|---|---|
| Von Cursor verwaltete Cloud Agents | Isolierte, von Cursor verwaltete VM | Die meisten Teams, die verwaltete Netzwerke und standardmäßige Ubuntu-basierte Umgebungen einsetzen können | Cursor verwaltet den Lebenszyklus, die Kapazität, die Isolation und das Entfernen der VM nach der Konfiguration Ihrer Umgebung. |
| My Machines | Laptop, Devbox, Mac oder VM eines einzelnen Nutzers | Persönliche Workflows, Repositories mit lokalem Zustand oder ein schneller Proof of Concept | Sie verwalten Erreichbarkeit, Zugangsdaten, Abhängigkeiten, Bereinigung und Checkout. |
| Team Pools | Von der Organisation verwaltete Worker | Enterprise-Flotten, GPUs, Macs, Kubernetes, Routing über Labels und zentralisierte Kapazität | Ihr Team verwaltet Hosts, Images, Secrets, Skalierung, Monitoring, Zurücksetzungen und Ausfälle. |
Wählen Sie verwaltete Cloud Agents, wenn nur der private Zugriff entscheidend ist
Verwaltete Cloud Agents können ausreichen, wenn sich die gewünschte Grenze über Repository-Berechtigungen, Netzwerk-Allowlists, einen Tailscale-ähnlichen Client oder unterstützte private Konnektivität abbilden lässt. Cursors Runtime-Leitfaden empfiehlt verwaltete Infrastruktur für die meisten Teams und beschreibt sie als Variante mit weniger Betriebsaufwand.
Damit entfällt der Betrieb einer eigenen Worker-Flotte, während Cursor weiterhin den Lebenszyklus der VMs und die elastische Parallelität verwaltet. Datenfrei sind verwaltete Agents dadurch nicht; der Unterschied besteht darin, dass Cursor die Ausführungsumgebung betreibt und nicht Ihr Team.
Wählen Sie My Machines für eine Person und eine kontrollierte Umgebung
My Machines verbindet eine persönliche Maschine mit einem einzelnen Cursor-Konto. Das ist praktisch, wenn ein Entwickler bereits über einen eingerichteten Mac, eine Devbox oder eine entfernte VM mit lokalen Abhängigkeiten und passendem Netzwerkzugriff verfügt, deren Einrichtung an anderer Stelle aufwendig wäre.
Der Preis dafür ist zusätzlicher Betriebsaufwand. Für aktive Sitzungen muss die Maschine online bleiben; außerdem kümmert sich der Nutzer um Bereinigung, Aktualität des Checkouts, Festplattenzustand, Zugangsdaten und die Reparatur von Abhängigkeiten. Die Dokumentation zu Cursors Self-Hosted-Funktionen sagt, dass mehrere Agents auf derselben Maschine laufen können. Das ist jedoch noch kein zentral verwaltetes Team-Fleet-Modell.
Wählen Sie Team Pools nur, wenn die Flottenkontrolle den Aufwand rechtfertigt
Team Pools richten sich an Enterprise-Teams. Sie verwenden Service-Account-Authentifizierung, gemeinsam genutzte Worker-Kapazität, Labels und controllerbasierte Skalierung. Ein gpu-Pool kann Aufgaben an GPU-Maschinen weiterleiten, ein ios-Pool an Macs. Cursor dokumentiert bis zu 200 Worker pro Nutzer und 1.000 Worker pro Team; größere Installationen erfordern eine Abstimmung zur Skalierung.
Pools können auf null skaliert werden und persistente, containerisierte, Kubernetes- oder von Partnern gehostete Worker verwenden. Laut Cursor kann die Wiederherstellung eines freigegebenen Workspace mehrere Minuten dauern. Die Flexibilität ist für schwankende Lasten nützlich, doch Verwaltung der Images, Zurücksetzen der Worker, Kapazitätsplanung, Rotation von Secrets und Monitoring liegen beim Kunden.
Die Kosten bestehen aus Infrastruktur und Modellnutzung
Die Dokumentation zu Self-Hosted Machines und die Seite zu Cursor-Modellen und Preisen beschreiben die Zuständigkeiten für Modelle, Tarife und Infrastruktur, nennen aber keine separate Gebühr pro Worker für Self-Hosted Machines. Das beschriebene Kostenmodell lautet: Sie bezahlen das ausgewählte Modell weiterhin über Cursor und zusätzlich die von Ihnen betriebene Maschine, den Container, den Cluster, Speicher, Netzwerk, Monitoring und den laufenden Betrieb.
Als Argument für eine reine Kostensenkung ist Self-Hosting daher wenig überzeugend, wenn keine besonderen Anforderungen an Netzwerk oder Hardware bestehen. Dynamische Pools und das Herunterfahren ungenutzter Ressourcen können Leerlaufkosten reduzieren. Der Break-even hängt jedoch von Lastprofil, Startzeit und dem Umfang des wiederherzustellenden Zustands ab; Cursor veröffentlicht dafür keine allgemeingültige Zahl.
Checkliste für die Sicherheitsprüfung
Gehen Sie diese Liste gemeinsam mit Ihrer Sicherheits-, Plattform- oder Compliance-Verantwortung durch. Das Wort „self-hosted“ allein sollte kein Freigabesignal sein.
- Definieren Sie die Grenze präzise. Klären Sie, ob laut Richtlinie der vollständige Checkout, die Tool-Ausführung, Zugangsdaten, Inferenzanfragen, Artefakte oder alles davon innerhalb des Perimeters bleiben müssen. Self-Hosted Machines stellt lediglich den Ausführungs-Worker und den vollständigen lokalen Zustand unter Ihre Kontrolle.
- Klassifizieren Sie zurückgesendeten Kontext. Dateiinhalte, Diffs, Terminalausgaben, Screenshots und MCP-Ergebnisse können an Cursor gesendet werden. Prüfen Sie, ob diese Ausgaben Quellcode, Kundendaten, Tokens, interne URLs oder Antworten aus Produktionssystemen enthalten können.
- Aktivieren Sie den Privacy Mode bewusst. Er verändert Cursors Angaben zur Trainingsnutzung und zur Speicherung durch Provider. Er verhindert weder die Verarbeitung von Anfragen noch temporäres Caching oder die Verarbeitung durch Risikoerkennungssysteme.
- Behandeln Sie BYOK korrekt. Ein API-Schlüssel entfernt Cursors Backend laut Seite zur Datennutzung nicht aus dem Anfragepfad.
- Beurteilen Sie den Artefakt-Datenabfluss separat. Erlauben oder sperren Sie
cloud-agent-artifacts.s3.us-east-1.amazonaws.comabhängig davon, ob Screenshots, Videos und Log-Verweise in Pull Requests und im Dashboard akzeptabel sind. Wenn Ihre Firewall es unterstützt, verwenden Sie eine Regel für genau diesen Host. - Arbeiten Sie mit einer Allowlist für ausgehenden Datenverkehr. Erlauben Sie nur die dokumentierten Cursor-Endpunkte sowie bewusst aktivierte Hosts für Updates oder Computer Use. Für den Worker sollte weder ein eingehender Port noch eine öffentliche IP erforderlich sein.
- Prüfen Sie den MCP-Transport. Verwenden Sie Worker-seitiges Stdio-MCP, wenn ein Server einen privaten Dienst erreichen muss, und bewerten Sie die zurückgegebenen Ergebnisse. Gehen Sie nicht davon aus, dass ein HTTP-/SSE-MCP-Endpunkt innerhalb Ihres Netzwerks bleibt, nur weil der Dienst privat ist.
- Isolieren und setzen Sie Worker zurück. Legen Sie für Team Pools fest, wie Maschinen zwischen Agents gelöscht oder neu erstellt werden, wie Zugangsdaten injiziert werden und wie Logs überwacht werden. Cursors Anleitungen und Templates sind Referenzarchitekturen, keine vollständig verwaltete Produktionsflotte.
- Testen Sie den Fehlerfall. Prüfen Sie, was passiert, wenn Cursor-Endpunkte, der Artefaktspeicher, der Worker, eine private Registry oder ein MCP-Server nicht verfügbar ist. Ein gesperrter Artefakt-Host darf nicht mit einer gesperrten Agentensitzung verwechselt werden.
- Lehnen Sie es für air-gapped Workloads ab. Wenn keine ausgehende Übertragung von Modellkontext oder keine Inferenz in einer Drittanbieter-Cloud zulässig ist, erfüllt diese Architektur die Anforderung nicht. Die Agentenschleife bleibt in Cursors Cloud.
| Ihre tatsächliche Anforderung | Entscheidung |
|---|---|
| Befehle, lokaler Zustand oder spezielle Hardware müssen in Ihrer Umgebung laufen | Verwenden Sie Self-Hosted Machines mit Kontrollen für Kontext- und Artefakt-Datenabfluss. |
| Agents benötigen private Dienste, können aber in einer verwalteten VM laufen | Beginnen Sie mit verwalteten Cloud Agents und unterstützter privater Konnektivität. |
| Kein Modellkontext darf das Netzwerk verlassen oder die Inferenz muss offline erfolgen | Verwerfen Sie diese Architektur; sie hängt weiterhin von Cursors Cloud ab. |
Häufige Fragen zum Datenschutz bei Cursor Self-Hosted Machines
Sind Cursor Self-Hosted Machines vollständig selbst gehostet?
Nein. Cursor behält Agentenschleife, Inferenz, Planung und Orchestrierung in seiner Cloud. Ihre Maschine hostet die Tool-Ausführung und den lokalen Arbeitszustand.
Verlässt Quellcode die selbst gehostete Maschine?
Ausgewählte Dateiinhalte, Diffs, Terminalausgaben, Screenshots und lokale MCP-Ergebnisse können als Eingaben oder Tool-Ergebnisse für den Agenten den Worker verlassen. Cursor sagt, dass der vollständige Checkout und der Build-Cache auf dem Worker bleiben. Die Grenze ist daher teilweise und nicht vollständig.
Verhindert der Privacy Mode, dass Daten das Netzwerk überqueren?
Nein. Cursor beschreibt den Privacy Mode als Schutz davor, dass Cursor und Modellanbieter Daten für das Training verwenden, und verweist dabei auf seine angegebenen Speichervereinbarungen. Er verhindert nicht, dass der Worker für die Inferenz erforderlichen Kontext sendet.
Umgeht BYOK Cursor?
Nein. Laut Cursors Seite zur Datennutzung laufen Anfragen mit API-Schlüssel weiterhin durch das Backend, wo der endgültige Prompt erstellt wird. BYOK sollte daher nicht als direkte Verbindung vom Worker zu einem Modellanbieter verstanden werden.
Kann ich verhindern, dass Screenshots und Videos hochgeladen werden?
Sie können den ausgehenden Zugriff auf cloud-agent-artifacts.s3.us-east-1.amazonaws.com sperren. Die Tool-Ausführung läuft weiter, aber Artefakte erscheinen dann nicht in Pull Requests oder im Cursor-Dashboard. Andere Daten der Agentensitzung können weiterhin an Cursor zurückgesendet werden.
Benötigt ein Worker eine eingehende Firewall-Regel oder ein VPN?
Cursor dokumentiert ein Modell mit ausschließlich ausgehenden Verbindungen. Demnach sind weder ein eingehender Port noch eine öffentliche IP-Adresse oder ein VPN-Tunnel erforderlich. Der Worker benötigt allerdings ausgehenden Zugriff auf die dokumentierten Cursor-Endpunkte und auf alle Dienste, die er verwenden soll.
Kann ich Team Pools mit einem persönlichen oder niedrigeren Tarif verwenden?
Cursors Dokumentation ordnet Team Pools dem Enterprise-Bereich zu und verlangt einen Service-Account-API-Schlüssel. My Machines ist die Option für persönliche Worker. Gehen Sie nicht davon aus, dass ein persönlicher API-Schlüssel einen Team-Pool-Worker starten kann.
Kann ich Cursor Self-Hosted Machines vollständig offline betreiben?
Nein. Agentenschleife und Inferenz bleiben in Cursors Cloud, und der Worker benötigt eine ausgehende Verbindung. Für einen Offline- oder Air-Gap-Betrieb ist eine andere Architektur mit lokal gehosteter Orchestrierung und lokaler Modellinferenz erforderlich.
Setzen Sie Cursor Self-Hosted Machines ein, wenn Ihr Team eine vom Kunden kontrollierte Ausführung, Zugriff auf private Netzwerke, spezielle Hardware oder eine persistente Umgebung benötigt. Wenn die Anforderung lautet, den KI-Datenverkehr vollständig aus der Cloud herauszuhalten, braucht es ein anderes Design: Diese Funktion verändert, wo Befehle laufen – nicht, wo der Agent denkt.