Leí los prompts de los agentes de seguridad de Cursor para que tú no tengas que hacerlo

Este es el prompt completo:

You are a security reviewer for pull requests.
Goal: Detect and clearly explain real vulnerabilities introduced or exposed by this PR. Review only added or modified code unless unchanged code is required to prove exploitability.
1. Inspect the PR diff and surrounding code paths.
2. For every candidate issue, trace attacker-controlled input to the real sink.
3. Verify whether existing controls already block exploitation: auth or permission checks, schema validation or type constraints, framework escaping, ORM parameterization, allowlists or bounded constants.
4. Report only medium, high, or critical findings with a plausible attack path and concrete code evidence.
Prioritize: injection risks, authn or authz bypasses, permission-boundary mistakes, secret leakage or insecure logging, SSRF, XSS, request forgery, path traversal, and unsafe deserialization, dependency or supply-chain risk introduced by the change.

Es el núcleo de la automatización Agentic Security Review de Cursor, que revisa más de 3,000 PRs internos por semana y detecta más de 200 vulnerabilidades reales. Una asignación de rol, un objetivo, una metodología de cuatro pasos y una lista de prioridades. Sin una elaborada estructura de razonamiento paso a paso. Sin páginas de ejemplos few-shot. Sin esquemas complejos de salida JSON.

Si hace dos años me hubieras dicho que un prompt tan conciso podía funcionar a esa escala y producir resultados suficientes para bloquear la integración continua, habría sido escéptico. A todos nos han condicionado a pensar que los prompts de IA requieren una ingeniería elaborada: páginas de instrucciones, ejemplos cuidadosamente diseñados y especificaciones detalladas de salida. Las plantillas de código abierto de Cursor sugieren que, para la revisión de seguridad, una definición clara del rol y una metodología estructurada podrían ser todo lo que necesitas.

Es una señal notable de dónde están ahora los modelos de frontera. El modelo ya «sabe» cómo es una inyección SQL, cómo funcionan los ataques para eludir la autenticación y qué significa una deserialización insegura. Solo necesita un marco para aplicar ese conocimiento de forma sistemática. Si hoy los modelos pueden hacer tanto con tan pocas instrucciones, la trayectoria para los próximos seis a doce meses es realmente emocionante.

Por supuesto, el prompt es solo la punta del iceberg. El verdadero logro de ingeniería no son las 15 líneas de instrucciones, sino todo lo que hay debajo: el servidor MCP personalizado que gestiona la persistencia y la deduplicación, el pipeline de despliegue administrado con Terraform, la orquestación de webhooks que sabe cuándo activar cada agente y la gestión de estado que permite a los agentes comparar hallazgos entre ejecuciones. El prompt es simple porque la infraestructura que lo rodea no lo es. Esa es una distinción importante y, de hecho, la historia más interesante: Cursor no se limitó a escribir prompts ingeniosos; creó una plataforma de orquestación de agentes lista para producción y luego le añadió prompts simples.

Pero antes de adelantarnos, veamos el panorama completo de lo que creó Cursor, qué es impresionante de cada componente y dónde están las brechas. Para eso, ayuda contar con un marco para analizar la seguridad en los entornos de desarrollo agéntico.

Las tres dimensiones de la seguridad agéntica

En Snyk, pensamos en la seguridad del desarrollo agéntico en tres dimensiones: el código que generan los agentes, la cadena de suministro de la que dependen los agentes y el comportamiento de los propios agentes. La dimensión del código es en la que se enfoca la mayoría: ¿la IA escribe código seguro y detectamos las vulnerabilidades antes de que lleguen a producción? La dimensión de la cadena de suministro es más reciente y menos evidente: los servidores MCP, las plantillas de automatización, las habilidades de los agentes y los plugins son componentes de los que dependen tus agentes, y conllevan los mismos riesgos que cualquier dependencia de terceros. La dimensión del comportamiento es la más compleja: ¿los agentes actúan dentro del alcance previsto, toman decisiones que no deberían tomar y tienes visibilidad de lo que realmente hacen en toda tu organización?

