Cursor öffnet Cloud Agents für eigene Infrastruktur

Cursor öffnet Cloud Agents für eigene Infrastruktur

Cursor erweitert seine Cloud Agents: Sie können nun auf von Nutzern verwalteten Maschinen ausgeführt werden, etwa auf dynamisch geplanten Pools im eigenen Netzwerk. Cursor übernimmt weiterhin Start und Verwaltung der Agenten, die Infrastruktur liegt jedoch beim Team. Cursor-hosted Umgebungen bleiben der Standard: Jede Session läuft auf einer dedizierten VM in der Cursor-Cloud mit eigenen Abhängigkeiten und Netzwerkkontrollen.

Die Neuerung gibt Teams mehr Kontrolle über Ausführungsumgebung und Infrastruktur – und zwar auf mehreren Ebenen. Erstens bestimmen Teams, wo Agenten ausgeführt werden: Sie können die Maschinen in ihrem eigenen Netzwerk platzieren, sodass Agenten direkt neben internen Diensten und der Quellcodeverwaltung arbeiten, ohne dass Daten das Firmennetz verlassen. Zweitens entscheiden sie, welche Hardware zum Einsatz kommt: Eigene Server oder spezielle Instanztypen, die für bestimmte Workloads optimiert sind. Drittens können sie Betriebssysteme und Build-Pipelines nutzen, die sich nur schwer als vorgefertigter Cloud-Agent-Build verpacken lassen – etwa Legacy-Systeme, spezielle Compiler-Ketten oder unternehmensspezifische Toolchains. Viertens behalten sie die Kontrolle über Netzwerkzugriffe, Firewall-Regeln und Zugriffsrechte, da die Maschinen in ihrer eigenen Infrastruktur laufen. Diese Flexibilität ist besonders für Unternehmen relevant, die regulatorische Anforderungen an Datenresidenz oder Netzwerksegmentierung erfüllen müssen. Cursor orchestriert dabei weiterhin die Arbeit der Agenten, sodass Teams die operative Last nicht selbst tragen.

Lambda MicroVMs als schnelle Compute-Schicht

Mit Lambda MicroVMs als Compute-Schicht können Entwickler KI-Coding-Agenten im eigenen AWS-Konto ausführen. Jede Maschine startet nahezu sofort aus einem Snapshot, pausiert bei Inaktivität und setzt mit vollem Zustand fort. Dadurch profitieren Agenten von schnellem Start, starker Isolation und null Flottenmanagement, während Cursor die Arbeit orchestriert.

Die Funktionsweise ist der entscheidende Vorteil gegenüber klassischen VM- oder Container-Ansätzen. Da keine dauerhaft laufenden Instanzen vorgehalten werden müssen, entfallen Leerlaufkosten vollständig: Eine MicroVM wird nur dann gestartet, wenn ein Agent tatsächlich Arbeit verrichtet, und pausiert, sobald der Agent inaktiv ist. Der Zustand bleibt dabei vollständig erhalten – laufende Prozesse, geöffnete Dateien, Umgebungsvariablen und der gesamte Speicherinhalt werden eingefroren und beim nächsten Start nahtlos wiederhergestellt. Das bedeutet, dass ein Agent nach einer Pause nicht neu initialisiert werden muss, sondern exakt dort weitermacht, wo er aufgehört hat. Für Teams, die bereits AWS nutzen, entfällt das Verwalten eigener Server oder Container-Orchestrierung: Es gibt keine Flotte zu patchen, keine Kapazitätsplanung und keine manuelle Skalierung. Stattdessen skaliert die Compute-Schicht automatisch mit der Anzahl der aktiven Agenten – ob ein einzelner Entwickler einen Agenten startet oder ein ganzes Team hunderte parallel laufen lässt, die Infrastruktur passt sich ohne Eingriff an. Entwickler behalten die volle Kontrolle über ihre AWS-Umgebung, während Cursor die Orchestrierung übernimmt.

Sicherheitsarchitektur: Isolation, Sandboxing, Genehmigungen

