# Security Agents e Rollouts in Cursor: controlli di sicurezza e monitoraggio dei rilasci
> Come abilitare Security Reviewer, Vulnerability Scanner e Rollouts in Cursor Automations: trigger, utilizzo del pool del team, piani e differenze rispetto a Bugbot.
Source: https://ailoot.ai/blog/it/cursor-rollouts-security-agents/
Canonical: https://ailoot.ai/blog/it/cursor-rollouts-security-agents/
Language: it
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-089
Revision: sha256-125c8bd833f8a452b8b079236f68ebe90ecef06d196c8fd804c557b0b6a220d4
In Cursor Automations puoi configurare controlli di sicurezza del codice e il monitoraggio dei rilasci. Security Agents esaminano le pull request (PR) e scansionano l'intero repository secondo una pianificazione. Rollouts monitora una modifica dopo il deployment, è disponibile con i piani Teams ed Enterprise e richiede dati di telemetria collegati: log, metriche e tracce.
Di seguito trovi i passaggi di configurazione basati sulla documentazione ufficiale di Cursor, il modo in cui viene conteggiato l'utilizzo di Security Agents, le limitazioni dei piani e le differenze rispetto a Bugbot e al comando manuale `/review-security`.
Le informazioni sull'utilizzo di Ailoot sono disponibili nella [documentazione](https://ailoot.ai/docs/).
## Cosa sono Security Agents in Cursor
Punto chiave
Security Agents sono due tipi di agenti gestiti da Cursor in Automations. Security Reviewer esamina una pull request prima che venga unita. Vulnerability Scanner scansiona la base di codice secondo una pianificazione, cercando vulnerabilità esistenti, problemi di lunga data e tutto ciò che è sfuggito alla revisione della PR. Entrambi i tipi richiedono e utilizzano Cloud Agents; l'eccezione è un Security Reviewer di team attivato da un evento di pull request: tale revisione viene eseguita sull'infrastruttura di hosting di Cursor anziché in un agente cloud. L'utilizzo viene detratto dal pool di utilizzo del team.
Il tipo di agente determina come viene avviato un controllo:
- **Security Reviewer** viene attivato da eventi Git: una pull request o una merge request.
- **Vulnerability Scanner** viene eseguito secondo una pianificazione cron e scansiona la base di codice indipendentemente dall'attività delle PR.
Cron consente di pianificare le esecuzioni ricorrenti dello scanner.
## Come abilitare Security Reviewer e Vulnerability Scanner
### Passaggi
1. Apri Security Agents in Automations (la sezione è descritta nella [documentazione di Security Agents](https://cursor.com/docs/security-agents.md)).
2. Scegli il tipo di agente: Security Reviewer (revisione delle PR) o Vulnerability Scanner (scansione pianificata).
3. Per Security Reviewer, configura un trigger Git: un evento di pull request o merge request. Per Vulnerability Scanner, configura una pianificazione cron.
4. Abilita o disabilita i controlli di sicurezza integrati: sono disponibili per entrambi i tipi di agente e puoi adattarne l'insieme all'attività.
5. Collega uno strumento o un server MCP: consentono all'agente di collegarsi ai sistemi in cui il team gestisce il proprio lavoro di sicurezza. Per Security Reviewer è obbligatorio: non puoi salvarlo senza almeno una connessione a uno strumento o a un MCP. Vulnerability Scanner può essere salvato anche senza tali connessioni e invia i risultati all'elenco Flagged Vulnerabilities.
6. Salva l'agente.
Gli strumenti e MCP consentono di inviare le vulnerabilità rilevate dall'agente a un canale Slack, a un tracker di problemi o a un altro sistema collegato.
### Verifica
La cronologia di Automations mostra quando è stato eseguito ciascun agente, quali strumenti ha usato, come si è conclusa l'esecuzione e quanto è durata. Per un controllo di Security Reviewer eseguito sull'infrastruttura di hosting di Cursor, consulta **Recent Runs** nella pagina Security Agents: puoi aprire la sessione di revisione in modalità di sola lettura.
I risultati di Vulnerability Scanner compaiono in **Flagged Vulnerabilities** nella pagina Security Agents e nella pagina di ogni scanner. L'elenco è raggruppato per repository; puoi filtrare i risultati per scanner, stato, feedback e gravità. Ciascun risultato include l'azione **Fix in Cursor**, che avvia un agente cloud per correggere la vulnerabilità.
### Errori
Se non riesci a salvare Security Reviewer, verifica che sia configurata almeno una connessione a uno strumento o a un MCP: senza, il salvataggio non riesce.
## Chi paga i controlli: utilizzo di Security Agents
Secondo la documentazione, l'utilizzo di Security Agents viene detratto dal pool di utilizzo del team. Gli agenti operano con l'account di servizio condiviso del team, quindi non consumano la quota di un singolo membro.
La pagina della documentazione non specifica i prezzi né quali piani includano Security Agents. Prima di abilitarli in tutti i repository, verifica la disponibilità nel tuo account e controlla quanto consumano dal pool del team le prime esecuzioni.
## In cosa Security Reviewer differisce da /review-security e Bugbot
Questi meccanismi hanno obiettivi simili, ma si avviano in modi diversi.
**`/review-security` e `/review`** possono essere eseguiti manualmente dall'agente prima di inviare il codice a un repository remoto. Per impostazione predefinita, `/review-security` controlla le modifiche del branch rispetto al branch di base, includendo sia le modifiche già salvate nei commit sia quelle non ancora sottoposte a commit. Puoi chiedergli di limitare la revisione a queste ultime. I comandi sono disponibili in Cursor 3.7 e versioni successive, su cursor.com/agents e nella CLI di Cursor. Decidi tu quando eseguire la revisione.
**Security Reviewer** è un agente in Automations che viene eseguito automaticamente in risposta a un trigger Git.
**Bugbot** è un prodotto Cursor separato per la revisione delle PR. Secondo la documentazione, cerca bug, vulnerabilità e problemi di qualità del codice, lasciando commenti con spiegazioni e correzioni suggerite. Viene eseguito automaticamente ogni volta che una PR viene aggiornata oppure manualmente.
Security Agents sono progettati per i controlli di sicurezza: includono controlli integrati, scansioni pianificate dell'intero repository e un elenco Flagged Vulnerabilities con stati e livelli di gravità. La documentazione non confronta la qualità dei risultati di Bugbot e Security Agents.
## Rollouts: monitoraggio dopo il deployment
Punto chiave
Rollouts (solo piani Teams ed Enterprise) scrive un piano di monitoraggio quando viene aperta una PR e, dopo il deployment, verifica la modifica rispetto ai dati di telemetria (log, metriche e tracce): subito, poi dopo 20 minuti, 1 ora, 1 giorno e 3 giorni. Se rileva una regressione, cioè un peggioramento successivo alla modifica, apre un problema e puoi fare clic su un pulsante per avviare un agente cloud che lo corregga. Rollouts non unisce, ripristina né annulla le modifiche. Senza dati di telemetria collegati, le modifiche restano in sospeso e Rollouts non può individuare i problemi.
### Cosa fa Rollouts
Quando viene aperta una pull request, Rollouts legge le modifiche e i sistemi interessati e crea un piano di monitoraggio del deployment. Il piano elenca i rischi individuati, l'effetto atteso della modifica, i segnali da controllare e le lacune nella raccolta dei dati che rendono difficile verificare la modifica. Su GitHub, GitLab.com e Bitbucket Cloud, il piano compare come commento alla PR.
Rollouts esegue controlli sugli eventi di deployment e confronta il piano con log, metriche e tracce. Ogni ambiente viene monitorato separatamente: una modifica può superare i controlli in un ambiente di test e venire comunque segnalata come problematica in produzione. I controlli vengono eseguiti al momento del deployment, poi dopo 20 minuti, 1 ora, 1 giorno e 3 giorni.
Se viene rilevata una regressione, Rollouts individua la modifica che ritiene ne sia la causa, apre un problema e avvisa l'autore. Nella pagina del problema, il pulsante **Fix issue** avvia un agente cloud. Rollouts non unisce, ripristina né annulla le modifiche autonomamente.
### Come configurare Rollouts
1. In Automations, fai clic su **Enable** nella scheda Rollouts in **From Cursor**.
2. Scegli i repository da monitorare. Nelle impostazioni puoi specificarne fino a 200.
3. Configura gli eventi di deployment: Rollouts deve sapere quando inizia e termina ogni deployment in produzione. Per farlo, crea una chiave API di Cursor e salvala nei segreti del sistema di build (CI) con il nome `CURSOR_API_KEY`. Hai quindi due opzioni: aggiungere manualmente le chiamate al processo di deployment (i comandi si trovano nella sezione Send deployment events della [documentazione di Rollouts](https://cursor.com/docs/rollouts.md)) oppure chiedere all'agente di configurazione di farlo. L'agente aprirà una PR contenente queste chiamate. Unisci quella PR per completare la configurazione.
4. Collega dati di telemetria, ad esempio Datadog. È richiesto almeno uno strumento collegato.
5. Scegli come riceveranno le notifiche gli autori delle PR.
### Limitazioni facili da trascurare
Senza dati di telemetria collegati, le modifiche restano in sospeso e Rollouts non può rilevare i problemi. Se il progetto non dispone ancora di Datadog o di un sistema di monitoraggio simile, dovrai prima procurartene uno.
Le notifiche Slack non sono disponibili in Privacy Mode. Un amministratore del team deve prima aggiungere Rollouts a Slack.
## A chi serve e chi dovrebbe aspettare
Se lavori da solo, verifica se Security Agents è disponibile nel tuo account prima di abilitarlo: l'utilizzo viene addebitato al pool del team e la pagina della documentazione non indica quali piani siano idonei. Sei tu ad avviare la correzione di una vulnerabilità rilevata dallo scanner: **Fix in Cursor** apre un agente cloud che opera nel repository.
Secondo la documentazione, Rollouts è disponibile solo con i piani Teams ed Enterprise. Se non disponi ancora di un sistema di monitoraggio come Datadog, inizia da quello e collega Rollouts in seguito.
Per saperne di più sui piani Cursor, consulta [cosa include un abbonamento a Cursor](https://ailoot.ai/blog/it/cursor-subscription/). Se hai già configurato in Cursor il coordinamento delle attività tra agenti, consulta [Cursor Projects: come il coordinatore delega le attività](https://ailoot.ai/blog/it/cursor-projects-coordinator-agents/).
## Riepilogo
Security Reviewer esamina le PR prima dell'unione; Vulnerability Scanner scansiona l'intero repository secondo una pianificazione. L'utilizzo di entrambi i tipi di agente viene detratto dal pool del team. Rollouts monitora una modifica dopo il deployment, è disponibile con i piani Teams ed Enterprise e richiede almeno una fonte di dati di telemetria collegata.
### Fonti
- Cursor Docs, Security Agents:
- Cursor Docs, Rollouts:
- Cursor Docs, Bugbot:
Scopri [Ailoot](https://ailoot.ai/).
## Domande frequenti
### Perché non riesco a salvare un Security Reviewer?
La configurazione descritta richiede almeno uno strumento o server MCP collegato per Security Reviewer. Controlla il collegamento prima di salvare; Vulnerability Scanner può invece pubblicare i risultati in Flagged Vulnerabilities senza quel collegamento.
### Rollouts annulla automaticamente un rilascio difettoso?
No. Confronta le modifiche con la telemetria collegata e può aprire un’issue se rileva una regressione. Puoi avviare un agente cloud da Fix issue; Rollouts non esegue direttamente merge, revert o rollback.
## Ailoot · L’azienda e il suo portafoglio di progetti
Ailoot si basa su un’esperienza operativa consolidata, un’ampia base di clienti, un servizio stabile e un controllo costante dei KPI.
L’azienda e il suo portafoglio di progetti: milioni di clienti; vendite nell’ordine dei miliardi ogni mese.
Ailoot mette questa esperienza operativa al servizio dell’accesso API alle funzioni AI nei prodotti dei clienti, negli agenti, nelle applicazioni e nelle automazioni.