# Cursor Security Agents und Rollouts: Sicherheit und Releases prüfen

> So aktivieren Sie Security Reviewer, Vulnerability Scanner und Rollouts in Cursor Automations: Auslöser, Nutzung aus dem Teamkontingent, Tarife und Unterschiede zu Bugbot.

Source: https://ailoot.ai/blog/de/cursor-rollouts-security-agents/
Canonical: https://ailoot.ai/blog/de/cursor-rollouts-security-agents/
Language: de
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-089
Revision: sha256-14664c311c59844a5503415165927c0c48acd1677b89e6dc5b4d207af12d592f


In Cursor Automations können Sie Code-Sicherheitsprüfungen und die Release-Überwachung konfigurieren. Security Agents prüfen Pull Requests (PRs) und scannen das gesamte Repository nach einem Zeitplan. Rollouts überwacht eine Änderung nach der Bereitstellung, ist in den Tarifen Teams und Enterprise verfügbar und erfordert verbundene Telemetriedaten: Logs, Metriken und Traces.

Im Folgenden finden Sie die Einrichtungsschritte auf Grundlage der offiziellen Cursor-Dokumentation, Informationen dazu, wie die Nutzung von Security Agents abgerechnet wird, Tarifbeschränkungen sowie die Unterschiede zu Bugbot und dem manuellen Befehl `/review-security`.

