# Security Agents i Rollouts w Cursor: kontrole bezpieczeństwa i monitorowanie wydań
> Jak włączyć Security Reviewer, Vulnerability Scanner i Rollouts w Cursor Automations: wyzwalacze, korzystanie ze wspólnej puli zespołu, plany i różnice w porównaniu z Bugbot.
Source: https://ailoot.ai/blog/pl/cursor-rollouts-security-agents/
Canonical: https://ailoot.ai/blog/pl/cursor-rollouts-security-agents/
Language: pl
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-089
Revision: sha256-9475370960edec6d812c58732c0c4b9d2ef4811a47c32577b353c7320aced269
W Cursor Automations możesz skonfigurować kontrole bezpieczeństwa kodu i monitorowanie wydań. Security Agents przeglądają pull requesty (PR) i skanują całe repozytorium według harmonogramu. Rollouts monitoruje zmianę po wdrożeniu, jest dostępne w planach Teams i Enterprise oraz wymaga podłączonej telemetrii: logów, metryk i śladów.
Poniżej znajdziesz oparte na oficjalnej dokumentacji Cursor instrukcje konfiguracji, informacje o sposobie rozliczania użycia Security Agents, ograniczeniach planów oraz różnicach w porównaniu z Bugbot i ręcznym poleceniem `/review-security`.
Informacje o korzystaniu z Ailoot znajdziesz w [dokumentacji](https://ailoot.ai/docs/).
## Czym są Security Agents w Cursor?
Najważniejsze informacje
Security Agents to dwa typy agentów zarządzanych przez Cursor w Automations. Security Reviewer sprawdza pull request przed jego scaleniem. Vulnerability Scanner skanuje bazę kodu według harmonogramu, szukając istniejących podatności, długotrwałych problemów i wszystkiego, co pominięto podczas przeglądu PR. Oba typy wymagają Cloud Agents i działają w ich środowisku. Wyjątkiem jest zespołowy Security Reviewer uruchamiany przez zdarzenie pull requestu: taki przegląd działa w środowisku hostingowym Cursor, a nie w agencie chmurowym. Użycie jest odejmowane od puli zespołu.
Typ agenta określa sposób rozpoczęcia kontroli:
- **Security Reviewer** jest uruchamiany przez zdarzenia Git: pull request lub merge request.
- **Vulnerability Scanner** działa według harmonogramu cron i skanuje bazę kodu niezależnie od aktywności PR.
Cron pozwala zaplanować cykliczne uruchomienia skanera.
## Jak włączyć Security Reviewer i Vulnerability Scanner
### Kroki
1. Otwórz Security Agents w Automations (ta sekcja jest opisana w [dokumentacji Security Agents](https://cursor.com/docs/security-agents.md)).
2. Wybierz typ agenta: Security Reviewer (przegląd PR) lub Vulnerability Scanner (skanowanie według harmonogramu).
3. W przypadku Security Reviewer skonfiguruj wyzwalacz Git: zdarzenie pull requestu lub merge requestu. W przypadku Vulnerability Scanner skonfiguruj harmonogram cron.
4. Włącz lub wyłącz wbudowane kontrole bezpieczeństwa: oba typy agentów je mają, a ich zestaw możesz dostosować do zadania.
5. Podłącz narzędzie lub serwer MCP: umożliwiają one agentowi łączenie się z systemami, w których zespół zarządza pracami związanymi z bezpieczeństwem. W przypadku Security Reviewer jest to wymagane: nie można go zapisać bez co najmniej jednego połączenia z narzędziem lub MCP. Vulnerability Scanner można zapisać bez takich połączeń; wyniki skanowania trafiają wtedy na listę Flagged Vulnerabilities.
6. Zapisz agenta.
Narzędzia i MCP pozwalają wysyłać wykryte przez agenta podatności do kanału Slack, systemu śledzenia zgłoszeń lub innego podłączonego systemu.
### Weryfikacja
Historia Automations pokazuje, kiedy uruchomił się każdy agent, jakich narzędzi użył, jaki był wynik uruchomienia i ile ono trwało. Aby sprawdzić Security Reviewer uruchomiony w środowisku hostingowym Cursor, przejdź do **Recent Runs** na stronie Security Agents: sesję przeglądu możesz otworzyć w trybie tylko do odczytu.
Wyniki Vulnerability Scanner pojawiają się w sekcji **Flagged Vulnerabilities** na stronie Security Agents i na stronie każdego skanera. Lista jest pogrupowana według repozytorium; wyniki możesz filtrować według skanera, statusu, opinii i poziomu ważności. Każdy wynik ma akcję **Fix in Cursor**, która uruchamia agenta chmurowego, aby naprawił podatność.
### Błędy
Jeśli nie można zapisać Security Reviewer, sprawdź, czy skonfigurowano co najmniej jedno połączenie z narzędziem lub MCP: bez niego zapis się nie powiedzie.
## Kto płaci za kontrole: użycie Security Agents
Zgodnie z dokumentacją użycie Security Agents jest odejmowane od puli zespołu. Agenty działają na wspólnym koncie usługi zespołu, więc nie zużywają limitu pojedynczego członka.
Strona dokumentacji nie podaje cen ani planów obejmujących Security Agents. Przed włączeniem ich we wszystkich repozytoriach sprawdź dostępność w swoim koncie i zobacz, ile z puli zespołu zużywają pierwsze uruchomienia.
## Czym Security Reviewer różni się od /review-security i Bugbot
Te mechanizmy mają podobne cele, ale są uruchamiane w inny sposób.
**`/review-security` i `/review`** można uruchomić ręcznie z poziomu agenta przed wypchnięciem kodu do zdalnego repozytorium. Domyślnie `/review-security` sprawdza zmiany w gałęzi w porównaniu z gałęzią bazową, uwzględniając zarówno zmiany zapisane już w commitach, jak i te, które nie zostały jeszcze zacommitowane. Możesz poprosić o ograniczenie przeglądu do tych drugich. Polecenia są dostępne w Cursor 3.7 i nowszych wersjach, na cursor.com/agents oraz w Cursor CLI. Samodzielnie decydujesz, kiedy uruchomić przegląd.
**Security Reviewer** to agent w Automations, który uruchamia się automatycznie po wyzwalaczu Git.
**Bugbot** to osobny produkt Cursor do przeglądu PR. Zgodnie z dokumentacją wyszukuje błędy, podatności i problemy z jakością kodu, pozostawiając komentarze z wyjaśnieniami i sugerowanymi poprawkami. Uruchamia się automatycznie po każdej aktualizacji PR albo ręcznie.
Security Agents są przeznaczone do kontroli bezpieczeństwa: mają wbudowane kontrole, skanują całe repozytorium według harmonogramu i udostępniają listę Flagged Vulnerabilities ze statusami oraz poziomami ważności. Dokumentacja nie porównuje jakości wyników Bugbot i Security Agents.
## Rollouts: monitorowanie po wdrożeniu
Najważniejsze informacje
Rollouts (tylko w planach Teams i Enterprise) tworzy plan monitorowania po otwarciu PR, a po wdrożeniu sprawdza zmianę na podstawie telemetrii (logów, metryk i śladów): natychmiast, a następnie po 20 minutach, 1 godzinie, 1 dniu i 3 dniach. Jeśli wykryje regresję — pogorszenie po wprowadzeniu zmiany — otwiera zgłoszenie, a kliknięcie przycisku uruchamia agenta chmurowego do jej naprawy. Rollouts samo nie scala, nie cofa ani nie przywraca zmian. Bez podłączonej telemetrii zmiany pozostają oczekujące, a Rollouts nie może wykrywać problemów.
### Co robi Rollouts
Po otwarciu pull requestu Rollouts analizuje zmiany i dotknięte nimi systemy, a następnie tworzy plan monitorowania wdrożenia. Plan wymienia rozpoznane ryzyka, przewidywany wpływ zmiany, sygnały do sprawdzenia oraz braki w zbieraniu danych, które utrudniają weryfikację zmiany. W GitHub, GitLab.com i Bitbucket Cloud plan pojawia się jako komentarz do PR.
Rollouts uruchamia kontrole przy zdarzeniach wdrożenia i porównuje plan z logami, metrykami i śladami. Każde środowisko jest śledzone oddzielnie: zmiana może przejść kontrole w środowisku testowym, a mimo to zostać oznaczona jako problematyczna w środowisku produkcyjnym. Kontrole są uruchamiane w chwili wdrożenia, a następnie po 20 minutach, 1 godzinie, 1 dniu i 3 dniach.
Jeśli zostanie wykryta regresja, Rollouts wskazuje podejrzewaną zmianę, która ją spowodowała, otwiera zgłoszenie i powiadamia autora. Przycisk **Fix issue** na stronie zgłoszenia uruchamia agenta chmurowego. Rollouts samo nie scala, nie cofa ani nie przywraca zmian.
### Jak skonfigurować Rollouts
1. W Automations kliknij **Enable** na karcie Rollouts w sekcji **From Cursor**.
2. Wybierz repozytoria do monitorowania. W ustawieniach możesz wskazać maksymalnie 200 repozytoriów.
3. Skonfiguruj zdarzenia wdrożenia: Rollouts musi wiedzieć, kiedy rozpoczyna się i kończy każde wdrożenie produkcyjne. W tym celu utwórz klucz API Cursor i zapisz go w sekretach systemu budowania (CI) jako `CURSOR_API_KEY`. Następnie możesz wybrać jedną z dwóch opcji: ręcznie dodać wywołania do procesu wdrożenia (polecenia znajdują się w sekcji Send deployment events w [dokumentacji Rollouts](https://cursor.com/docs/rollouts.md)) albo poprosić agenta konfigurującego o wykonanie tej czynności. Agent otworzy PR zawierający te wywołania. Scal ten PR, aby zakończyć konfigurację.
4. Podłącz telemetrię, na przykład Datadog. Wymagane jest co najmniej jedno podłączone narzędzie.
5. Wybierz sposób powiadamiania autorów PR.
### Łatwe do przeoczenia ograniczenia
Bez podłączonej telemetrii zmiany pozostają oczekujące, a Rollouts nie może wykrywać problemów. Jeśli projekt nie ma jeszcze Datadog ani podobnego systemu monitorowania, najpierw trzeba go skonfigurować.
Powiadomienia Slack są niedostępne w Privacy Mode. Administrator zespołu musi najpierw dodać Rollouts do Slacka.
## Dla kogo jest to rozwiązanie, a kto powinien poczekać
Jeśli pracujesz samodzielnie, przed włączeniem Security Agents sprawdź, czy są dostępne na Twoim koncie: użycie pochodzi z puli zespołu, a strona dokumentacji nie wymienia kwalifikujących się planów. Naprawę podatności znalezionej przez skaner rozpoczynasz samodzielnie: **Fix in Cursor** otwiera agenta chmurowego, który pracuje w repozytorium.
Zgodnie z dokumentacją Rollouts jest dostępne tylko w planach Teams i Enterprise. Jeśli nie masz jeszcze systemu monitorowania, takiego jak Datadog, najpierw go skonfiguruj, a potem podłącz Rollouts.
Więcej informacji o planach Cursor znajdziesz w artykule [Co zawiera subskrypcja Cursor](https://ailoot.ai/blog/pl/cursor-subscription/). Jeśli masz już skonfigurowaną koordynację zadań między agentami w Cursor, zobacz [Cursor Projects: jak koordynator deleguje zadania](https://ailoot.ai/blog/pl/cursor-projects-coordinator-agents/).
## Podsumowanie
Security Reviewer przegląda PR przed scaleniem; Vulnerability Scanner skanuje całe repozytorium według harmonogramu. Użycie obu typów agentów jest odejmowane od puli zespołu. Rollouts monitoruje zmianę po wdrożeniu, jest dostępne w planach Teams i Enterprise oraz wymaga co najmniej jednego podłączonego źródła telemetrii.
### Źródła
- Cursor Docs, Security Agents:
- Cursor Docs, Rollouts:
- Cursor Docs, Bugbot:
Poznaj [Ailoot](https://ailoot.ai/).
## Pytania i odpowiedzi
### Dlaczego nie mogę zapisać Security Reviewer?
Opisana konfiguracja Security Reviewer wymaga co najmniej jednego podłączonego narzędzia lub serwera MCP. Sprawdź połączenie przed zapisem; Vulnerability Scanner może publikować ustalenia w Flagged Vulnerabilities bez tego połączenia.
### Czy Rollouts automatycznie wycofuje nieudane wdrożenie?
Nie. Porównuje zmiany z podłączoną telemetrią i może otworzyć zgłoszenie po wykryciu regresji. Z Fix issue można uruchomić agenta chmurowego; sam Rollouts nie scala, nie cofa ani nie wycofuje zmian.
## Ailoot · Firma i jej portfel projektów
Ailoot opiera się na zgromadzonym doświadczeniu operacyjnym, szerokiej bazie klientów, stabilnej usłudze i stałej kontroli KPI.
Firma i jej portfel projektów: miliony klientów; miesięczna sprzedaż liczona w miliardach.
Ailoot wykorzystuje to doświadczenie operacyjne, zapewniając dostęp przez API do funkcji AI w produktach klientów, agentach, aplikacjach i automatyzacjach.