¿Es seguro Cursor AI? El editor, el código y la app que publicaste

Construiste algo en Cursor, funciona, y estás a punto de meter a personas reales. En algún momento de esa semana escribiste «es seguro cursor ai» en un buscador, y lo que salió fue una página sobre los ajustes de privacidad de Cursor, una página sobre si el código escrito por IA vale algo, y una página sobre una descarga de punteros de ratón personalizados. Ninguna dijo una palabra sobre la app que estás a punto de publicar.

Aquí está la parte que la mayoría de esas respuestas se equivoca: «¿es seguro Cursor AI?» son tres preguntas en una sola frase, y tienen tres respuestas distintas. Dos son sobre Cursor y los modelos que hay detrás. La tercera es sobre lo que publicaste, y es la que decide si un desconocido puede leer los datos de tus usuarios.

Piensa en Cursor como un contratista al que contrataste para construir una casa. Si se queda con una copia de tus planos es una pregunta. Si lo que construye cumple la normativa es una segunda. Si las puertas cierran con llave una vez que te has mudado es la tercera, y sigue siendo tu pregunta mientras vivas ahí.

¿Es seguro Cursor AI?

Como editor, es una herramienta en la nube corriente: un interruptor de privacidad, una página de seguridad publicada y una atestación SOC 2 Tipo II. Eso responde una de las tres preguntas, y no la que decide si desconocidos pueden leer los datos de tus usuarios.

1. El editor. Si Cursor guarda tu código, entrena con él o se lo pasa a otro. Esta es la copia de los planos que tiene el contratista.
2. El código. Si lo que escribe la IA es seguro. Esto es si la casa cumple la normativa, y nadie lo inspecciona al entrar.
3. La app que publicaste. Lo que un desconocido puede alcanzar desde la calle: una clave en el código que descarga un navegador, una base de datos que responde sin iniciar sesión, un archivo que nunca debió tener una URL. Estas son las puertas.

Nada del lado de Cursor puede responder la tercera. Nada del nuestro puede responder las dos primeras.

¿Cursor guarda mi código?

Mientras tarda en responderte, sí. Después depende de un interruptor.

Cursor es una herramienta en la nube. Cuando le preguntas algo, las partes relevantes de tu proyecto salen de tu ordenador, van a los servidores de Cursor y pasan a un proveedor de modelos (OpenAI, Anthropic, Google, el modelo que hayas elegido) para ser respondidas. Así funciona el producto. Los planos tienen que llegar al contratista.

Lo que pasa después es el interruptor, y la página de uso de datos de Cursor pone las dos posiciones en un mismo párrafo. Con el Privacy Mode encendido, «los datos de clientes no serán usados por Cursor para entrenar» y Cursor «mantiene acuerdos de retención cero de datos (ZDR) con todos los proveedores», es decir, las empresas que ejecutan los modelos se comprometen a no quedarse con nada. Con él apagado, Cursor «puede usar y almacenar datos del código, prompts, acciones del editor, fragmentos de código y otros datos y acciones de código para mejorar nuestras funciones de IA y entrenar nuestros modelos».

El interruptor está disponible en todos los planes, el gratuito incluido, y un administrador de equipo o de empresa puede encenderlo para todos e impedir que los miembros lo apaguen. La propia guía de endurecimiento de Cursor dice que viene encendido por defecto en las cuentas Enterprise. En un plan individual es un ajuste, y ese ajuste vale la pena buscarlo hoy.

Una cosa más sobre él, porque ya ha pillado a alguien. Desde mediados de 2025 hay dos versiones: «Privacy Mode», que permite a Cursor guardar algunos datos para funciones como sus agentes en la nube y las memorias, y «Privacy Mode (Legacy)», que no guarda nada. En julio de 2026 un usuario de Hacker News contó que inició sesión en la app de iOS y encontró su cuenta movida del ajuste antiguo al actual. Un empleado de Cursor respondió que el aviso para activar los agentes en la nube lo había hecho «sin dejar claro qué significaba ni que es difícil de deshacer», y que volver atrás no estaba disponible en la app. Si elegiste la más estricta, comprueba que sigue seleccionada.

Los certificados responden una pregunta más estrecha de lo que parece. La página de seguridad de Cursor lista una atestación SOC 2 Tipo II, ISO/IEC 27001 e ISO/IEC 42001. Significan que un auditor externo comprobó que Cursor tiene controles sobre cómo maneja los datos que guarda, igual que el certificado de seguro de un contratista dice que el contratista está asegurado. No dicen nada sobre el código que escribe ni sobre la app que publicas con él.

¿Qué sube la indexación del código?

Un índice de tu proyecto, guardado en los servidores de Cursor, con las rutas de los archivos cifradas y el código en sí nunca almacenado como texto legible.

La indexación es la forma en que Cursor responde una pregunta sobre todo tu proyecto y no solo sobre el archivo que tienes abierto. Parte tus archivos en trozos, los envía a los servidores de Cursor para convertirlos en embeddings (un resumen numérico de de qué trata cada trozo) y conserva esos embeddings para que, cuando preguntes «dónde gestionamos los reembolsos», pueda encontrar los trozos correctos. La documentación de Cursor dice: «Las rutas de los archivos se cifran antes de enviarse a los servidores de Cursor. El contenido del código nunca se almacena en texto plano». Lo que queda de su lado es un mapa de tu código, y eso es algo distinto de una copia.