Los agentes de seguridad de Cursor operan principalmente en la primera dimensión: detectan vulnerabilidades en el código. Es un trabajo valioso y necesario. Pero, como verás en el recorrido que sigue, las otras dos dimensiones importan igual de mucho, sobre todo a escala empresarial. Y las organizaciones que obtienen los mejores resultados, como Labelbox, que resolvió un rezago de vulnerabilidades de varios años al usar Cursor y Snyk en conjunto, son las que abordan las tres.

Los cuatro agentes: qué hacen bien y qué les falta

Hoy, Travis McPeak publicó una entrada de blog en la que detalla cómo el equipo de seguridad de Cursor creó cuatro agentes de seguridad autónomos sobre Cursor Automations (su plataforma de agentes en la nube) y publicó las plantillas como código abierto para que cualquiera las use. La velocidad de sus PRs había aumentado cinco veces en nueve meses y el análisis estático tradicional no podía seguir el ritmo. Así que crearon agentes capaces de hacerlo.

Todo el sistema se apoya en una base que vale la pena destacar: un servidor MCP (Model Context Protocol) personalizado, implementado como una función Lambda sin servidor. Ofrece seguimiento persistente del estado, una capa de deduplicación basada en Gemini Flash 2.5 (para que distintos agentes no reporten el mismo hallazgo con palabras diferentes) y un formato uniforme para los mensajes de Slack con opciones para descartar o posponer. Todo se administra con Terraform. Ingeniería sólida.

A continuación, cada agente, junto con lo que me parece realmente impresionante y lo que un equipo de seguridad empresarial debería tener en cuenta.

Agentic Security Review: el guardián de los pull requests

Qué hace: Revisa cada pull request según el modelo de amenazas específico de Cursor. Publica los hallazgos en un canal privado de Slack, comenta directamente en los PRs y puede bloquear el pipeline de CI si encuentra problemas de seguridad. Su principal diferencia frente a un bot de revisión de propósito general como Cursor’s Bugbot es que se puede ajustar el prompt específicamente para seguridad sin bloquear cada detalle menor de calidad del código.

Qué es impresionante: Los resultados hablan por sí solos. En los últimos dos meses, este agente se ejecutó en miles de PRs y evitó que cientos de problemas llegaran a producción. Y, como mostré antes, el prompt que impulsa todo esto es notablemente conciso. Para un revisor basado en un LLM, la proporción entre señal y ruido es realmente sorprendente.

Qué debes tener en cuenta: Los LLM pueden señalar con seguridad una «inyección SQL crítica» en una consulta parametrizada que es perfectamente segura, porque el modelo interpretó mal el flujo de datos. También pueden pasar por alto una vulnerabilidad real porque su atención se dispersa al analizar una base de código grande. En seguridad, ambos tipos de error son costosos: los falsos positivos erosionan la confianza de los desarrolladores y los falsos negativos dejan vulnerabilidades reales en producción. Cuando tu capa de detección es totalmente probabilística, estás aceptando ambos riesgos. El principio es simple: el agente no puede calificarse su propia tarea. Necesitas una capa de validación independiente que confirme lo que encontró el LLM. Por eso es importante combinar el análisis SAST determinista (como Snyk Code) con la revisión del LLM. El motor determinista detecta patrones conocidos con precisión mecánica; el LLM detecta errores de lógica novedosos que abarcan varios archivos y que las herramientas basadas en reglas no encuentran. Necesitas ambos.

También vale la pena fijarse en el final de la plantilla del prompt.

Post a short Slack summary with the overall outcome and the top findings, if any.
Do not push changes or open fix PRs from this workflow.

El agente de revisión explícitamente no aplica correcciones. Detecta, reporta y bloquea, pero una persona sigue decidiendo qué hacer. Incluso el propio equipo de seguridad de Cursor mantiene la supervisión humana en sus herramientas. Eso debería darte una idea de dónde está hoy la seguridad con IA autónoma: es un acelerador potente, no un reemplazo del criterio humano. Al menos, todavía no.

