roobriefIT-News für Entwickler

Dev & Releases

Cursor-Agentenbefehle können auf Firmenrechnern laufen, Schwachstellenprüfungen dagegen in der Cursor-Cloud

Tool-Aufrufe von Cloud-Agenten können auf Firmenrechnern bleiben, aber die Dateiinhalte, die das Modell zum Antworten liest, bleiben standardmäßig nicht im Unternehmen.

Cursor hat im September zwei Unternehmensfunktionen freigegeben. Am 2. Sept. kündigte es Self-Hosted Machines an: Dateiänderungen und Befehlsausführung für Cloud-KI-Agenten (Programme, die für Nutzer mehrstufige Aufgaben selbstständig erledigen) laufen auf Rechnern, die dem Unternehmen gehören. Am 23. Sept. öffnete es Security Review für die Teams- und Enterprise-Pläne. Security Review sucht in Pull Requests (eine vorgeschlagene Code-Änderung, die andere vor dem Zusammenführen prüfen) nach ausnutzbaren Fehlern.

Design Mode, mit dem man Elemente auf dem Bildschirm anklicken und korrigieren lässt, und Agent Tabs, die im Editor mehrere Chats nebeneinander zeigen, gehörten nicht zu diesen September-Veröffentlichungen. Design Mode erschien zuerst mit Cursor 3 am 2. April; Mehrfachauswahl und Spracheingabe kamen am 5. Juni. Agent Tabs stehen ebenfalls im Changelog vom 2. April.

Elemente auf dem Bildschirm anzeigen und dem Agenten übergeben

Design Mode läuft im Browser im Agents Window, nicht in einem normalen Webbrowser. Auf dem Mac schaltet man ihn mit Cmd+Shift+D ein und aus. Für Windows nennt die Dokumentation keinen Kurzbefehl.

Ein Klick auf ein Element schickt dieses Element und den dahinterliegenden Code an den Agenten. Seit dem 5. Juni kann man mehrere Elemente wählen und etwa sagen „mach das wie jenes“, oder die nächste Änderung sprechen. Das Mikrofon bleibt offen, während Agenten arbeiten. Markiert man einen Bereich, liegt die Markierung auf einem eingefrorenen Bild, sodass der Agent von der gesehenen Szene ausgeht.

Für ein gewähltes Element gehen zwei Signale mit: wo auf der Seite welcher Baustein liegt (Pfad, Komponentenname, Attribute, berechnete Styles, Props) und ein Screenshot des Layouts drumherum. Nach der Änderung zeichnet die App neu, ohne neu zu laden. Cursor empfiehlt dafür sein Modell Composer 2.5.

Das Fenster für viele Agenten und Tabs im Editor sind verschieden

Das Agents Window ist ein eigener Bildschirm und seit dem 2. April allgemein verfügbar. Im Editor öffnet man mit Cmd+Shift+P die Befehlsliste und wählt Open Agents Window. Dort sieht man lokale, Cloud- und Remote-SSH-Agenten (Arbeit über eine Verbindung zu einem anderen Rechner) an einem Ort und kann mehrere Cloud-Agenten parallel laufen lassen. Zurück zum älteren Editor geht Open IDE in derselben Liste. Zwei Wochen nach dem Start konnten Enterprise-Admins den Zugang einschränken; diese Frist ist vorbei.

Agent Tabs im Editor stehen im selben Changelog, machen aber etwas anderes: Sie zeigen mehrere Chats nebeneinander oder im Raster. Das Bild für viele Cloud-Jobs gleichzeitig ist das Agents Window.

Befehle auf Firmenrechnern, Entscheidungen in der Cursor-Cloud

Das Changelog vom 2. Sept. fasst Self-Hosted Machines so zusammen: Die Werkzeugausführung bleibt im Firmennetz; Codebase (der gesamte Code im Repository), Build-Ergebnisse und Geheimnisse bleiben auf internen Rechnern.

Die Cursor-Dokumentation zu Self-Hosted Machines lässt die Planung in der Cursor-Cloud. Dateiänderungen, Terminalbefehle, Klicks auf dem Bildschirm und lokale MCP-Server (ein Standard, mit dem KI externe Tools nutzen kann) laufen auf einem Worker – dem Rechner, der die Arbeit annimmt und ausführt. Was zu tun ist und die Inferenz (mit einem fertigen Modell Antworten zu erzeugen) bleiben bei Cursor.