Dos cosas conviene saber sobre el mapa.

Algunos archivos se dejan fuera por defecto, y puedes añadir más. Cursor omite todo lo que esté en tu .gitignore y una lista por defecto que incluye .env*, el archivo donde suelen vivir tus claves secretas. Un archivo .cursorignore en la raíz del proyecto, escrito con la misma sintaxis que .gitignore, deja fuera del índice y de lo que se muestra a la IA cualquier otra cosa que nombres.

El terminal del agente no lee esa lista. Esta es la salvedad que importa para las claves. La página sobre archivos de exclusión de Cursor dice que «las herramientas de terminal y de servidor MCP que usa el Agente no pueden bloquear el acceso al código regido por .cursorignore», y que «no se garantiza una protección completa debido a la imprevisibilidad de los LLM». Cuando el agente ejecuta un comando en tu máquina, puede leer .env como lo haría cualquier comando. El archivo está fuera del índice y sigue al alcance. Si hay una clave en la carpeta de proyecto que tienes abierta en Cursor, trátala como una clave que el agente puede ver.

¿Es seguro el código que escribe Cursor?

No por defecto, y eso está medido, aunque la medición es de los modelos que usa Cursor y no de Cursor en sí.

Veracode, una empresa que vende pruebas de seguridad de código, ha pasado más de 150 modelos por las mismas 80 tareas de programación, en cuatro lenguajes, cada tarea con una forma segura y otra insegura de resolverla. Su actualización de primavera de 2026, publicada el 24 de marzo de 2026, encontró que solo el 55 % de los resultados eran seguros, una cifra que Veracode califica de «prácticamente idéntica a la de hace dos años», mientras que la proporción que compilaba superaba el 95 %. En dos de los cuatro tipos de fallo los modelos casi nunca eligieron la versión segura: el cross-site scripting, que permite que el texto de un visitante se ejecute como código en el navegador de otro, pasó el 15 % de las veces, y la inyección de logs el 13 %.

El propio resumen de Veracode es que los modelos «se han vuelto excelentes escribiendo código que compila. Han fracasado escribiendo código que es seguro».

Para ti, la persona que no escribió el código, la brecha entre esos dos números es todo el hallazgo. La prueba que haces en un proyecto de Cursor es si funciona: recorres la app a clics y aparecen las cosas correctas. Ese es el 95 %. La prueba que nadie hace es si el código decidió quién puede ver qué, y el 55 % dice que esa decisión se tomó más o menos la mitad de las veces. Una app puede pasar la primera prueba por completo y fallar la segunda, porque una página que te muestra tus pedidos y una página que muestra a cualquiera los pedidos de todos se ven idénticas para la persona dueña de la cuenta.

Dónde corresponde esa decisión, y por qué «carga los pedidos» nunca la toma por sí sola, está en el centro de la guía de Cursor.

Inyección de prompts, en lenguaje llano

El modelo trata las instrucciones como instrucciones allí donde las encuentre, incluso dentro de cosas que solo tenía que leer.

Le dices a Cursor «resume este hilo» o «ordena este archivo», y para hacerlo lee el hilo o el archivo. Si el hilo contiene una frase escrita para parecer una instrucción a una IA, el modelo puede seguirla, porque no tiene una forma fiable de distinguir tu voz de la de la página. Eso es la inyección de prompts, y en un agente de programación, que puede editar archivos y ejecutar comandos en tu máquina, las consecuencias van más allá de un mal resumen.

Dos casos con nombre, ambos contra Cursor. En marzo de 2025 Pillar Security publicó «Rules File Backdoor»: instrucciones ocultas con caracteres Unicode invisibles dentro de un archivo .cursor/rules, el archivo de configuración que le dice a Cursor cómo quieres que escriba tu código. El archivo parecía limpio en el editor y en un diff de GitHub, y le decía a la IA en silencio que añadiera a cada página generada un script desde el dominio de un atacante y que nunca lo mencionara. La respuesta de Cursor fue que eso no era una vulnerabilidad de su plataforma y que la responsabilidad recae en el usuario. En agosto de 2025 Aim Security reveló CVE-2025-54135, que llamaron CurXecute: un mensaje en un canal público de Slack, leído por Cursor a través de un servidor MCP (un complemento que permite al agente llegar a herramientas externas), podía hacer que el agente escribiera una entrada en su propia configuración mcp.json, y Cursor arrancaba esa entrada, ejecutando el comando del atacante, antes de que hubieras aprobado el cambio. Cursor lo corrigió en la versión 1.3 el 29 de julio de 2025, y ahora cada cambio en ese archivo espera tu aprobación.

Lo que se deriva para ti es corto. Un archivo de reglas que copiaste de un repositorio o de un artículo es código, y dirige todo lo que el agente escribe después, así que léelo como código. Mantén Cursor actualizado, porque la corrección de CurXecute fue un número de versión. Y cada servidor MCP que conectes y que lea texto de fuera, una bandeja de entrada, una cola de tickets, una búsqueda, le entrega al agente frases que tú no escribiste.