Vuln Hunter: análisis de la base de código existente

Qué hace: En lugar de observar el código nuevo, Vuln Hunter analiza la base de código existente. Divide el repositorio en segmentos lógicos, busca vulnerabilidades en cada uno y el equipo de seguridad clasifica los hallazgos desde Slack. A menudo usan @Cursor directamente desde Slack para generar PRs con correcciones.

Qué es impresionante: Aplicar el razonamiento de un LLM al código heredado es una buena idea. Es ahí donde brilla la IA: al comprender bases de código complejas y sin documentación, e identificar vulnerabilidades que las reglas estáticas pasarían por alto. Errores de lógica entre archivos, patrones de control de acceso defectuosos y formas de eludir la autenticación ocultas en código de hace años. Los analizadores tradicionales tienen dificultades porque necesitan patrones bien definidos con los que comparar.

Qué debes tener en cuenta: Este es el agente con mayor probabilidad de generar falsos positivos a escala. Analizar una base de código completa (en lugar de los cambios específicos de un pull request) significa que el modelo trabaja con mucho más contexto, y es ahí donde la dispersión de atención de los LLM se convierte en un riesgo real. BaxBench, un benchmark de ETH Zurich, UC Berkeley e INSAIT, descubrió que el 62 % de las soluciones generadas incluso por los mejores modelos son incorrectas o contienen vulnerabilidades de seguridad. Cuando el modelo razona sobre bases de código grandes y complejas, el principio de que «el agente no puede calificarse su propia tarea» cobra aún más importancia: necesitas una validación determinista que confirme o refute lo que encontró el LLM antes de que alguien invierta tiempo en una corrección.

Anybump: aplicación automatizada de parches a dependencias

Qué hace: Se ocupa de la tarea más tediosa de la seguridad de aplicaciones: aplicar parches a las dependencias. Ejecuta un análisis de reachability para filtrar y conservar solo las vulnerabilidades que realmente tienen impacto, rastrea las rutas del código, ejecuta pruebas, comprueba que no haya errores y abre un PR cuando las pruebas pasan. Todo está automatizado, con el pipeline de despliegue canario de Cursor como última barrera de seguridad.

Este es el núcleo del prompt:

You are a dependency-vulnerability remediation automation.
Goal: When a new Linear issue describes a vulnerable dependency, determine whether it can be upgraded safely and open a PR only when confidence is high.
Decision rule: Create PR only when upgrade is clearly safe; otherwise do not make changes.

Qué es impresionante: Esto aborda un problema que todos los equipos de seguridad conocen muy bien. Aplicar parches a las dependencias consume tanto tiempo que la mayoría de los equipos termina rindiéndose y delega la tarea en ingeniería, donde se queda en la lista de pendientes durante meses (o años). Automatizar el análisis de reachability, las pruebas y la generación de PRs es una mejora real del flujo de trabajo.

Qué debes tener en cuenta: Anybump resuelve la parte más difícil de administrar dependencias: aplicar el parche, probarlo e incluirlo en un PR. Pero ahí termina su alcance. No genera un SBOM, no verifica el cumplimiento de licencias ni crea un registro de auditoría para tu equipo de cumplimiento. No son tanto limitaciones del agente como problemas de una categoría completamente distinta. La aplicación automatizada de parches y el análisis de composición de software para empresas se superponen, pero no son lo mismo. Si trabajas en una industria regulada o distribuyes software en virtud de contratos con clientes que exigen cumplir ciertos requisitos, seguirás necesitando esa infraestructura más amplia junto con la automatización.

Si tu startup tiene un solo repositorio, Anybump podría ser todo lo que necesitas. Si operas a escala empresarial (cientos de repositorios, industrias reguladas, contratos con clientes que exigen certificaciones de cumplimiento específicas), necesitas saber exactamente qué contiene tu software y qué licencias utilizas, y poder demostrarlo. Esa es la diferencia entre aplicar parches de forma automatizada y el análisis de composición de software de nivel empresarial: se superponen, pero resuelven problemas fundamentalmente distintos.

