Logique de récupération du code divulguée dans la documentation officielle sur la sécurité de Cursor

Sécurité des infrastructures

Nous nous appuyons sur les sous-processeurs suivants, classés par ordre décroissant de criticité. Veuillez noter que les données relatives au code sont téléchargées sur nos serveurs afin de soutenir le système de gestion de l'information. Curseur Toutes les fonctionnalités de l'IA (voir Composant de demande d'IA), tandis qu'en mode privé, les données du code de l'utilisateur ne sont pas conservées (pour plus de détails, voir Garantie du mode de protection de la vie privée (partiel).

Le mode de confidentialité est activé (cliquez pour voir comment le mode de confidentialité affecte la transmission des données de code).

• AWS Voir les données de code : notre infrastructure est principalement hébergée sur AWS. La plupart des serveurs sont situés aux États-Unis, et certains serveurs sensibles à la latence sont situés dans des régions AWS en Asie (Tokyo) et en Europe (Londres).
• Feux d'artifice Voir les données de code : nous hébergeons des modèles personnalisés sur les serveurs de Fireworks aux États-Unis, en Asie (Tokyo) et en Europe (Londres). Pour accélérer l'inférence du modèle, Fireworks peut stocker certaines données de code si le mode de confidentialité n'est pas activé.
• OpenAI Voir les données du code : nous nous appuyons sur de nombreux modèles d'OpenAI pour fournir des réponses à l'IA. Les demandes peuvent être envoyées à OpenAI même si le modèle d'Anthropic (ou un autre) est sélectionné dans le chat (par exemple, pour le résumé). Nous avons un accord de conservation de zéro données avec OpenAI.
• Anthropique Voir les données du code : nous nous appuyons sur de nombreuses Anthropique Nous avons conclu un accord de conservation des données avec Anthropic. Les demandes peuvent être envoyées à Anthropic même si un modèle OpenAI (ou autre) est sélectionné dans le chat (par exemple pour le résumé).
• Google Cloud Vertex API Voir les données du code : nous nous appuyons sur certaines données fournies par Google Cloud. Gémeaux pour fournir une réponse d'IA. Des demandes peuvent être envoyées à l'API Google Cloud Vertex même si un modèle OpenAI (ou autre) est sélectionné dans le chat (par exemple pour le résumé).
• Turbopuffer Stockage des données de code obscurci : Les embeddings des bases de code indexées et les métadonnées (noms de fichiers obscurcis) associées aux embeddings sont stockés sur Turbopuffer dans le Google Cloud, situé aux États-Unis. Vous trouverez plus d'informations sur les données de code obscurcies dans la section Page de sécurité de Turbopuffer Pour en savoir plus. Les utilisateurs peuvent désactiver l'indexation de la base de code ; pour plus de détails, voir la section Index de la base de code Partie.
• Exa répondre en chantant SerpApi Voir Requêtes de recherche (qui peuvent provenir de données de code) : pour la fonctionnalité de recherche sur le web. Les demandes de recherche peuvent provenir de données de code (par exemple, lorsque vous utilisez "@web" dans un chat, un modèle de langage distinct détermine ce qu'il faut rechercher sur la base de vos messages, de l'historique de la session et des documents actuels, et Exa/SerpApi verra la requête de recherche générée).
• MongoDB Données de code invisibles : nous utilisons MongoDB pour stocker certaines de nos données analytiques pour les utilisateurs dont le mode de confidentialité n'est pas activé.
  • Datadog Pas d'accès aux données du code : nous utilisons Datadog pour la journalisation et la surveillance. Comme le montre la page Section Assurance du mode de protection de la vie privée Les journaux concernant les utilisateurs du mode "vie privée" ne contiennent pas de données de code, comme décrit dans la section
• Les banques de données Pas d'accès aux données de code : nous utilisons Databricks MosaicML pour entraîner certains modèles personnalisés. Les données des utilisateurs du modèle de confidentialité ne sont pas transmises à Databricks.
• Fonderie Pas d'accès aux données de code : nous utilisons Foundry pour entraîner certains modèles personnalisés. Les données de l'utilisateur en mode confidentialité ne sont pas transmises à Foundry.
• Slack Pas d'accès aux données du code : nous utilisons Slack comme outil de communication interne. Dans les chats internes, des bribes d'indices pour les utilisateurs non privés peuvent être envoyées à des fins de débogage.
• Espace de travail Google Pas d'accès aux données du code : nous utilisons Google Workspace pour la collaboration. Dans les courriels internes, des bribes d'indices destinés aux utilisateurs non privés peuvent être envoyées à des fins de débogage.
• Pomme de pin Pas d'accès aux données du code : les données intégrées et les métadonnées des documents indexés sont stockées dans Pinecone. Ces documents sont extraits du web public. Nous sommes en train de les migrer vers Turbopuffer.
• Amplitude Pas d'accès aux données de code : nous utilisons Amplitude pour certaines de nos analyses de données ; aucune donnée de code n'est stockée dans Amplitude ; seules des données d'événement sont enregistrées, telles que le nombre de "demandes de tabulation du curseur".
• HashiCorp Pas d'accès aux données de code : nous utilisons HashiCorp Terraform pour gérer l'infrastructure.
• Rayure Pas d'accès aux données codées : nous utilisons Stripe pour traiter les factures. Stripe stocke vos données personnelles (nom, carte de crédit, adresse).
• Vercel Pas d'accès aux données de code : Nous utilisons Vercel pour déployer le site. Le site n'a pas accès aux données du code.
• WorkOS Pas d'accès aux données du code : nous utilisons WorkOS pour gérer l'authentification. workOS peut stocker certaines données personnelles (nom, adresse électronique).

Aucune de nos infrastructures n'est située en Chine. Nous n'utilisons pas directement de sociétés chinoises comme sous-traitants et, à notre connaissance, aucun de nos sous-traitants ne le fait non plus.

Nous suivons le principe du moindre privilège dans l'attribution de l'accès à l'infrastructure et mettons en œuvre l'authentification multifactorielle pour AWS. Nous limitons l'accès aux ressources grâce à des contrôles au niveau du réseau et à la gestion des secrets.

Sécurité des clients

Cursor est un projet open source géré par Microsoft. Code Visual Studio (VS Code), une branche de Microsoft. Page de sécurité de GitHub sur la publication de bulletins de sécurité. Après chaque nouvelle version majeure de VS Code, nous publierons en amont ‘microsoft/vscode’ La base de code est fusionnée dans Cursor. Vous pouvez voir la version de VS Code sur laquelle votre version de Cursor est basée en cliquant sur "Cursor > About Cursor" dans l'application. S'il y a un correctif de sécurité sérieux dans le code VS en amont, nous choisirons ce correctif avant la prochaine fusion et le publierons immédiatement.

Nous utilisons ToDesktop pour distribuer nos applications et effectuer des mises à jour automatiques. Plusieurs applications largement utilisées (telles que Linéaire répondre en chantant ClickUp) font également confiance à la plateforme.

Notre application envoie des requêtes aux domaines suivants pour communiquer avec notre backend. Si vous êtes dans un environnement proxy d'entreprise, veuillez mettre ces domaines sur liste blanche pour vous assurer que Cursor fonctionne correctement.

• ‘api2.cursor.sh’: Utilisé pour la plupart des demandes d'API.
• ‘api3.cursor.sh’Pour les demandes de tabulation du curseur (HTTP/2 uniquement).
• ‘repo42.cursor.sh’Pour l'indexation de la base de code (HTTP/2 uniquement).
• ‘api4.cursor.sh’(math.) genre‘us-asia.gcpp.cursor.sh’(math.) genre‘us-eu.gcpp.cursor.sh’(math.) genre‘us-only.gcpp.cursor.sh’: Utilisé pour les demandes de tabulation du curseur (HTTP/2 uniquement) en fonction de votre emplacement.
• ‘marketplace.cursorapi.com’(math.) genre‘cursor-cdn.com’: Permet de télécharger des extensions à partir de l'Extension Marketplace.
• ‘download.todesktop.com’Pour vérifier et télécharger les mises à jour.

Il convient de noter une caractéristique de sécurité qui diffère de VS Code :

1. Espace de travail fiduciaire Cette fonction est désactivée par défaut dans le curseur. Vous pouvez paramétrer l'option ‘security.workspace.trust.enabled’ fixé à ‘true’ pour l'activer. Il est désactivé par défaut pour éviter toute confusion entre le "mode restreint" de Workspace Trust et le "mode privé" de Cursor, et parce que ses propriétés de confiance sont complexes et difficiles à comprendre (par exemple, même si Workspace Trust est activé, vous n'êtes pas protégé contre les extensions malveillantes, mais seulement contre les dossiers malveillants). Nous invitons la communauté à nous faire part de ses commentaires sur la question de savoir si Workspace Trust devrait être activé par défaut.

Demandes d'IA

Pour fournir ses fonctionnalités, Cursor adresse des demandes d'IA à nos serveurs. Ces requêtes se produisent dans différents scénarios. Par exemple, nous envoyons une demande d'IA lorsque vous posez une question dans un chat, nous envoyons une demande d'IA à chaque fois que vous tapez pour que l'onglet Cursor puisse vous faire des suggestions, et nous pouvons également envoyer une demande d'IA en arrière-plan pour établir un contexte ou trouver des erreurs afin de vous alerter.

Les demandes d'IA contiennent généralement des informations contextuelles telles que les documents récemment consultés, les journaux de dialogue et des extraits de code pertinents basés sur les informations du serveur linguistique. Ces données de code sont envoyées à notre infrastructure basée sur AWS, puis transmises au fournisseur d'inférence de modèle linguistique approprié (Fireworks/OpenAI/Anthropic/Google). Notez que même si vous configurez votre propre clé API OpenAI dans vos paramètres, la demande sera toujours transmise en premier lieu à notre infrastructure sur AWS.

Pour l'instant, nous ne prenons pas en charge la connexion directe de l'application Cursor à votre déploiement d'entreprise d'OpenAI/Azure/Anthropic, car nos constructions de repères sont effectuées sur des serveurs et les modèles personnalisés sur Fireworks sont essentiels pour offrir une bonne expérience à l'utilisateur. Nous n'offrons pas encore d'option de déploiement de serveur auto-hébergé.

Vous êtes propriétaire de tout le code généré par Cursor.

Index de la base de code

Cursor vous permet d'indexer sémantiquement la base de code, ce qui permet de répondre à des questions dans le contexte de l'ensemble de la base de code et d'écrire un code de meilleure qualité en se référant à des implémentations existantes. L'indexation de la base de code est activée par défaut, mais peut être désactivée dans le processus de démarrage ou dans les paramètres.

Notre fonction d'indexation de la base de code fonctionne comme suit : lorsqu'elle est activée, elle analyse les dossiers que vous avez ouverts dans Cursor et calcule un arbre de Merkle des hachages de tous les fichiers.‘.gitignore’ peut-être ‘.cursorignore’ Les fichiers et sous-répertoires spécifiés dans l'arbre Merkle sont ignorés. L'arbre de Merkle est ensuite synchronisé avec le serveur. Toutes les 10 minutes, le hachage est vérifié et l'arbre de Merkle est utilisé pour identifier les fichiers modifiés et ne télécharger que ceux-ci.

Sur notre serveur, nous découpons et intégrons les fichiers et nous stockons l'intégration dans le fichier Turbopuffer en. Pour permettre le filtrage des résultats de la recherche de vecteurs par chemin de fichier, nous stockons un chemin de fichier relatif obscurci pour chaque vecteur, ainsi que la plage de lignes correspondant au morceau. Nous indexons également les embeddings par hash de chunk dans le cache AWS pour garantir que l'indexation de la même base de code une deuxième fois est plus rapide (ce qui est particulièrement utile pour les équipes).

Dans la phase d'inférence, nous calculons un encastrement, demandons à Turbopuffer d'effectuer une recherche du plus proche voisin, renvoyons les chemins d'accès aux fichiers obscurcis et les plages de lignes au client, et lisons ces morceaux de fichiers localement sur le client. Nous renvoyons ensuite ces blocs au serveur pour répondre aux questions de l'utilisateur. Cela signifie qu'aucun code en clair n'est stocké sur notre serveur ou dans Turbopuffer.

Quelques notes :

• même si ‘.cursorignore’ Il est possible d'empêcher l'indexation des fichiers, mais ceux-ci peuvent tout de même être inclus dans les demandes d'IA, par exemple lorsque vous avez récemment consulté un fichier et que vous avez ensuite posé une question dans le chat. Nous envisageons d'ajouter ‘.cursorban’ pour gérer les scénarios dans lesquels vous souhaitez empêcher l'envoi d'un fichier dans une requête - si vous êtes intéressé par cette fonctionnalité, veuillez envoyer un message dans les forums ou par l'intermédiaire du fichier hi@cursor.com Nous contacter.
• Détails de l'obscurcissement des chemins d'accès aux fichiers : les chemins d'accès sont passés à travers ‘/’ répondre en chantant ‘.’ Diviser et chiffrer chaque fragment à l'aide d'une clé stockée sur le client et d'un nombre aléatoire déterministe de 6 octets. Cette méthode laisse filtrer quelques informations sur la hiérarchie de l'annuaire et il y a quelques conflits de nombres aléatoires, mais elle cache la plupart des informations.
• Inversion de l'intégration : des recherches universitaires ont montré qu'il était possible d'inverser les intégrations dans certains cas. L'attaque actuelle repose sur l'accès au modèle et l'intégration de courtes chaînes de caractères dans de grands vecteurs, ce qui nous amène à penser qu'il est plus difficile d'effectuer cette attaque dans ce contexte. Cependant, si un adversaire s'introduit dans notre base de données de vecteurs, il peut avoir une certaine connaissance de la base de code indexée.
• Lorsque l'indexation de la base de code est activée dans un dépôt Git, nous indexons également l'historique Git. Plus précisément, nous stockons les SHA des livraisons, les informations sur les parents et les noms de fichiers obscurcis (comme ci-dessus). Pour permettre le partage des structures de données au sein d'un même dépôt Git et d'une même équipe, la clé pour l'obscurcissement des noms de fichiers est dérivée d'un hachage des livraisons les plus récentes. Les messages de validation et les contenus ou différences de fichiers ne sont pas indexés.
• Notre fonction d'indexation est généralement très sollicitée, ce qui peut entraîner l'échec de nombreuses demandes. Cela signifie que les fichiers doivent parfois être téléchargés plusieurs fois avant d'être entièrement indexés. L'une des manifestations de ce problème est que si vous regardez le fichier ‘repo42.cursor.sh’ du trafic sur le réseau et peut constater une utilisation de la bande passante qui dépasse les attentes.