Cloud Agents laufen in isolierten VMs. Es gibt Per-Agent-Isolation, Secret-Redaktion, Egress-Kontrollen und signierte Commits. Code und Daten liegen in der VM, isoliert und verschlüsselt. Cursor hat Agent-Sandboxing auf macOS, Linux und Windows eingeführt; sandboxed Agents stoppen 40 Prozent seltener als unsandboxed. Cursor ist SOC 2 Type 2 compliant und verpflichtet sich zu mindestens jährlichen Penetrationstests durch Dritte. Zudem hält Cursor AIUC-1, ISO/IEC 27001:2022 und ISO/IEC 42001:2023 Zertifizierungen sowie eine SOC 2 Type II Attestierung.

Die unterschiedlichen Genehmigungsregeln folgen einer klaren Sicherheits- und Usability-Logik. Datei-Lesen und Code-Suche benötigen keine Genehmigung, weil sie keine sensiblen Daten nach außen exponieren und das Risiko eines Schadens gering ist – der Agent kann den Code nur lesen, nicht verändern. Änderungen an Workspace-Dateien sind ohne Genehmigung erlaubt, da sie sofort auf die Festplatte geschrieben werden und durch Versionskontrolle rückgängig gemacht werden können; Konfigurationsdateien bilden die Ausnahme, weil sie das Verhalten der Entwicklungsumgebung selbst verändern und bei Auto-Reload potenziell schädlicher Code ausgeführt werden könnte, bevor der Nutzer ihn prüfen kann. Terminal-Befehle erfordern standardmäßig manuelle Genehmigung, weil sie das System verändern, Daten löschen oder Secrets auslesen können – ein fehlgeleiteter Befehl kann Datenbanken zerstören oder fehlerhaften Code ausliefern. MCP-Verbindungen benötigen Genehmigung, weil sie externe Tools anbinden und damit die Angriffsfläche erweitern; nach der Verbindung muss jeder einzelne Tool-Aufruf erneut genehmigt werden. Das Sandboxing auf macOS, Linux und Windows entschärft diesen Zielkonflikt: Sandboxed Agents laufen frei in einer kontrollierten Umgebung und fordern nur dann Genehmigung an, wenn sie die Sandbox verlassen müssen, etwa für Internetzugriff. Das reduziert Unterbrechungen drastisch – sandboxed Agents stoppen 40 Prozent seltener – und verhindert gleichzeitig Genehmigungsmüdigkeit, bei der Nutzer aus Gewohnheit jede Anfrage abnicken, ohne sie zu prüfen.

Preise und Pakete: Cloud Agents inklusive

Cloud Agents sind in den Individual-, Teams- und Enterprise-Plänen enthalten. Individual kostet 20 US-Dollar pro Monat (Pro), Pro Plus 60, Ultra 200. Teams kostet 40 US-Dollar pro Nutzer und Monat, Enterprise wird individuell bepreist. Es gibt zwei Nutzungspools: Cursor Models (Grok 4.6, Grok 4.5, Composer 2.5) und Other Models für Drittanbieter zu API-Preisen. Wer regionale Datenresidenz wählt, zahlt einen Aufschlag von 10 Prozent auf die Modellpreise.

Die Wahl des Pools hat konkrete Auswirkungen auf Kosten, Leistung und Flexibilität. Der Cursor Models Pool enthält deutlich mehr inkludierte Nutzung für die hauseigenen Modelle Grok 4.6, Grok 4.5 und Composer 2.5 – wer primär mit diesen Modellen arbeitet, kommt mit dem monatlichen Kontingent weit und zahlt selten zusätzlich. Der Other Models Pool dagegen wird zu den API-Preisen des jeweiligen Drittanbieters abgerechnet; hier ist das inkludierte Kontingent kleiner, und wer regelmäßig Frontier-Modelle von OpenAI, Anthropic oder Google nutzt, muss mit Zusatzkosten rechnen. Auf Teams- und Enterprise-Plänen wählt der Cursor Router bei Auto-Anfragen das Modell basierend auf dem Optimierungsmodus – wer Kosten optimieren will, bekommt eher Cursor Models, wer maximale Intelligenz priorisiert, eher Drittanbieter. Die regionale Datenresidenz verteuert die Modellpreise um 10 Prozent, bietet aber die Garantie, dass Daten in einer bestimmten Region verarbeitet werden – ein entscheidendes Kriterium für Unternehmen mit strengen Compliance-Vorgaben. Der Start-Plan für Indien enthält nur den Cursor Models Pool und keinen Zugriff auf Drittanbieter-Modelle, was ihn für preissensible Nutzer attraktiv macht, aber die Modellauswahl einschränkt.

