Cursor Security Review es un bot que revisa cada pull request en el contexto de tu código y publica un solo comentario con los bugs de seguridad explotables que encuentra, cada uno con su severidad, la ruta de ataque y una corrección propuesta. Cursor lo lanzó el 23 de septiembre de 2026 junto con Rollouts, un segundo bot que vigila cada cambio después del despliegue. Ambos están disponibles desde ya en los planes Teams y Enterprise.
Cursor los presenta como bots para “la última milla” de entregar código. La mayoría de las herramientas de IA para programar compiten en escribir código; estas dos trabajan en lo que viene después: si es seguro hacer merge y si el cambio se comportó bien una vez que llegó a producción.
¿Qué vulnerabilidades detecta Cursor Security Review?
Security Review busca bugs que un atacante podría explotar, no problemas de estilo. Según el anuncio de lanzamiento, cubre:
- Inyección SQL, de comandos y de plantillas.
- Bypass de autenticación y autorización, incluidos los chequeos que un refactor dejó de ejecutar sin que nadie lo notara.
- Secretos y credenciales subidos al repositorio.
- SSRF y redirecciones sin validar.
- Deserialización insegura.
- Cambios en dependencias que introducen vulnerabilidades conocidas.
Rastrea por dónde entra el input del usuario y por dónde pasa, y eso es lo que lo separa de un linter basado en patrones. Cada hallazgo incluye severidad, ruta de ataque y corrección propuesta. Si descartas un hallazgo indicando el motivo, no vuelve a aparecer en ese mismo PR. Los PR en borrador se omiten.
También puedes agregar reglas propias del equipo, por ejemplo por qué cliente deben pasar las llamadas externas o qué tablas nunca se consultan desde un request handler. Security Review las aplica en cada PR.
¿Cómo se activa Security Review en Cursor?
Se activa desde la página Security Agents del panel de Automations de Cursor, eligiendo los repositorios que quieres revisar. La documentación lo describe como uno de dos tipos de agente gestionados por Cursor. La puesta en marcha cubre:
- Triggers: disparadores de Automations basados en Git, incluidos los eventos de pull request y merge request.
- Security checks: un conjunto de chequeos incorporados que puedes activar o desactivar uno por uno.
- Instrucciones personalizadas: qué priorizar y las expectativas de seguridad propias de tu proyecto.
- Tools y MCPs: un Security Reviewer no se puede guardar hasta que tenga al menos una herramienta o MCP conectado, por ejemplo uno que envíe los hallazgos a un canal de Slack o a tu gestor de issues.
Los Security Agents se ejecutan sobre los Cloud Agents de Cursor y no requieren configuración adicional del entorno si usas la nube de Cursor.
¿Se puede revisar la seguridad antes de hacer push?
Sí. La skill /review-security (o la más general /review) ejecuta el mismo Security Agent desde tu propia sesión de agente, antes de que el código salga de tu máquina. Por defecto revisa todos los cambios respecto de la rama base, tanto los commiteados como los que aún no lo están. Puedes pedirle que mire solo los cambios sin commitear, o indicarle otra rama base si la tuya no es la predeterminada.
Las skills están disponibles en Cursor 3.7 o superior, en cursor.com/agents y en el Cursor CLI. Es el ciclo más rápido de los tres: ves los hallazgos antes de que los vea cualquier revisor.
¿Cómo hacer un escaneo de vulnerabilidades del código que ya está en el repositorio?
Para eso está el segundo tipo de agente, el Vulnerability Scanner. En lugar de reaccionar a cada PR, escanea el código en reposo con un calendario tipo cron, y encuentra problemas antiguos y lo que se le escapó a la revisión de PR. Sus hallazgos aparecen en una lista llamada Flagged Vulnerabilities:
- Los hallazgos se agrupan por repositorio.
- Puedes filtrarlos por severidad (Critical, High, Medium), estado y feedback (Useful, False Positive, Unimportant).
- Cada hallazgo tiene un botón Fix in Cursor que lanza un cloud agent para corregirlo.
En conjunto quedan tres capas: la skill antes del push, el reviewer en el PR y el scanner sobre lo que ya está mergeado.
El panel también muestra vulnerabilidades encontradas, issues corregidos y una tasa de resolución. La documentación aclara que un LLM decide si algo quedó “corregido” revisando los diffs posteriores, así que conviene leer esa métrica como una estimación.
¿Security Review es una herramienta SAST?
Cumple una función parecida, aunque Cursor no usa ese término: al momento de publicar esta nota, su documentación no lo describe como SAST. Un SAST (Static Application Security Testing) clásico analiza el código fuente sin ejecutarlo, normalmente con reglas y patrones definidos de antemano. Security Review también lee el código sin ejecutarlo, pero con otras diferencias:
- Lo lee en el contexto del PR y del resto del codebase.
- Sigue el recorrido del input del usuario.
- Propone una corrección concreta.
- Acepta reglas del equipo escritas en lenguaje natural.
Si ya tienes un SAST en tu pipeline, lo razonable es tratar a Security Review como una capa adicional y comparar sus hallazgos con los de tu herramienta actual durante un tiempo, no reemplazarla de entrada.
¿Security Review o Bugbot?
Se reparten el trabajo. Security Review reporta bugs explotables; el estilo y la calidad del código siguen a cargo de Bugbot, el bot general de code review de Cursor. Si ya usas Bugbot, Security Review funciona a su lado, no en su lugar. Contamos el cambio de Bugbot al modelo propio de Cursor en esta nota anterior.
Para ver cómo resuelven el mismo problema otras herramientas, revisa nuestra guía de Copilot Code Review y la de code review con Claude Code y otros agentes.
¿Qué hace Cursor Rollouts después del despliegue?
Rollouts comprueba si un cambio hizo realmente lo que debía una vez desplegado, y lo hace en cada entorno por separado. Cursor lo describe como su propia versión de los Change Monitors de Firetiger, reconstruida con su Bot Development Kit.
- Cuando se abre el PR, Rollouts lee el diff y escribe un rollout plan. El plan incluye los riesgos que detecta, el efecto que debería tener el cambio, las señales que va a revisar y los huecos de instrumentación que harían difícil verificarlo.
- En GitHub, GitLab.com y Bitbucket Cloud, el plan se publica como comentario en el PR.
- Para cambiarlo, menciona el handle del bot en un comentario del PR y dile qué vigilar o qué ignorar. Solo pueden hacerlo quienes tienen permisos de escritura en el repositorio.
- Cuando el commit se despliega, Rollouts ejecuta el plan contra tus logs, métricas y trazas. Revisa en el momento del despliegue y de nuevo a los 20 minutos, 1 hora, 1 día y 3 días. Como cada entorno se sigue por separado, un cambio puede quedar verificado en staging y marcado en producción.
- Cuando detecta una regresión, nombra el cambio sospechoso, abre un issue y avisa al autor. Desde el issue puedes pulsar Fix para lanzar un cloud agent, o cerrarlo indicando el motivo.
Rollouts nunca hace merge, revierte ni hace rollback por su cuenta. El anuncio menciona un PR de reversión opcional, pero al momento de publicar esta nota la documentación solo describe el flujo de issue con el botón Fix.
¿Cómo se activa Rollouts?
Se activa desde la tarjeta de Rollouts en Automations, en cuatro pasos:
- Repositorios: eliges cuáles vigilar, hasta 200, en Origin, GitHub, GitLab.com o Bitbucket Cloud.
- Eventos de despliegue: tu pipeline avisa cuándo empieza y termina cada despliegue a producción, usando una API key de Cursor guardada en los secretos de tu CI. Puedes agregar esas llamadas tú mismo o dejar que un agente de setup abra un PR que las agregue.
- Telemetría: conecta al menos una herramienta de observabilidad, como Datadog. Sin ella, los cambios quedan pendientes y Rollouts no puede detectar nada.
- Notificaciones: por ejemplo, mensajes directos o un canal de Slack. Las notificaciones de Slack no están disponibles en Privacy Mode.
Por defecto, Rollouts omite los cambios que solo tocan documentación, formato, lint, erratas o tests. Puedes reescribir esa regla en lenguaje natural. La integración con feature flags está anunciada como “próximamente”.
¿Cursor Security Review es gratis?
No: ambos bots requieren un plan Teams o Enterprise, y los Security Agents se cobran contra el pool de uso del equipo, no contra el de cada persona. Para que los equipos prueben Rollouts con cambios reales, Cursor incluye créditos de uso durante 10 días desde el lanzamiento del 23 de septiembre: unos 50 cambios para Teams y 500 para Enterprise. Al momento de publicar esta nota, esa promoción sigue vigente hasta aproximadamente el 3 de octubre.
¿Qué es Cursor?
Cursor es un editor de código con IA y agente de programación desarrollado por Anysphere. Está construido alrededor de agentes que planifican, escriben y revisan código en tus repositorios: en local, en la nube y desde el CLI. Security Review y Rollouts lo extienden más allá del editor, hacia el PR y el pipeline de despliegue. Si eres nuevo en Cursor, comienza por nuestra introducción.
¿Por qué importa?
Los agentes ya escriben una parte importante del código que llega a revisión, así que el cuello de botella se movió a verificarlo. La apuesta de Cursor, visible desde Automations, es que los mismos agentes revisen el resultado: antes del push, en el PR y después del despliegue. El enfoque mantiene a una persona en el circuito. Nada se mergea ni se revierte sin que alguien lo decida.