Während eines Laufs schickt der Worker Cursor benötigte Dateiinhalte, Terminalausgabe, Diffs, Screenshots, lokale MCP-Ergebnisse und Routing-Metadaten. Bei Desktop-Sharing geht auch dieser Stream nach draußen. Screenshots, Videos und Log-Verweise für Pull Requests und das Dashboard landen in Cursor-verwaltetem Speicher. Im Unternehmen bleiben das vollständige Repository, der Build-Cache (Zwischendateien, damit nicht neu gebaut wird) und Anmeldedaten auf dem Rechner. Die Docs raten, Geheimnisse nicht in Werkzeugausgaben oder Artefakte zu schreiben.

Mit Privacy Mode trainieren Cursor und Modell-Anbieter nicht mit dem vom Worker gesendeten Code. Das heißt nicht, dass der Code nicht hinausgeht. Worker brauchen keine eingehenden Ports – nur eine ausgehende verschlüsselte Webverbindung zu Cursor. Wer nur Artefakte sperren will, blockiert ausgehenden Verkehr zu cloud-agent-artifacts.s3.us-east-1.amazonaws.com. Die Arbeit läuft weiter; Artefakte erscheinen dann nicht in Pull Requests und Dashboard.

Es gibt zwei Betriebsarten:

  • My Machines ist persönlich. Man verbindet den eigenen Rechner mit dem Konto per Browser-Login oder persönlichem API-Schlüssel (eine geheime Zeichenkette, die ein Programm statt eines Logins vorzeigt). Auf einem Rechner können mehrere Agenten laufen. Dashboard-Geheimnisse werden auf diesen Worker nicht heruntergeladen.
  • Team Pools bündeln Worker für eine Organisation. Die Cursor-Dokumentation verlangt den Enterprise-Plan. Authentifizierung nur über einen Service-Account-API-Schlüssel. Ein Service-Account gehört dem Team, nicht einer Person. Mit Opt-in kann man pro Anfrage wählen; sonst läuft es auf Cursor-Infrastruktur. Mit Pflicht gehen alle Cloud-Agent-Läufe auf eigene Worker. Im Pool beansprucht ein Agent jeweils einen Rechner.

Umgebungen im Changelog vom 2. Sept. sind unter anderem AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel und E2B. Die Docs nennen auch Kubernetes (ein Open-Source-System, das viele Container verwaltet). Grenzen: 200 Worker pro Nutzer, 1.000 pro Team. Modellpreise bleiben; die Firma zahlt die Rechner. Cursor-verwaltete Agenten enthalten die Ausführungsmaschine.

Die Docs empfehlen den meisten Teams verwaltete Cloud Agents. Self-Hosting lohnt, wenn Code das Netz nicht verlassen darf oder GPUs bzw. Macs für iPhone- und iPad-Apps nötig sind. Geht es nur um einen privaten Git-Server oder eine interne Paketquelle, raten die Docs zuerst zu einer privaten Verbindung ins Firmennetz auf verwalteten Agenten. Beispiele: AWS PrivateLink und Cloudflare Tunnel.

Ausnutzbare Fehler in Änderungsvorschlägen finden

Security Review startete am 23. Sept. für Teams und Enterprise. Im Dashboard wählt man Repositories; dann liest es Nicht-Entwurf-Pull-Requests im Kontext der Codebase und hinterlässt einen Review-Kommentar zu ausnutzbaren Fehlern. Stil und Qualität bleiben bei Bugbot. Es merged und schreibt Code nicht von allein um.

Diese Prüfung läuft nicht auf Firmenrechnern. Die Security-Agents-Dokumentation sagt, Security Review und Repository-Schwachstellenscans laufen auf Cloud Agents und nutzen ohne Extra-Setup die Cursor-Cloud. Ein Cloud Agent klont das freigegebene Repository in eine virtuelle Maschine in der Cursor-Cloud. Der Klon verschwindet nicht sofort nach dem Lauf; Snapshots werden nach 30 Tagen ohne Nutzung gelöscht. Ausnahme: Security Review eines Teams, ausgelöst durch ein Pull-Request-Ereignis, läuft auf Cursor-verwaltetem Hosting statt auf einem Cloud Agent. Auch das ist kein Firmenrechner. Ob dieser Host das ganze Repository klont, steht in diesen Docs nicht.

Der Umfang umfasst Injection in Datenbankabfragen, Shell-Befehle und Seiten-Templates; fehlende Login- oder Rechteprüfungen, auch solche, die nach einem Refactor nicht mehr laufen; Geheimnisse im Quellcode; SSRF (ein Fehler, bei dem ein Server eine Anfrage an eine vom Angreifer gewählte Adresse schickt) und ungeprüfte Weiterleitungen; unsichere Deserialisierung, wenn gespeicherte Daten wieder zu Programmwerten werden; Abhängigkeitsänderungen mit bekannten Schwachstellen; und die Spur, wo Nutzereingaben eintreten und wohin sie gehen.

