Proteger tu código fuente y tu entorno de desarrollo es importante para nosotros. En esta página explicamos cómo abordamos la seguridad en Cursor.

Envía posibles vulnerabilidades por correo electrónico a security-reports@cursor.com.

Para cualquier pregunta relacionada con la seguridad, no dudes en contactarnos en security@cursor.com.

Aunque ya contamos con varias organizaciones grandes que confían en Cursor, ten en cuenta que seguimos en el proceso de hacer crecer nuestro producto y mejorar nuestro nivel de seguridad. Si trabajas en un entorno de alta sensibilidad, debes tener cuidado al usar Cursor (o cualquier otra herramienta de IA). Esperamos que esta página te dé una mejor idea de nuestro progreso y te ayude a realizar una evaluación de riesgos adecuada.

#Certificaciones y evaluaciones de terceros

Cursor cuenta con certificación SOC 2 Tipo II. Visita trust.cursor.com para solicitar una copia del informe.

Nos comprometemos a realizar, como mínimo, una vez al año, pruebas de penetración con terceros de reconocido prestigio. Visita trust.cursor.com para solicitar un resumen ejecutivo del informe más reciente.

#Seguridad de la infraestructura

Dependemos de los siguientes subprocesadores, organizados aproximadamente de los más críticos a los menos críticos. Ten en cuenta que los datos de código se envían a nuestros servidores para habilitar todas las funciones de IA de Cursor (consulta la sección Solicitudes de IA), y que los datos de código de los usuarios con modo de privacidad (heredado) nunca se almacenan (consulta la sección Garantía del modo de privacidad).

Explora cómo cada modo afecta la forma en que se envían y almacenan los datos:

*Cursor respeta las listas de bloqueo de modelos y no enviará ninguna solicitud a modelos incluidos en una lista de bloqueo.

Ninguna parte de nuestra infraestructura se encuentra en China. No utilizamos directamente ninguna empresa china como subprocesador y, hasta donde sabemos, ninguno de nuestros subprocesadores lo hace tampoco.

Asignamos el acceso a la infraestructura a los miembros del equipo siguiendo el principio de privilegios mínimos. Aplicamos autenticación multifactor para AWS. Restringimos el acceso a los recursos utilizando tanto controles a nivel de red como secretos.

#Seguridad del cliente

Cursor es un fork de Visual Studio Code (VS Code) de código abierto, mantenido por Microsoft. Publican avisos de seguridad en su página de seguridad de GitHub. En cada versión principal alterna de VS Code, fusionamos en Cursor el código del repositorio ascendente (upstream) 'microsoft/vscode'. Puedes comprobar en qué versión de VS Code se basa tu versión de Cursor haciendo clic en "Cursor > About Cursor" en la aplicación. Si hay un parche de seguridad de alta criticidad en la versión ascendente de VS Code, aplicaremos la corrección (cherry-pick) antes de la siguiente integración y la publicaremos de inmediato.

Nuestra aplicación realizará solicitudes a los siguientes dominios para comunicarse con nuestro backend. Si estás detrás de un proxy corporativo, incluye estos dominios en la lista de permitidos para asegurarte de que Cursor funcione correctamente.

• 'api2.cursor.sh': Se utiliza para la mayoría de las solicitudes a la API.

• 'api5.cursor.sh': Se utiliza para las solicitudes del agente de Cursor.

• 'api3.cursor.sh': Se utiliza para las solicitudes de Cursor Tab (solo HTTP/2).

• 'repo42.cursor.sh': Se utiliza para la indexación de bases de código (solo HTTP/2).

• 'api4.cursor.sh', 'us-asia.gcpp.cursor.sh', 'us-eu.gcpp.cursor.sh', 'us-only.gcpp.cursor.sh': Se utilizan para las solicitudes de Cursor Tab según tu ubicación (solo HTTP/2).

• 'adminportal42.cursor.sh': Se utiliza para configurar SSO y la verificación de dominios.

• 'marketplace.cursorapi.com', 'cursor-cdn.com', 'downloads.cursor.com', 'anysphere-binaries.s3.us-east-1.amazonaws.com': Se utilizan para actualizaciones del cliente y para descargar extensiones desde el marketplace de extensiones.

Dos diferencias relacionadas con la seguridad respecto a VS Code a tener en cuenta:

1. Workspace Trust está desactivado de forma predeterminada en Cursor. Puedes activarlo configurando 'security.workspace.trust.enabled' en 'true' en la configuración de Cursor. Está desactivado de forma predeterminada para evitar confusión entre el "Restricted Mode" de Workspace Trust y el "Privacy Mode" de Cursor, y porque sus propiedades de confianza son sutiles y difíciles de entender (por ejemplo, incluso con Workspace Trust activado, no estás protegido frente a extensiones maliciosas, solo frente a carpetas maliciosas). Estamos abiertos a comentarios de la comunidad sobre si deberíamos activarlo de forma predeterminada.

