Cloud Agents, aber im eigenen Netz
Cursors Cloud Agents arbeiten Aufgaben selbstständig ab, während du etwas anderes machst. Bisher liefen sie auf Cursors Infrastruktur. Mit Self-Hosted Machines verlagert Cursor die Ausführung der Werkzeuge in dein Netzwerk: Codebasis, Build-Ergebnisse und Secrets bleiben auf internen Maschinen. Die Ankündigung stammt vom 2. September 2026.
Für viele Unternehmen war genau das der Grund, Cloud Agents nicht zu nutzen. Interne Paketregistries, Datenbanken im privaten Netz oder Build-Systeme hinter der Firewall waren für einen Agenten in fremder Cloud schlicht nicht erreichbar.
So funktioniert die Anbindung
Laut Dokumentation öffnet die Cursor-CLI auf der Maschine eine ausgehende HTTPS-Verbindung zu Cursor. Über diese Verbindung schickt Cursor die Tool-Aufrufe des Agenten. Eingehende Ports musst du nicht öffnen.
Was Admins wissen müssen:
- Nötig ist ein Cursor Enterprise-Plan. Ein Team-Admin schaltet die Funktion im Cloud-Agents-Dashboard frei.
- Worker authentifizieren sich mit dem API-Key eines Service Accounts in der Umgebungsvariable CURSOR_API_KEY.
- Freizugeben sind ausgehend api2.cursor.sh, api2direct.cursor.sh und ein S3-Bucket für Agent-Artefakte in us-east-1.
- Anfragen werden über einen Pool-Namen oder Labels an die passenden Worker verteilt.
- Der bisherige Kubernetes-Operator samt Helm-Chart gilt für neue Installationen als veraltet.
Eigene Rechner oder Team-Pools
Cursor unterscheidet zwei Varianten. Unter My Machines verbindest du einen einzelnen Laptop oder eine VM mit deinem Konto, etwa für persönliche Workflows. Team-Pools sind benannte Warteschlangen von Workern, die mit der Nachfrage wachsen und schrumpfen. Ein Pool ist nicht an ein Repository gebunden, jeder passende Worker kann eine Anfrage übernehmen.
Ungenutzte Maschinen gehen in Standby und werden reaktiviert, wenn innerhalb eines Zeitfensters eine Folgeanfrage kommt. Wie lang dieses Fenster ist, nennt Cursor nicht. Für den Betrieb gibt es Vorlagen mit einem Controller, der pro Anfrage einen isolierten Worker startet, oder alternativ warm gehaltene Instanzen im Leerlauf.
Vorlagen existieren für AWS Lambda MicroVMs, Cloudflare, Namespace, Modal, Daytona, E2B, Vercel, Tensorlake und Coder. Wer schon eine Sandbox-Plattform im Einsatz hat, muss also nichts neu erfinden.
Computer Use auf Linux und Mac
Selbst gehostete Worker unter Linux und macOS unterstützen außerdem Computer Use. Der Agent kann klicken, tippen, Screenshots machen und einen Browser steuern. Du kannst ihm dabei zusehen oder die Kontrolle direkt aus Cursor übernehmen. Für End-to-End-Tests gegen interne Staging-Umgebungen ist das ein echter Gewinn.
Was das für Sicherheit und Datenschutz heißt
Wichtig ist eine Unterscheidung, die in der Ankündigung leicht untergeht. Lokal läuft die Ausführung der Werkzeuge: Terminal-Befehle, Builds, Tests, Dateizugriffe. Wo die Modellinferenz stattfindet, sagt die Dokumentation nicht. Da der Agent den Kontext zum Planen braucht, solltest du davon ausgehen, dass Codeausschnitte und Tool-Ergebnisse weiterhin an Cursor und die Modellanbieter gehen.
Self-Hosted Machines lösen damit vor allem das Netzwerk- und Secret-Problem, nicht jede Datenschutzfrage. Für den Rollout heißt das: Service Accounts mit minimalen Rechten, Worker in isolierten Umgebungen ohne dauerhafte Credentials und klare Regeln, welche Repositories überhaupt an Cloud Agents gehen.
Fazit
Mit Self-Hosted Machines werden Cursors Cloud Agents für Unternehmen mit internen Abhängigkeiten erst praktisch nutzbar. Das Setup ist durchdacht und nutzt vorhandene Sandbox-Plattformen. Wenn du den Enterprise-Plan hast, starte mit einem kleinen Pool für ein unkritisches Repository und prüfe, welche Daten den eigenen Perimeter trotzdem verlassen.