Qué dice un escaneo de 30.998 apps en vivo sobre la tercera pregunta

Que nada del editor llega a la app que publicaste. No podemos distinguir desde fuera una app hecha con Cursor de cualquier otra, y ese es el hallazgo.

Entre el 12 y el 14 de agosto de 2026 pasamos las nueve comprobaciones externas que cualquiera puede ejecutar gratis en nuestra página de inicio por 30.998 apps en vivo. Las encontramos por dónde estaban publicadas: 18.554 en el dominio de Lovable, 5.438 en el de Base44, 3.042 en el de Replit, y así en adelante. Un proyecto de Cursor se despliega donde tú lo pongas, en Vercel, en Netlify, en un dominio que compraste, y la página que descarga un visitante no lleva marca alguna del editor que la escribió. Así que no hay una columna de Cursor en el informe, y no puede haberla.

Lo que sí hay, en cada builder que medimos, es la misma lista corta de cosas que un dueño dejó abiertas, y ninguna la decide el editor. Cada proporción de abajo es sobre las apps en las que esa comprobación respondió, porque una comprobación que no pudo terminar es desconocida, no aprobada. Ninguna app se nombra aquí ni en ningún otro sitio que publiquemos.

La primera fila se mide sobre las 3.680 apps que nombraron un proyecto de Supabase y cuya base de datos respondió a la pregunta, por eso su base es más pequeña; qué lee esa comprobación y qué no tiene la escalera completa. La quinta fila es la que cuesta dinero por sí sola: una clave secreta de OpenAI, Anthropic, AWS o Stripe, o una clave service_role de Supabase, en el código que descarga un navegador.

La última columna es lo que cambia en Cursor. En el dominio propio de un builder, dos de esas filas pertenecen al host: las cabeceras las envía lo que sirve la página, y los source maps siguen la configuración de build del builder. Un proyecto de Cursor es tu repositorio, tu build y tu despliegue, así que cada fila de esa tabla es tuya, incluidas las dos que un dueño de Lovable no controla. Eso es más control y más que comprobar, y es por lo que la guía de Cursor dedica su tiempo a la salida de tu build y a tu base de datos y no al editor. El artículo sobre Replit hace las mismas tres preguntas a una plataforma que aloja la app y a la vez te deja publicar un servidor propio.

La comprobación de cinco minutos desde fuera

Usa una ventana privada para las tres primeras, para que tu propia sesión no responda por un desconocido.

1. Abre tu dirección publicada con /.env al final, y luego con /.git/config. Las dos deben fallar. Si alguna muestra texto, rota hoy cada clave que contenga y arregla el despliegue para que ese archivo nunca se sirva.
2. Abre de la misma forma una de tus propias rutas de API, una que no querrías que leyera un desconocido. Si responde con datos, esa ruta necesita una comprobación de sesión.
3. Abre tu app en vivo y luego la pestaña Sources de las herramientas de desarrollo de tu navegador. Si puedes leer tus archivos originales con sus comentarios, los source maps están activados en tu build de producción.
4. Si tus datos están en Supabase, la mitad interior de la comprobación está en la guía de Cursor: busca service_role y sk_live_ en la salida del build, y luego abre la página de políticas.
5. O deja que el escaneo lo haga. Ejecuta estas y el resto de las nueve desde fuera, tarda unos 20 segundos, no necesita cuenta e imprime «No se pudo comprobar» para todo lo que no pudo responder en lugar de una marca: escanea tu app.

¿Qué cambia después del siguiente push?

Cualquier cosa. Un proyecto de Cursor sale al mundo cuando haces push, y nada entre tu editor e internet vuelve a leer la app en busca de una ruta que perdió su comprobación de sesión, una clave pegada a medianoche para pasar un build que fallaba o un source map que volvió a activarse con un cambio de configuración. El número de Veracode es la razón por la que esto importa más aquí que en un builder: cada sesión con el agente es código nuevo que compila y puede no ser seguro, y un escaneo que hiciste el mes pasado describe la app del mes pasado.

Reeve Monitor está hecho para eso. Vuelve a ejecutar las nueve comprobaciones cada hora en hasta tres apps, vigila la disponibilidad cada 60 segundos, te avisa cuando un resultado cambia en lugar de esperar a que mires, y envía un informe mensual. Cuesta $12 al mes a precio de lista, con siete días gratis antes de cobrarte; la página de precios a veces está por debajo de la cifra de aquí y nunca por encima. Monitor vigila y nada más. Si tu app de Cursor guarda sus datos en Supabase, Care es el plan que además conserva una copia de esa base de datos, y de tus archivos subidos una vez que conectas una credencial de Storage. Si los datos viven en otro sitio, Monitor es la mitad que encaja.

Qué hacer esta semana

La mitad interior de todo esto, la salida del build y la base de datos, es la guía de Cursor. La lista de seguridad de 10 minutos cubre lo que vale la pena confirmar en cualquier app recién lanzada, la haya escrito quien la haya escrito.