2. Firmas de código de extensiones: Cursor no verifica las firmas de las extensiones que se descargan desde el marketplace. VS Code ha empezado recientemente a hacerlo. En particular, la configuración 'extensions.verifySignature' tiene como valor predeterminado 'false' en Cursor, pero 'true' en VS Code. Si la configuras en 'true' en Cursor, verás una ventana emergente que indica que la verificación de la firma ha fallado cada vez que intentes descargar una extensión. Esperamos empezar a admitir la verificación de firmas de extensiones a medio plazo.

#Solicitudes de IA

Para ofrecer sus funcionalidades, Cursor realiza solicitudes de IA a nuestro servidor. Esto sucede por varios motivos. Por ejemplo, enviamos solicitudes de IA cuando haces preguntas en el chat, enviamos solicitudes de IA en cada pulsación de tecla para que Cursor Tab pueda hacerte sugerencias y también podemos enviar solicitudes de IA en segundo plano para ir construyendo contexto o buscar errores que mostrarte.

Una solicitud de IA generalmente incluye contexto como tus archivos vistos recientemente, tu historial de conversaciones y fragmentos de código relevantes basados en la información del servidor de lenguaje. Estos datos de código se envían a nuestra infraestructura en AWS y luego al proveedor de inferencia del modelo de lenguaje correspondiente (Fireworks/OpenAI/Anthropic/Google). Ten en cuenta que las solicitudes siempre pasan por nuestra infraestructura en AWS incluso si has configurado tu propia clave de API de OpenAI en la configuración.

Actualmente no tenemos la capacidad de enrutar directamente desde la aplicación de Cursor a tu implementación empresarial de OpenAI/Azure/Anthropic, ya que la creación de prompts se realiza en nuestro servidor y nuestros modelos personalizados en Fireworks son fundamentales para ofrecer una buena experiencia de usuario. Aún no contamos con una opción de implementación de servidor autohospedado.

#Indexación de la base de código

Cursor te permite indexar semánticamente tu base de código, lo que le permite responder preguntas con el contexto de todo tu código, además de escribir mejor código haciendo referencia a implementaciones existentes. La indexación de la base de código está habilitada de forma predeterminada, pero se puede desactivar en la configuración.

Nuestra función de indexación de la base de código funciona de la siguiente manera: cuando está habilitada, escanea la carpeta que abres en Cursor y calcula un árbol de Merkle de hashes de todos los archivos. Se ignoran los archivos y subdirectorios especificados por '.gitignore' o '.cursorignore'. Luego, el árbol de Merkle se sincroniza con el servidor. Cada 10 minutos comprobamos si hay discrepancias en los hashes y usamos el árbol de Merkle para averiguar qué archivos han cambiado y solo subimos esos.

En nuestro servidor, dividimos los archivos en fragmentos, generamos sus embeddings y almacenamos esos embeddings en Turbopuffer. Para permitir filtrar los resultados de búsqueda vectorial por ruta de archivo, almacenamos junto con cada vector una ruta de archivo relativa ofuscada, así como el rango de líneas al que corresponde el fragmento. También almacenamos el embedding en una caché en AWS, indexado por el hash del fragmento, para garantizar que indexar la misma base de código una segunda vez sea mucho más rápido (lo cual es especialmente útil para equipos).

En tiempo de inferencia, calculamos un embedding, dejamos que Turbopuffer haga la búsqueda de vecinos más cercanos, enviamos de vuelta la ruta de archivo ofuscada y el rango de líneas al cliente y leemos esos fragmentos de archivo localmente en el cliente. Luego volvemos a enviar esos fragmentos al servidor para responder la pregunta del usuario. Esto significa que, para los usuarios en modo de privacidad, no se almacena código en texto plano en nuestros servidores ni en Turbopuffer.

Algunas notas:

• Para bloquear archivos específicos de tu base de código y evitar que se envíen a los servidores de Cursor o se incluyan en solicitudes de IA, añade un archivo '.cursorignore' a tu base de código que liste los archivos y directorios que se deben excluir. Cursor hará un esfuerzo razonable para evitar que estos archivos se incluyan en cualquier solicitud.

• Detalles de la ofuscación de rutas de archivo: la ruta se divide por '/' y '.' y cada segmento se cifra con una clave secreta almacenada en el cliente y un nonce determinista corto de 6 bytes. Esto filtra información sobre la jerarquía de directorios y provocará algunas colisiones de nonce, pero oculta la mayor parte de la información.

• Reversión de embeddings: trabajos académicos han demostrado que revertir embeddings es posible en algunos casos. Los ataques actuales dependen de tener acceso al modelo y de incrustar cadenas cortas en vectores grandes, lo que nos hace pensar que el ataque sería algo difícil de realizar aquí. Dicho esto, es definitivamente posible que un adversario que irrumpa en nuestra base de datos vectorial aprenda cosas sobre las bases de código indexadas.