Invariant Sentinel: detección de desviaciones de cumplimiento

Qué hace: Se ejecuta a diario para detectar desviaciones respecto a un conjunto de propiedades de seguridad y cumplimiento. Inicia subagentes para cada segmento lógico del repositorio, compara el estado actual con ejecuciones anteriores mediante la memoria de automatización y alerta al equipo de seguridad cuando algo cambia.

Lo impresionante: La gestión de estado es ingeniosa. Usar la función de memoria de la automatización para comparar distintas ejecuciones permite que el agente detecte cambios en la postura de seguridad, no solo instantáneas de un momento determinado. La posibilidad de escribir y ejecutar código de validación junto con el análisis agrega un rigor que el razonamiento puro de un LLM no ofrecería.

Qué debes tener en cuenta: Detectar desviaciones de cumplimiento es valioso, pero la gobernanza del cumplimiento es un desafío más amplio. Invariant Sentinel te avisa cuando algo cambia, pero no aplica políticas como código en cientos de repositorios, genera informes de cumplimiento para auditores ni ofrece a tu CISO un panel para ver las tendencias de riesgo a lo largo del tiempo. Esas son capacidades de plataforma que van más allá de lo que puede ofrecer un solo agente.

Esto sigue siendo CI, y la seguridad no debería empezar en CI

Esto es fácil de pasar por alto al revisar los diagramas de arquitectura y la orquestación de agentes: en esencia, lo que creó Cursor es una capa de CI muy sofisticada. Los agentes se activan mediante webhooks de GitHub cuando se abre o se actualiza un pull request. Revisan los cambios, publican comentarios, bloquean pipelines y abren PRs con correcciones. En el fondo, es el mismo punto de control en el que han operado las herramientas de seguridad tradicionales durante años, pero ahora es más inteligente porque el análisis lo hace un LLM en lugar de un motor de reglas basado en expresiones regulares.

Y mira, eso sí es una mejora real; no hay duda. Pero CI sigue siendo el lugar equivocado para empezar con la seguridad.

Por qué CI llega demasiado tarde para la seguridad

Piénsalo: si usas Cursor para escribir código en tu IDE y el código vulnerable llega hasta un PR antes de que alguien lo detecte, ya perdiste tiempo. El desarrollador tiene que cambiar de contexto y dejar el código que escribió, el ciclo de revisión del PR agrega latencia y, si la verificación de CI lo bloquea, ahora tiene que volver atrás, entender el hallazgo, corregirlo, enviar los cambios de nuevo y esperar otro ciclo de revisión. Claro que es mejor que descubrir la vulnerabilidad en producción, pero sigue siendo el modelo de «analizar y crear un ticket», solo que comprimido en el cronograma del PR.

Cómo se ve realmente adelantar la seguridad

Lo que realmente necesitas son herramientas de seguridad que se ejecuten directamente dentro de tu IDE y activen análisis y correcciones de inmediato cuando se agrega código nuevo. Así, el código vulnerable ni siquiera llega a un commit. El historial de Git se mantiene limpio. Tus PR no se bloquean porque los problemas de seguridad se detectan y corrigen en el flujo de trabajo, antes de que el desarrollador prepare el cambio. Además, reduces drásticamente la necesidad de costosas revisiones con intervención humana, porque si la vulnerabilidad nunca llega a un PR, nadie tiene que priorizarla ni se bloquea el pipeline de nadie a las 4:30 p. m. de un viernes.

Seguridad desde el IDE vs. seguridad desde CI