Interne Nutzung: Widersprüchliche Zahlen zu autonomen PRs

Cursor gibt an, Cloud Agents erzeugten intern mehr als 60 Prozent der gemergten Pull Requests. Eine andere Quelle nennt dagegen mehr als 35 Prozent der PRs, die im Engineering-Team von Cursor von autonomen Cloud Agents geschrieben werden. Der Widerspruch lässt sich durch unterschiedliche Definitionen und Messmethoden erklären.

Die 60-Prozent-Angabe aus der aktuellen Ankündigung bezieht sich auf alle intern gemergten Pull Requests im gesamten Unternehmen – also nicht nur das Engineering-Team, sondern potenziell auch andere Abteilungen, die Code beisteuern, sowie automatisierte Fixes aus Sicherheits- oder Wartungs-Workflows. Die 35-Prozent-Angabe aus dem Complete Guide vom Mai 2026 bezieht sich explizit auf das Engineering-Team von Cursor und wurde zu einem früheren Zeitpunkt erhoben. Zwischen Mai und der aktuellen Ankündigung liegt eine Weiterentwicklung der Cloud Agents, sodass der Anteil in der Zwischenzeit gestiegen sein kann. Zudem ist unklar, wie ein „von Cloud Agents geschriebener“ PR definiert wird: Zählt ein PR, bei dem der Agent den gesamten Code geschrieben hat, oder auch solche, bei denen ein Mensch den Entwurf lieferte und der Agent nur die Umsetzung übernahm? Werden PRs mitgezählt, die von Agenten eröffnet, aber von Menschen überarbeitet wurden? Ohne eine einheitliche Definition sind beide Zahlen nicht direkt vergleichbar. Beide Angaben stammen von Cursor selbst und sind nicht unabhängig geprüft; sie dienen primär als Marketing-Signal für die Leistungsfähigkeit der Cloud Agents.

Was das für Teams und den Markt bedeutet

Die Neuerung adressiert Unternehmen mit speziellen Infrastrukturanforderungen, etwa eigene Hardware, interne Netzwerke oder besondere Build-Pipelines. Sie erhöht den Druck auf Konkurrenzprodukte, die ähnliche Kontrolle bieten müssen. AWS wird als Compute-Partner relevanter, da Lambda MicroVMs die Ausführung übernehmen. Sicherheitsbedenken bleiben: Ein dokumentierter Vorfall, bei dem ein KI-Kostenmanager die Kontrolle über den eigenen Agenten verlor, zeigt, dass autonome Agenten trotz Isolation und Genehmigungen Risiken bergen.

Für Wettbewerber wie GitHub Copilot Workspace, OpenAI Codex oder Claude Code bedeutet die Ankündigung, dass sie nachziehen müssen: Wer keine vergleichbare Kontrolle über die Ausführungsumgebung bietet, verliert bei Unternehmen mit strengen Infrastruktur- oder Compliance-Anforderungen an Attraktivität. AWS profitiert doppelt: Lambda MicroVMs werden zur bevorzugten Compute-Schicht für Cursor Cloud Agents, was AWS-Kunden bindet und zusätzliche Nutzung generiert. Der genannte Vorfall unterstreicht, dass selbst ausgefeilte Sicherheitsarchitekturen keine absolute Sicherheit garantieren – Teams müssen Genehmigungsregeln, Sandboxing und Egress-Kontrollen aktiv konfigurieren und überwachen, um das Risiko autonomer Agenten zu beherrschen.