Jeder Fund hat Schweregrad, Angriffspfad und einen Fix-Vorschlag. Mit Begründung verwerfen, und derselbe Hinweis kommt auf diesem Pull Request nicht wieder. Teamregeln gelten für jeden Pull Request – etwa dass externe Aufrufe über einen festen Client laufen oder bestimmte Tabellen nicht aus Request-Handlern abgefragt werden. Ein eigener Preis steht in dieser Ankündigung nicht.

Am selben Tag öffnete auch Rollouts für Teams und Enterprise. Beim Deploy meldet es je Umgebung, ob alles gesund wirkt, schlechter als zuvor oder unklar. Es merged und rollt nicht von allein zurück; je nach Einstellung kann es einen Revert-Pull-Request zur Prüfung öffnen oder einen Fix an einen Cloud-Agenten geben. Quellverwaltung verbindet Origin oder GitHub, Signale Datadog und Ähnliches. Feature-Flag-Anbindung (Schalter, die Funktionen pro Nutzer an- und ausschalten) steht nur als „bald“; bis zum 16. Okt. konnten wir den Start nicht bestätigen. Testguthaben für Rollouts galten 10 Tage ab Start – etwa 50 Änderungen für Teams, etwa 500 für Enterprise. Am 16. Okt. war das Fenster zu; ob Guthaben danach blieb, konnten wir nicht bestätigen.

Was wir nicht bestätigen konnten oder mit Vorsicht behandeln sollten

  • Diese Funktionen als ein großes Update zu sehen, stimmt nicht. Bildschirm-Zeigen stammt vom 2. April und 5. Juni, Self-Hosting vom 2. Sept., Security Review vom 23. Sept.
  • „Code und Build-Ergebnisse gehen nie hinaus“ ist weiter als die Cursor-Docs. Vollständiges Repository, Build-Cache und Anmeldedaten auf dem Rechner bleiben; für den Lauf nötige Dateiinhalte und Artefakte gehen zu Cursor.
  • Dass Self-Hosting für Teams und Enterprise gemeinsam startete, passt nicht zu den Cursor-Docs. Team Pools brauchen Enterprise. Das Changelog vom 2. Sept. nennt Pools nur eine Warteschlange für Teams oder Unternehmen; ob der Teams-Plan dabei war, lässt sich aus dem Satz allein nicht feststellen.
  • Dass sicherheitsbewusste Unternehmenskunden schneller adoptieren, hat keine Zahl und keine offizielle Ankündigung, die wir prüfen konnten.
  • Auch Behauptungen, Security Review stoppe jede Schwachstelle oder repariere Fehler von allein, stehen in der Cursor-Ankündigung nicht.

Was sich für Entwickler ändern könnte

Das Folgende ist unsere Einschätzung und unser Rat auf Grundlage der Berichte.

  • In Sicherheitsreviews nicht schreiben „Code geht nie hinaus“. Bleibendes und Herausgehendes nach den Cursor-Docs trennen. Artefakt-Uploads sind eine eigene Frage: ob ausgehender Verkehr zu diesem Speicher-Host blockiert ist.
  • Team Pools brauchen den Enterprise-Plan und Betriebskosten für Rechner. Modellpreise bleiben. Ausprobieren auf dem eigenen Rechner geht über My Machines. Die Docs empfehlen den meisten Teams weiterhin Cursor-verwaltete Cloud Agents.
  • Security Review läuft nicht auf Firmenrechnern. Pro Repository einschalten; Entwurfs-Pull-Requests werden übersprungen. Verworfene Funde kommen auf demselben Pull Request nicht zurück – vor dem Verwerfen eine Begründung lassen. Stil und Qualität bleiben bei Bugbot.
  • Design Mode sieht man nicht, wenn nur der Editor offen ist. Im Browser des Agents Window mit Cmd+Shift+D einschalten. Kurzbefehl-Tabellen in den Docs sind nur für den Mac.

Was man beobachten sollte

Ob Feature Flags an Rollouts angebunden werden, ob Preis und Falsch-Positiv-Rate von Security Review veröffentlicht werden, und ob eine Option kommt, die auch Dateiinhalte für die Inferenz im Unternehmen lässt.

Quellen

Quelle: cursor.com

← Zurück