Con Snyk Studio, funciona exactamente así. Las barreras de seguridad interceptan el código inseguro antes de que el desarrollador acepte la sugerencia de la IA. El asistente de IA ejecuta snyk_code_scan en tiempo real sobre el código nuevo y, si encuentra problemas de seguridad, los corrige ahí mismo, sin interrumpir el flujo de trabajo. Funciona directamente en Cursor y en todos los demás asistentes de programación con IA principales. Sin bloqueos del pipeline de CI, cambios de contexto ni un historial de Git desordenado.

Por qué es necesaria la seguridad por capas

Ahora imagina que usas ambos: Snyk Studio en la capa del IDE, que detecta la gran mayoría de los problemas en el momento en que se crea el código, y los agentes de seguridad de Cursor en la capa de CI, como red de seguridad para lo que se escape. Obtienes defensa en profundidad: la mayor parte del trabajo se hace de forma silenciosa en el IDE y las costosas revisiones humanas se reservan para los casos realmente complejos. Teniendo en cuenta lo que nos dice BaxBench sobre la tasa de inseguridad del código generado por IA (el 62 % de las soluciones de los modelos principales contienen vulnerabilidades o son incorrectas), esta protección por capas no es algo opcional. Es esencial.

Y, más allá de la cuestión de CI, un programa de seguridad es mucho más que verificaciones de CI. Incluye paneles centralizados que consolidan los riesgos de cientos de repositorios. Sus hallazgos de SAST se correlacionan con los resultados de DAST y confirman que el mismo endpoint es explotable durante la ejecución. Incluye un motor de SCA que identifica que la biblioteca ORM que usas tiene un CVE conocido que omite la parametrización en ciertos casos límite y relaciona ese hallazgo con el de SAST en el mismo método del controlador. Por separado, cada uno de esos datos es solo un dato más. Juntos, correlacionados en la misma plataforma, te dicen exactamente qué está pasando, por qué y qué debes corregir primero. Un escáner de código, incluso uno autónomo con cuatro agentes y un impresionante volumen de PR, no responde esas preguntas. Una plataforma de seguridad sí.

Validación, no competencia (y ya estamos integrados)

Hace unas semanas escribí sobre el lanzamiento de Claude Code Security de Anthropic y expliqué por qué la inversión en seguridad de las plataformas de programación con IA es una validación, no una disrupción. La misma lógica aplica aquí: cuando los nombres más importantes de las herramientas de desarrollo con IA empiezan a crear funciones de seguridad, significa que la industria entendió que la seguridad en el desarrollo asistido por IA es infraestructura, no un complemento opcional.

Cómo trabajan juntos Cursor y Snyk

Cursor y Snyk no son barcos que pasan de noche; Snyk ya está en el directorio MCP de Cursor. Tenemos una extensión verificada. Lanzamos Evo Agent Guard via Hooks. Hace dos semanas, Cursor fue nuestro socio de innovación en IA del año. No es una relación de confrontación: es la arquitectura de dos niveles en acción. Piénsalo así: los agentes de IA son los investigadores, que descubren vulnerabilidades y proponen correcciones con rapidez y creatividad. La validación determinista es una revisión por pares que confirma de forma independiente que los hallazgos son reales y las correcciones, sólidas.

La arquitectura de seguridad de dos niveles

No publicarías un artículo sin una revisión por pares, y tampoco deberías implementar una corrección de seguridad sin una validación determinista. Cursor ofrece la capa de investigación (orquestación de agentes, activadores de webhook y generación automatizada de PR). Snyk ofrece la revisión por pares, la gobernanza y una cobertura amplia de toda la cadena de suministro de software.

Y esto ya funciona en el mundo real: Labelbox usa Cursor + Snyk en producción y logró eliminar un atraso de vulnerabilidades acumulado durante varios años. Cursor automatiza los flujos de trabajo de corrección; Snyk garantiza que esas correcciones sean reales y estén a la altura de las exigencias empresariales.

La cadena de suministro agéntica es la nueva superficie de ataque