• Cuando la indexación de la base de código está habilitada en un repositorio Git, también indexamos el historial de Git. En concreto, almacenamos los SHA de los commits, la información de los padres y los nombres de archivo ofuscados (igual que arriba). Para permitir compartir la estructura de datos entre usuarios en el mismo repositorio Git y en el mismo equipo, la clave secreta para ofuscar los nombres de archivo se deriva de hashes del contenido de commits recientes. Los mensajes de los commits y el contenido de los archivos o diffs no se indexan.

• Nuestra función de indexación a menudo experimenta una carga elevada, lo que puede hacer que muchas solicitudes fallen. Esto significa que, a veces, será necesario subir archivos varias veces antes de que queden completamente indexados. Una forma en que esto se manifiesta es que, si revisas el tráfico de red a 'repo42.cursor.sh', puedes ver más ancho de banda usado del esperado.

#Garantía del modo de privacidad

El modo de privacidad se puede activar en la configuración o por un administrador de equipo. Cuando está activado, garantizamos que los datos de código nunca se almacenan en nuestros proveedores de modelos ni se usan para entrenamiento. Cualquier persona (usuario gratuito o Pro) puede activar el modo de privacidad y, de forma predeterminada, este se fuerza para cualquier usuario que sea miembro de un equipo.

Nos tomamos muy en serio la garantía del modo de privacidad. Más del 50% de todos los usuarios de Cursor tienen el modo de privacidad activado.

Cada solicitud a nuestro servidor incluye un encabezado 'x-ghost-mode', que contiene un valor booleano que indica si el usuario está en modo de privacidad. Para evitar tratar accidentalmente a un usuario en modo de privacidad como un usuario sin modo de privacidad, siempre asumimos por defecto que un usuario está en modo de privacidad si falta el encabezado.

Todas las solicitudes a nuestro servidor pasan primero por un proxy, que decide qué servicio lógico debe gestionar la solicitud (por ejemplo, el "chat service" o el "Cursor Tab service"). Cada servicio lógico tiene dos réplicas casi idénticas: una réplica que gestiona las solicitudes en modo de privacidad y otra réplica que gestiona las solicitudes sin modo de privacidad. El proxy comprueba el valor del encabezado 'x-ghost-mode' y envía la solicitud a la réplica correspondiente. Las propias réplicas también comprueban el encabezado por redundancia. De forma predeterminada, todas las funciones de registro (log) de las réplicas de modo de privacidad no realizan ninguna operación (no-ops), a menos que tengan sufijos como 'infoUnrestricted', las cuales revisamos cuidadosamente para no adjuntar nunca posibles datos de código ni prompts. Para las solicitudes que generan tareas en segundo plano, de manera similar tenemos colas paralelas y réplicas de workers para modo de privacidad y sin modo de privacidad. Esta infraestructura paralela nos da confianza en nuestra garantía de modo de privacidad y en su resiliencia frente a errores o bugs accidentales.

Para la aplicación del modo de privacidad a nivel de equipo, cada cliente hace ping al servidor cada 5 minutos para comprobar si el usuario forma parte de un equipo que aplica el modo de privacidad. Si es así, se anula la configuración de modo de privacidad del cliente. Para evitar casos en los que el ping de modo de privacidad del cliente falle por cualquier motivo, nuestro servidor también, en la ruta crítica, comprueba si el usuario forma parte de un equipo que aplica el modo de privacidad y, de ser así, trata la solicitud como si estuviera en modo de privacidad incluso si el encabezado indica lo contrario. En los servicios sensibles a la latencia, almacenamos en caché este valor durante 5 minutos, y ante cualquier fallo de caché asumimos que el usuario está en modo de privacidad. En resumen, esto significa que cuando un usuario se une a un equipo, se garantiza que estará en modo de privacidad, como muy tarde, 5 minutos después de unirse al equipo.

#Eliminación de la cuenta

Puedes eliminar tu cuenta en cualquier momento en el panel de configuración (haz clic en "Advanced" y luego en "Delete Account"). Esto eliminará todos los datos asociados con tu cuenta, incluidos cualquier repositorio de código indexado. Garantizamos la eliminación completa de tus datos en un plazo de 30 días (eliminamos los datos de inmediato, pero algunas de nuestras bases de datos y almacenamiento en la nube tienen copias de seguridad de no más de 30 días).

Cabe señalar que, si alguno de tus datos se utilizó en el entrenamiento de modelos (lo que solo ocurriría si no tenías activado el modo de privacidad en ese momento), nuestros modelos ya entrenados no se volverán a entrenar de inmediato. Sin embargo, cualquier modelo futuro que se entrene no se entrenará con tus datos, ya que esos datos se habrán eliminado.

#Notificación de vulnerabilidades

Si crees que has encontrado una vulnerabilidad en Cursor, envíanos el informe a security-reports@cursor.com.

Nos comprometemos a confirmar la recepción de los informes de vulnerabilidades en un plazo de 5 días hábiles y a atenderlos tan pronto como nos sea posible. Los incidentes críticos se comunicarán por correo electrónico a todos los usuarios.