Informationen zur Nutzung von Ailoot finden Sie in der [Dokumentation](https://ailoot.ai/docs/).



## Was sind Security Agents in Cursor?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Das Wichtigste in diesem Abschnitt">

Das Wichtigste

Security Agents sind zwei Arten von von Cursor verwalteten Agents in Automations. Security Reviewer prüft einen Pull Request, bevor er zusammengeführt wird. Vulnerability Scanner scannt den Codebestand nach einem Zeitplan und sucht nach bestehenden Schwachstellen, lang anhaltenden Problemen und allem, was bei der PR-Prüfung übersehen wurde. Beide Arten erfordern Cloud Agents und laufen darauf; die Ausnahme ist ein teamweiter Security Reviewer, der durch ein Pull-Request-Ereignis ausgelöst wird: Diese Prüfung läuft auf dem Hosting von Cursor und nicht in einem Cloud Agent. Die Nutzung wird vom Nutzungskontingent des Teams abgezogen.

</div>

Der Agent-Typ bestimmt, wie eine Prüfung gestartet wird:

- **Security Reviewer** wird durch Git-Ereignisse ausgelöst: einen Pull Request oder Merge Request.
- **Vulnerability Scanner** läuft nach einem Cron-Zeitplan und scannt den Codebestand unabhängig von PR-Aktivitäten.

Mit Cron können Sie wiederkehrende Scanner-Läufe planen.

## Security Reviewer und Vulnerability Scanner aktivieren

### Schritte

1.  Öffnen Sie Security Agents in Automations (der Abschnitt wird in der [Security-Agents-Dokumentation](https://cursor.com/docs/security-agents.md) beschrieben).
2.  Wählen Sie den Agent-Typ: Security Reviewer (PR-Prüfung) oder Vulnerability Scanner (geplantes Scannen).
3.  Konfigurieren Sie für Security Reviewer einen Git-Auslöser: ein Pull-Request- oder Merge-Request-Ereignis. Konfigurieren Sie für Vulnerability Scanner einen Cron-Zeitplan.
4.  Aktivieren oder deaktivieren Sie die integrierten Sicherheitsprüfungen: Beide Agent-Typen verfügen darüber, und Sie können die Auswahl an die Aufgabe anpassen.
5.  Verbinden Sie ein Tool oder einen MCP-Server: Damit kann der Agent eine Verbindung zu den Systemen herstellen, in denen das Team seine Sicherheitsarbeit verwaltet. Für Security Reviewer ist dies erforderlich: Ohne mindestens eine Tool- oder MCP-Verbindung können Sie ihn nicht speichern. Vulnerability Scanner kann ohne solche Verbindungen gespeichert werden und sendet seine Ergebnisse an die Liste „Flagged Vulnerabilities“.
6.  Speichern Sie den Agent.

Mit Tools und MCP können Sie vom Agent gefundene Schwachstellen an einen Slack-Kanal, einen Issue-Tracker oder ein anderes verbundenes System senden.

### Überprüfung

Der Automations-Verlauf zeigt, wann jeder Agent ausgeführt wurde, welche Tools er verwendet hat, wie der Lauf endete und wie lange er dauerte. Wenn eine Security-Reviewer-Prüfung auf dem Hosting von Cursor ausgeführt wurde, sehen Sie unter **Recent Runs** auf der Seite Security Agents nach: Sie können die Prüfsitzung im schreibgeschützten Modus öffnen.

Die Ergebnisse von Vulnerability Scanner erscheinen unter **Flagged Vulnerabilities** auf der Seite Security Agents und auf der Seite des jeweiligen Scanners. Die Liste ist nach Repository gruppiert; Sie können die Ergebnisse nach Scanner, Status, Feedback und Schweregrad filtern. Für jedes Ergebnis gibt es die Aktion **Fix in Cursor**, die einen Cloud Agent startet, um die Schwachstelle zu beheben.

### Fehler

Wenn Security Reviewer nicht gespeichert werden kann, prüfen Sie, ob mindestens eine Tool- oder MCP-Verbindung konfiguriert ist: Ohne eine solche Verbindung schlägt das Speichern fehl.





## Wer die Prüfungen bezahlt: Nutzung von Security Agents

Laut Dokumentation wird die Nutzung von Security Agents vom Nutzungskontingent des Teams abgezogen. Die Agents laufen unter dem gemeinsamen Dienstkonto des Teams und verbrauchen daher nicht das Kontingent eines einzelnen Mitglieds.

Auf der Dokumentationsseite werden weder Preise noch die Tarife angegeben, in denen Security Agents enthalten sind. Prüfen Sie vor der Aktivierung für alle Repositories, ob die Funktion in Ihrem Konto verfügbar ist und wie viel die ersten Läufe vom Teamkontingent verbrauchen.

## Unterschiede zwischen Security Reviewer, /review-security und Bugbot

Diese Mechanismen verfolgen ähnliche Ziele, werden aber auf unterschiedliche Weise gestartet.

**`/review-security` und `/review`** können vor dem Pushen von Code in ein entferntes Repository manuell über den Agent ausgeführt werden. Standardmäßig prüft `/review-security` die Änderungen des Branches im Vergleich zum Basis-Branch, einschließlich sowohl bereits in Commits gespeicherter als auch noch nicht committeter Änderungen. Sie können die Prüfung auf Letztere beschränken. Die Befehle sind in Cursor 3.7 und höher, auf cursor.com/agents und in der Cursor CLI verfügbar. Sie entscheiden, wann Sie die Prüfung ausführen.

**Security Reviewer** ist ein Agent in Automations, der automatisch durch einen Git-Auslöser ausgeführt wird.

**Bugbot** ist ein separates Cursor-Produkt zur PR-Prüfung. Laut Dokumentation sucht es nach Bugs, Schwachstellen und Problemen mit der Codequalität und hinterlässt Kommentare mit Erklärungen und Lösungsvorschlägen. Es läuft automatisch, sobald ein PR aktualisiert wird, oder manuell.

Security Agents sind für Sicherheitsprüfungen vorgesehen: Sie verfügen über integrierte Prüfungen, geplante Scans des gesamten Repositorys und eine Liste „Flagged Vulnerabilities“ mit Status und Schweregraden. Die Dokumentation vergleicht nicht die Qualität der Ergebnisse von Bugbot und Security Agents.

## Rollouts: Überwachung nach der Bereitstellung

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Das Wichtigste in diesem Abschnitt">

Das Wichtigste

Rollouts (nur in den Tarifen Teams und Enterprise verfügbar) erstellt beim Öffnen eines PR einen Überwachungsplan und prüft nach der Bereitstellung die Änderung anhand von Telemetriedaten (Logs, Metriken und Traces): sofort und anschließend nach 20 Minuten, 1 Stunde, 1 Tag und 3 Tagen. Wenn eine Regression gefunden wird – eine Verschlechterung nach der Änderung –, wird ein Issue eröffnet, und Sie können auf eine Schaltfläche klicken, um einen Cloud Agent zur Behebung zu starten. Rollouts führt selbst keine Änderungen zusammen, setzt sie nicht zurück und rollt sie nicht zurück. Ohne verbundene Telemetriedaten bleiben Änderungen ausstehend, und Rollouts kann keine Probleme finden.

</div>

### Was Rollouts macht

Wenn ein Pull Request geöffnet wird, liest Rollouts die Änderungen und die betroffenen Systeme und erstellt einen Überwachungsplan für die Bereitstellung. Der Plan listet die erkannten Risiken, die erwartete Wirkung der Änderung, zu prüfende Signale und Lücken bei der Datenerfassung auf, die eine Überprüfung der Änderung erschweren. Auf GitHub, GitLab.com und Bitbucket Cloud erscheint der Plan als PR-Kommentar.

Rollouts führt bei Bereitstellungsereignissen Prüfungen aus und vergleicht den Plan mit Logs, Metriken und Traces. Jede Umgebung wird separat überwacht: Eine Änderung kann die Prüfungen in einer Testumgebung bestehen und in der Produktionsumgebung dennoch als problematisch gekennzeichnet werden. Die Prüfungen laufen zum Zeitpunkt der Bereitstellung sowie nach 20 Minuten, 1 Stunde, 1 Tag und 3 Tagen.

Wird eine Regression gefunden, ermittelt Rollouts die Änderung, die dafür verantwortlich sein könnte, eröffnet ein Issue und benachrichtigt den Autor. Auf der Issue-Seite startet die Schaltfläche **Fix issue** einen Cloud Agent. Rollouts führt selbst keine Änderungen zusammen, setzt sie nicht zurück und rollt sie nicht zurück.

### Rollouts konfigurieren

1.  Klicken Sie in Automations auf **Enable** auf der Rollouts-Karte unter **From Cursor**.
2.  Wählen Sie die zu überwachenden Repositories aus. In den Einstellungen können Sie bis zu 200 Repositories angeben.
3.  Konfigurieren Sie Bereitstellungsereignisse: Rollouts muss wissen, wann jede Produktionsbereitstellung beginnt und endet. Erstellen Sie dazu einen Cursor-API-Schlüssel und speichern Sie ihn als `CURSOR_API_KEY` in den Secrets Ihres Build-Systems (CI). Anschließend gibt es zwei Möglichkeiten: Fügen Sie die Aufrufe manuell zum Bereitstellungsprozess hinzu (die Befehle stehen im Abschnitt „Send deployment events“ der [Rollouts-Dokumentation](https://cursor.com/docs/rollouts.md)) oder bitten Sie den Setup-Agent, dies zu erledigen. Der Agent öffnet einen PR mit diesen Aufrufen. Führen Sie diesen PR zusammen, um die Einrichtung abzuschließen.
4.  Verbinden Sie Telemetriedaten, beispielsweise Datadog. Mindestens ein verbundenes Tool ist erforderlich.
5.  Legen Sie fest, wie PR-Autoren Benachrichtigungen erhalten sollen.

### Leicht zu übersehende Einschränkungen

Ohne verbundene Telemetriedaten bleiben Änderungen ausstehend, und Rollouts kann keine Probleme erkennen. Wenn das Projekt noch kein System wie Datadog zur Überwachung hat, benötigen Sie zunächst ein solches System.

Slack-Benachrichtigungen sind im Privacy Mode nicht verfügbar. Ein Teamadministrator muss Rollouts zuerst zu Slack hinzufügen.

## Für wen sich das eignet und wer noch warten sollte

Wenn Sie allein arbeiten, prüfen Sie vor der Aktivierung, ob Security Agents in Ihrem Konto verfügbar sind: Die Nutzung wird aus dem Teamkontingent abgezogen, und auf der Dokumentationsseite sind die berechtigten Tarife nicht aufgeführt. Die Behebung einer vom Scanner gefundenen Schwachstelle starten Sie selbst: **Fix in Cursor** öffnet einen Cloud Agent, der im Repository arbeitet.

Laut Dokumentation ist Rollouts nur in den Tarifen Teams und Enterprise verfügbar. Wenn Sie noch kein Überwachungssystem wie Datadog haben, beginnen Sie damit und verbinden Sie anschließend Rollouts.

Weitere Informationen zu Cursor-Tarifen finden Sie unter [Was ein Cursor-Abonnement umfasst](https://ailoot.ai/blog/de/cursor-subscription/). Wenn Sie die Aufgabenkoordination zwischen Agents in Cursor bereits eingerichtet haben, lesen Sie [Cursor Projects: Wie der Koordinator Aufgaben delegiert](https://ailoot.ai/blog/de/cursor-projects-coordinator-agents/).

## Zusammenfassung

Security Reviewer prüft PRs vor dem Zusammenführen; Vulnerability Scanner scannt das gesamte Repository nach einem Zeitplan. Die Nutzung beider Agent-Typen wird vom Teamkontingent abgezogen. Rollouts überwacht eine Änderung nach der Bereitstellung, ist in den Tarifen Teams und Enterprise verfügbar und erfordert mindestens eine verbundene Telemetriequelle.

<div class="section" role="doc-bibliography" aria-label="Quellen">

### Quellen

- Cursor Docs, Security Agents: <https://cursor.com/docs/security-agents.md>
- Cursor Docs, Rollouts: <https://cursor.com/docs/rollouts.md>
- Cursor Docs, Bugbot: <https://cursor.com/docs/bugbot.md>

</div>





Lernen Sie [Ailoot](https://ailoot.ai/) kennen.

## Fragen und Antworten

### Warum kann ich einen Security Reviewer nicht speichern?

Die hier beschriebene Einrichtung verlangt für Security Reviewer mindestens ein verbundenes Tool oder einen MCP-Server. Prüfe die Verbindung vor dem Speichern. Vulnerability Scanner kann Funde dagegen auch ohne diese Verbindung unter Flagged Vulnerabilities veröffentlichen.

### Nimmt Rollouts eine fehlerhafte Bereitstellung automatisch zurück?

Nein. Es vergleicht Änderungen mit verbundener Telemetrie und kann bei einer Regression ein Issue eröffnen. Über Fix issue kannst du einen Cloud-Agenten starten. Rollouts selbst führt weder Merge noch Revert oder Rollback aus.


## Ailoot · Das Unternehmen und sein Projektportfolio

Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle.

Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe.

Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.