Alejémonos un poco de la implementación específica de Cursor y veamos qué está pasando realmente en la industria. En el último año surgió una cadena de suministro de software completamente nueva, y está creciendo rápido: servidores MCP, habilidades de agentes, plantillas de automatización, complementos de herramientas de IA y configuraciones de modelos personalizadas. Llamémosla la cadena de suministro agéntica. Es el conjunto de componentes de los que dependen las herramientas de desarrollo con IA para funcionar y que, por ahora, casi nadie protege.

Esto no es una preocupación teórica. En enero de 2026, el equipo de investigación de Snyk descubrió cientos de habilidades maliciosas en ClawHub, el primer gran ataque a la cadena de suministro dirigido a los ecosistemas de agentes de IA. Piensa en esto en el contexto de lo que Cursor acaba de publicar como código abierto: plantillas de automatización que se ejecutan con acceso a tu base de código, tus pipelines de CI, tus canales de Slack y tus repositorios de GitHub. Un servidor MCP implementado como función de Lambda que procesa cada hallazgo de seguridad de tu organización. Son componentes potentes y privilegiados. Y el ecosistema para distribuirlos y descubrirlos (mercados, galerías de plantillas y repositorios de código abierto) crece mucho más rápido que las prácticas de seguridad que deberían acompañarlo.

La cadena de suministro de software tradicional tardó décadas en desarrollar las herramientas de las que dependemos hoy: registros de paquetes con verificación de firmas, SBOM, escáneres de licencias y bases de datos de vulnerabilidades. La cadena de suministro agéntica aún carece de esa infraestructura y, aun así, ya se está adoptando a gran escala. Cada organización que instala servidores MCP, importa plantillas de automatización o conecta habilidades de agentes a su entorno de desarrollo amplía su superficie de ataque de formas que el análisis de código, por sofisticado que sea, simplemente no puede abordar.

Este es precisamente el problema que Evo by Snyk se creó para resolver. Evo es nuestro sistema de orquestación de seguridad agéntica, diseñado para el entorno de desarrollo nativo de IA: modelado de amenazas con IA que crea modelos de amenazas en vivo a partir de tu código; red teaming con IA que ejecuta pruebas adversariales continuas en tus modelos y agentes; AI-SPM, para que sepas exactamente qué modelos y frameworks de IA se ejecutan en toda tu organización (incluida la «IA en la sombra» que los equipos de seguridad ni siquiera conocen); y Agent Scanning, para tener visibilidad de todas las cadenas de herramientas con barreras de seguridad en tiempo real.

Cuando ejecutas agentes de seguridad autónomos en toda tu base de código, también tienes que proteger esos agentes. Las herramientas de tu cadena de suministro agéntica son tan críticas como los paquetes npm de tu node_modules y merecen el mismo nivel de rigor.

Qué sigue: las preguntas que esto plantea

En lugar de cerrar con una tesis sobre la que ya escribí, terminaré con las preguntas que abre el anuncio de Cursor y que apuntan al futuro. Creo que esto es más interesante que mirar hacia atrás.

Pruébalo

Snyk Studio es gratis y configurarlo toma solo unos minutos. Funciona en Cursor (y prácticamente en cualquier otro asistente de programación con IA). En unos cinco minutos tendrás el análisis determinista y el comando de corrección /snyk-fix funcionando en tu IDE. Si quieres ver la seguridad por capas en la práctica, esta es la forma más rápida.

Evo by Snyk es la solución que necesitas cuando quieres proteger la propia pila de IA: modelado de amenazas, red teaming, AI-SPM, análisis de agentes y orquestación de seguridad agéntica. Si tu organización está adoptando herramientas de programación con IA a gran escala (y seamos sinceros, probablemente sí), Evo te ofrece la visibilidad y las barreras de seguridad necesarias para hacerlo de forma segura.

Las plantillas de automatización de Cursor son de código abierto en GitHub. Si usas Cursor, vale la pena explorarlas. Y si las usas junto con Snyk, obtendrás lo mejor de ambos mundos: automatización con agentes y validación de nivel empresarial.

Ya tenemos todas las piezas. Es hora de unirlas.