# Security Agents e Rollouts no Cursor: verificações de segurança e monitorização de lançamentos
> Como ativar Security Reviewer, Vulnerability Scanner e Rollouts no Cursor Automations: acionadores, utilização do conjunto da equipa, planos e diferenças em relação ao Bugbot.
Source: https://ailoot.ai/blog/pt-pt/cursor-rollouts-security-agents/
Canonical: https://ailoot.ai/blog/pt-pt/cursor-rollouts-security-agents/
Language: pt-PT
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-089
Revision: sha256-eece837650f04e7bff5bf9f2ea4a7cf7f7f3b0853434d818a5c2e6228c604dd6
No Cursor Automations, pode configurar verificações de segurança do código e a monitorização de lançamentos. Security Agents analisam pull requests (PR) e verificam todo o repositório de acordo com um calendário. Rollouts monitoriza uma alteração após a implementação, está disponível nos planos Teams e Enterprise e requer telemetria ligada: registos, métricas e rastos.
Em seguida, apresentamos os passos de configuração com base na documentação oficial do Cursor, a forma como é contabilizada a utilização de Security Agents, as restrições dos planos e as diferenças em relação ao Bugbot e ao comando manual `/review-security`.
Pode encontrar informações sobre a utilização do Ailoot na [documentação](https://ailoot.ai/docs/).
## O que são Security Agents no Cursor
Ponto-chave
Security Agents são dois tipos de agentes geridos pelo Cursor no Automations. Security Reviewer analisa um pull request antes de este ser integrado. Vulnerability Scanner verifica a base de código de acordo com um calendário, procurando vulnerabilidades existentes, problemas antigos e tudo o que tenha passado despercebido durante a análise do PR. Ambos os tipos requerem e utilizam Cloud Agents; a exceção é um Security Reviewer de equipa acionado por um evento de pull request: essa análise é executada no alojamento do Cursor, e não num agente na cloud. A utilização é deduzida do conjunto de utilização da equipa.
O tipo de agente determina como uma verificação é iniciada:
- **Security Reviewer** é acionado por eventos Git: um pull request ou merge request.
- **Vulnerability Scanner** é executado segundo um calendário cron e verifica a base de código independentemente da atividade dos PR.
O cron permite agendar execuções recorrentes do scanner.
## Como ativar Security Reviewer e Vulnerability Scanner
### Passos
1. Abra Security Agents em Automations (a secção está descrita na [documentação de Security Agents](https://cursor.com/docs/security-agents.md)).
2. Escolha o tipo de agente: Security Reviewer (análise de PR) ou Vulnerability Scanner (verificação agendada).
3. Para Security Reviewer, configure um acionador Git: um evento de pull request ou merge request. Para Vulnerability Scanner, configure um calendário cron.
4. Ative ou desative as verificações de segurança incorporadas: estão disponíveis em ambos os tipos de agente e pode ajustar o conjunto de acordo com a tarefa.
5. Ligue uma ferramenta ou servidor MCP: estes permitem ao agente ligar-se aos sistemas onde a equipa gere o seu trabalho de segurança. É obrigatório para Security Reviewer: não pode guardá-lo sem pelo menos uma ligação a uma ferramenta ou MCP. Vulnerability Scanner pode ser guardado sem estas ligações e envia os resultados para a lista Flagged Vulnerabilities.
6. Guarde o agente.
As ferramentas e o MCP permitem enviar as vulnerabilidades encontradas pelo agente para um canal do Slack, um sistema de gestão de problemas ou outro sistema ligado.
### Verificação
O histórico de Automations mostra quando cada agente foi executado, que ferramentas utilizou, como terminou a execução e quanto tempo demorou. No caso de uma verificação de Security Reviewer executada no alojamento do Cursor, consulte **Recent Runs** na página de Security Agents: pode abrir a sessão de análise em modo só de leitura.
Os resultados do Vulnerability Scanner aparecem em **Flagged Vulnerabilities**, na página de Security Agents e na página de cada scanner. A lista está agrupada por repositório; pode filtrar os resultados por scanner, estado, feedback e gravidade. Cada resultado tem a ação **Fix in Cursor**, que inicia um agente na cloud para corrigir a vulnerabilidade.
### Erros
Se não for possível guardar Security Reviewer, confirme que está configurada pelo menos uma ligação a uma ferramenta ou MCP: sem ela, a gravação falha.
## Quem paga as verificações: utilização de Security Agents
De acordo com a documentação, a utilização de Security Agents é deduzida do conjunto de utilização da equipa. Os agentes são executados com a conta de serviço partilhada da equipa, pelo que não consomem a franquia de cada membro individual.
A página de documentação não especifica os preços nem quais os planos que incluem Security Agents. Antes de os ativar em todos os repositórios, confirme a disponibilidade na sua conta e verifique quanto é consumido do conjunto da equipa pelas primeiras execuções.
## Diferenças entre Security Reviewer, /review-security e Bugbot
Estes mecanismos têm objetivos semelhantes, mas são iniciados de formas diferentes.
**`/review-security` e `/review`** podem ser executados manualmente a partir do agente antes de enviar o código para um repositório remoto. Por predefinição, `/review-security` verifica as alterações do ramo em relação ao ramo base, incluindo tanto as alterações já guardadas em commits como as que ainda não foram confirmadas. Pode pedir-lhe que limite a análise às últimas. Os comandos estão disponíveis no Cursor 3.7 e posteriores, em cursor.com/agents e na CLI do Cursor. Cabe-lhe decidir quando executar a análise.
**Security Reviewer** é um agente em Automations que é executado automaticamente quando ocorre um acionador Git.
**Bugbot** é um produto separado do Cursor para análise de PR. De acordo com a documentação, procura erros, vulnerabilidades e problemas de qualidade do código, deixando comentários com explicações e sugestões de correção. É executado automaticamente sempre que um PR é atualizado, ou manualmente.
Security Agents foram concebidos para verificações de segurança: incluem verificações incorporadas, análises agendadas de todo o repositório e uma lista Flagged Vulnerabilities com estados e níveis de gravidade. A documentação não compara a qualidade dos resultados do Bugbot e de Security Agents.
## Rollouts: monitorização após a implementação
Ponto-chave
Rollouts (disponível apenas nos planos Teams e Enterprise) cria um plano de monitorização quando é aberto um PR e, após a implementação, verifica a alteração com base na telemetria (registos, métricas e rastos): imediatamente, depois ao fim de 20 minutos, 1 hora, 1 dia e 3 dias. Se detetar uma regressão — uma deterioração na sequência da alteração — abre um problema, e pode clicar num botão para iniciar um agente na cloud que a corrija. O próprio Rollouts não integra, reverte nem faz rollback das alterações. Sem telemetria ligada, as alterações ficam pendentes e Rollouts não consegue detetar problemas.
### O que faz Rollouts
Quando é aberto um pull request, Rollouts lê as alterações e os sistemas afetados e cria um plano de monitorização da implementação. O plano enumera os riscos identificados, o efeito esperado da alteração, os sinais a verificar e as lacunas na recolha de dados que dificultam a verificação da alteração. No GitHub, GitLab.com e Bitbucket Cloud, o plano aparece como um comentário no PR.
Rollouts executa verificações quando ocorrem eventos de implementação e compara o plano com os registos, as métricas e os rastos. Cada ambiente é monitorizado separadamente: uma alteração pode passar nas verificações num ambiente de teste e, ainda assim, ser assinalada como problemática em produção. As verificações são executadas no momento da implementação e, depois, ao fim de 20 minutos, 1 hora, 1 dia e 3 dias.
Se for detetada uma regressão, Rollouts identifica a alteração que suspeita tê-la causado, abre um problema e notifica o autor. Na página do problema, o botão **Fix issue** inicia um agente na cloud. O próprio Rollouts não integra, reverte nem faz rollback das alterações.
### Como configurar Rollouts
1. Em Automations, clique em **Enable** no cartão de Rollouts, em **From Cursor**.
2. Escolha os repositórios a monitorizar. Pode especificar até 200 repositórios nas definições.
3. Configure os eventos de implementação: Rollouts precisa de saber quando começa e termina cada implementação em produção. Para isso, crie uma chave de API do Cursor e guarde-a nos segredos do sistema de compilação (CI) como `CURSOR_API_KEY`. Depois, tem duas opções: adicionar manualmente as chamadas ao processo de implementação (os comandos estão na secção Send deployment events da [documentação de Rollouts](https://cursor.com/docs/rollouts.md)) ou pedir ao agente de configuração que o faça. O agente abrirá um PR com estas chamadas. Integre esse PR para concluir a configuração.
4. Ligue a telemetria, como o Datadog. É necessária pelo menos uma ferramenta ligada.
5. Escolha como os autores de PR vão receber notificações.
### Restrições fáceis de ignorar
Sem telemetria ligada, as alterações ficam pendentes e Rollouts não consegue detetar problemas. Se o projeto ainda não tiver Datadog ou um sistema de monitorização semelhante, terá de começar por o configurar.
As notificações do Slack não estão disponíveis no Privacy Mode. Um administrador da equipa tem de adicionar primeiro Rollouts ao Slack.
## Quem precisa disto e quem deve esperar
Se trabalha sozinho, confirme se Security Agents estão disponíveis na sua conta antes de os ativar: a utilização é descontada do conjunto da equipa e a página de documentação não indica os planos elegíveis. É você que inicia a correção de uma vulnerabilidade encontrada pelo scanner: **Fix in Cursor** abre um agente na cloud para trabalhar no repositório.
De acordo com a documentação, Rollouts está disponível apenas nos planos Teams e Enterprise. Se ainda não tiver um sistema de monitorização, como o Datadog, comece por configurá-lo e ligue Rollouts depois.
Para saber mais sobre os planos do Cursor, consulte [o que inclui uma subscrição do Cursor](https://ailoot.ai/blog/pt-pt/cursor-subscription/). Se já tiver configurada a coordenação de tarefas entre agentes no Cursor, consulte [Cursor Projects: como o coordenador delega tarefas](https://ailoot.ai/blog/pt-pt/cursor-projects-coordinator-agents/).
## Resumo
Security Reviewer analisa PR antes da integração; Vulnerability Scanner verifica todo o repositório segundo um calendário. A utilização de ambos os tipos de agente é deduzida do conjunto da equipa. Rollouts monitoriza uma alteração após a implementação, está disponível nos planos Teams e Enterprise e requer pelo menos uma fonte de telemetria ligada.
### Fontes
- Cursor Docs, Security Agents:
- Cursor Docs, Rollouts:
- Cursor Docs, Bugbot:
Conheça o [Ailoot](https://ailoot.ai/).
## Perguntas frequentes
### Porque não consigo guardar um Security Reviewer?
A configuração aqui descrita exige pelo menos uma ferramenta ou servidor MCP ligado ao Security Reviewer. Verifique essa ligação antes de guardar; o Vulnerability Scanner pode publicar em Flagged Vulnerabilities sem essa ligação.
### O Rollouts reverte automaticamente uma implementação com problemas?
Não. Compara alterações com a telemetria ligada e pode abrir uma issue ao detetar uma regressão. Pode iniciar um agente na nuvem por Fix issue; o próprio Rollouts não integra, reverte nem desfaz implementações.
## Ailoot · A empresa e a sua carteira de projetos
A Ailoot assenta numa experiência operacional consolidada, numa ampla base de clientes, num serviço estável e no acompanhamento contínuo dos KPI.
A empresa e a sua carteira de projetos: milhões de clientes; vendas mensais na ordem dos milhares de milhões.
A Ailoot aplica essa experiência operacional ao acesso por API a funcionalidades de IA nos produtos dos clientes, agentes, aplicações e automatizações.