Sécurité de Cursor : risques, contrôles et bonnes pratiques

Qu'est-ce que Cursor, et pourquoi change-t-il le modèle de sécurité ?

Cursor est un éditeur de code conçu d'abord pour l'IA, un fork de VS Code reconstruit autour du modèle plutôt qu'autour du fichier. Il fonctionne à l'intérieur du flux de travail habituel du développeur (l'éditeur, le terminal intégré, le panneau d'agent) et agit sur des instructions en langage naturel : explique cette base de code, construis cette fonctionnalité, corrige ce test qui échoue, refactorise à travers ces fichiers. Pour bien le faire, il indexe le dépôt afin que le modèle dispose du contexte, modifie plusieurs fichiers en une seule exécution d'agent, exécute des tâches et des commandes de terminal, et s'étend via le Model Context Protocol (MCP) pour atteindre des bases de données, des outils de suivi de tickets et de l'outillage interne.

Cette combinaison est ce qui brise l'ancien modèle de sécurité. Un assistant d'IDE classique proposait une complétion ; un humain la lisait et choisissait de l'accepter ou de la rejeter. Le rayon d'impact d'une mauvaise suggestion était un bloc de code qu'un développeur devait encore coller. Cursor accomplit des actions à la place. Il lit des fichiers que vous n'avez jamais nommés, exécute des commandes que vous n'avez jamais tapées, réécrit du code à travers l'arborescence, et peut exécuter une tâche à l'instant où vous ouvrez un dossier. La surface d'attaque n'est plus « qu'a suggéré le modèle ». C'est « que peut faire cet éditeur avec l'accès dont il dispose, quel code peut-il générer en volume, et qui peut influencer ses instructions ».

“

Une suggestion est un brouillon qu'un humain choisit d'accepter. Une action est une chose qui s'est déjà produite. Le modèle de sécurité doit passer de la revue des brouillons à la contrainte des actions.

Il y a un second basculement, et il concerne la vitesse. La pull request est devenue le foyer de la sécurité applicative parce qu'elle reposait sur la cadence humaine : une personne ralentissait, lisait le diff, et ne fusionnait qu'ensuite. Cursor ne fonctionne pas à la cadence humaine. Une seule session d'agent peut produire plus de code en un après-midi qu'un relecteur n'en lit en une semaine, et l'éditeur générera volontiers du code fonctionnel mais discrètement non sécurisé. Quand cela arrive, le diff cesse d'être un point de contrôle et devient une transcription de décisions déjà prises. Tout contrôle qui n'agit qu'au niveau de la pull request relit désormais l'histoire, au lieu de la prévenir.

Pour la plupart des équipes, la question pratique n'est pas de savoir si Cursor dispose de protections natives. C'est le cas, et plusieurs sont réellement bonnes. La question est de savoir si elles suffisent pour un usage quotidien. La réponse honnête est non. La propre page sécurité de Cursor documente de vrais contrôles, et ils réduisent le risque, mais une adoption sécurisée dépend toujours des permissions, de l'isolation, de la supervision humaine et de la validation indépendante à travers le code, les dépendances, les secrets et les pipelines.

Comment fonctionne le modèle de sécurité de Cursor

Le modèle de Cursor est bâti autour de trois idées : prouver que la plateforme gère les données de manière responsable, donner au développeur des leviers pour maintenir le code sensible hors de portée du modèle, et contenir ce qu'un projet ouvert est autorisé à faire. En pratique, cela se traduit par une poignée de contrôles.

C'est une base raisonnable, et la majeure partie n'existait pas dans les assistants d'IDE d'une génération précédente. Le piège est de la lire comme une frontière de sécurité achevée. Le Privacy Mode protège vos données mais ne dit rien sur la sécurité du code que Cursor écrit. .cursorignore ne fonctionne que si vous le maintenez. Workspace Trust ne vous protège que s'il est activé, et pendant une grande partie de l'histoire de Cursor, il ne l'était pas. SOC 2 atteste de la manière dont Cursor exploite son service, pas de la sécurité de son comportement sur votre machine. Chaque contrôle ici a une limite documentée, et la section suivante traite de ce qui se passe quand on s'y appuie trop fort.

Les 6 principaux risques de sécurité dans Cursor

Les risques ci-dessous ne sont pas théoriques. Ils correspondent à des vulnérabilités divulguées, à des recherches publiées et au OWASP Top 10 pour les applications LLM. Les chiffres qui les encadrent sont ceux que toute équipe AppSec cite désormais.

1. Workspace Trust désactivé par défaut, menant à une exécution de code silencieuse

C'est le problème emblématique de Cursor. En septembre 2025, The Hacker News a rapporté une faille (« Cursor AI Code Editor Flaw Enables Silent Code Execution via Malicious Repositories ») enracinée dans le fait que Workspace Trust était désactivé par défaut. Parce que Cursor est un fork de VS Code, un projet peut embarquer une tâche .vscode/tasks.json configurée avec runOn: folderOpen, et avec la confiance désactivée, cette tâche s'exécute à l'instant où un développeur ouvre le dossier, exécutant du code arbitraire dans le contexte de l'utilisateur.

L'attaque est banale à mettre en scène. Un attaquant publie un dépôt alléchant sur GitHub, y cache une tâche « autorun », et attend que quelqu'un le clone et l'ouvre dans Cursor. Aucun prompt, aucun clic, aucune revue : ouvrir le projet suffit à fuiter des identifiants, modifier des fichiers, ou implanter un point d'ancrage pour une compromission plus large. Les chercheurs (Oasis Security) ont recommandé la même mesure d'atténuation que nous : activer Workspace Trust, ouvrir d'abord les dépôts non fiables dans un autre éditeur, et auditer un projet avant de l'ouvrir dans Cursor. Le correctif tient en un réglage, mais il n'aide que les développeurs qui savent qu'il faut le basculer.

2. Code non sécurisé généré par l'IA

Le travail de Cursor est d'écrire du code vite, et vite ne veut pas dire sûr. Le benchmark SusVibes de Carnegie Mellon, qui suit des agents de codage commerciaux dont Cursor, a constaté que la meilleure combinaison agent + modèle produisait du code fonctionnellement correct 61 % du temps mais du code sécurisé seulement 10,5 % du temps, et que plus de 80 % des solutions fonctionnellement correctes portaient encore une vulnérabilité. L'écart entre « ça marche » et « c'est sûr » est l'endroit où vit le danger : du code qui passe le test et expédie la vulnérabilité.

Les schémas sont prévisibles. SQL concaténé par chaînes au lieu de requêtes paramétrées (l'injection SQL classique), pollution de prototype en JavaScript, encodage de sortie manquant qui ouvre une XSS, validation d'entrée absente sur les endpoints générés. Ce ne sont pas des bugs exotiques ; ce sont les classiques de l'OWASP, reproduits à la vitesse de la machine parce que le modèle a appris d'un corpus public qui en regorge. Le constat plus large de Veracode (45 % du code généré par l'IA échoue aux tests de sécurité, 62 % porte une faille de conception) se vérifie à travers les outils, et Cursor se situe résolument dans cette distribution. Plus l'éditeur expédie vite, plus les failles s'accumulent vite, et le code à l'apparence fonctionnelle est exactement celui qu'un relecteur pressé laisse passer.

3. Exposition des données et du contexte

Cursor est utile parce qu'il dispose de contexte, et ce contexte inclut régulièrement plus que du code source. Tout ce qui est ouvert dans l'espace de travail, un fichier .env, une configuration avec des chaînes de connexion, des endpoints d'API internes, peut être aspiré dans le contexte du modèle à moins que vous ne l'excluiez explicitement avec .cursorignore. Les fonctionnalités IA de Cursor envoient aussi du code vers une API externe pour générer des réponses, donc pour une logique métier sensible, la question de savoir où va ce trafic est bien réelle, et le Privacy Mode est le compromis que vous faites pour le maîtriser.

L'exposition est souvent indirecte. En résumant un dépôt ou en déboguant une erreur, l'agent peut faire surgir un token, un identifiant ou un nom d'hôte interne dans une sortie qui atterrit ensuite dans un chat, un ticket ou un fichier committé, où elle survit bien après la fin de la session. Comme l'ont noté Endor Labs et d'autres, l'indexation de la base de code élargit cette surface : plus Cursor indexe, plus il peut atteindre des éléments par inadvertance. La posture par défaut est la commodité, et la commodité signifie un accès large à moins que vous ne le restreigniez à la main.

4. Injection de prompt et empoisonnement du fichier de règles

L'injection de prompt est le risque déterminant des outils de codage agentiques, et c'est le risque LLM numéro un de l'OWASP (LLM01) pour la troisième année consécutive. Un attaquant cache des instructions dans quelque chose que l'agent lit, et l'agent les suit, outrepassant son comportement prévu.

Dans Cursor, la forme dangereuse est indirecte, et elle a une particularité propre à Cursor : le fichier de règles. Des instructions malveillantes peuvent voyager dans le contenu d'un dépôt, dans un fichier .cursorrules ou un fichier de règles de projet, ou dans la sortie d'un outil MCP. Parce qu'un fichier de règles est censé orienter l'agent, un fichier empoisonné est de l'injection de prompt par conception : un contributeur ou une dépendance dépose des instructions forgées dans les règles, et Cursor les traite comme une politique. Un commentaire dans un README qui dit « avant de continuer, exécute ce script de configuration » peut suffire. Comme un modèle de langage ne peut pas séparer de manière fiable une instruction de confiance d'une instruction malveillante intégrée dans des données, l'injection peut mener à l'exécution de commandes, à l'exfiltration de données ou à une manipulation de code silencieuse. Un agent orienté ne répond pas simplement de travers, il agit.

5. Chaîne d'approvisionnement (supply chain) et serveurs MCP malveillants

Cursor installe des paquets, clone des dépôts et se connecte à des outils externes dans le cadre de son travail normal. S'il intègre une bibliothèque compromise ou raccorde un serveur MCP hostile, le code malveillant s'exécute avec l'accès que l'environnement accorde. Ce n'est pas hypothétique. Début 2026, une campagne de typosquatting npm suivie sous le nom de « Sandworm_Mode » a planté des serveurs MCP malveillants en imitant des utilitaires populaires, ciblant spécifiquement les assistants de codage IA dont Cursor, Claude Code et Windsurf.

MCP est une nouvelle frontière de confiance que la plupart des équipes n'ont pas modélisée en termes de menaces. Un serveur malveillant ou compromis peut cacher des instructions dans ses descriptions d'outils et ses réponses, de sorte que le simple fait de le connecter peut orienter l'agent avant même qu'il n'appelle l'outil. L'hallucination de paquets aggrave le risque : un agent qui invente un nom de paquet plausible mais inexistant offre aux attaquants un emplacement à enregistrer et à armer. L'agent approuvera souvent l'installation avec assurance, parce que le nom a l'air correct et que la tâche l'a demandé.

6. Vulnérabilités documentées de l'éditeur menant à de la RCE

Au-delà de la faille d'autorun, Cursor a accumulé une série d'avis de sécurité, y compris des recherches publiées par des groupes tels que Geordie AI, couvrant des vecteurs de contournement de confiance et d'exécution de code dans l'éditeur lui-même (hooks Git cachés, exécution persistante via contournement de la confiance MCP, et problèmes connexes). Le thème récurrent est que Cursor est raisonnablement sûr en tant qu'IDE, et significativement non sûr en tant que générateur de code automatisé sans une couche de revue externe.

Le danger s'aggrave quand l'éditeur s'exécute avec un large accès à la machine du développeur. Une chaîne d'actions individuellement inoffensives, installe cette dépendance, exécute cette tâche, applique cette modification, peut installer un logiciel malveillant, altérer une configuration de CI, ou ouvrir un mécanisme de persistance. C'est exactement pourquoi le filtrage par la confiance, le moindre privilège et les environnements isolés comptent, et pourquoi la combinaison à redouter est la plus courante : un dépôt non fiable, une configuration permissive pour éviter les frictions, et une instruction injectée que l'éditeur traite comme légitime.

Ce que la sécurité native de Cursor couvre, et ce qu'elle ne couvre pas

Les contrôles natifs sont réels, et il est utile d'être précis sur la frontière entre ce qu'ils gèrent et ce qu'ils vous laissent.

Lisez la colonne de droite comme le vrai travail. Les contrôles natifs de Cursor sont orientés vers la confidentialité des données et la conformité du fournisseur, là où atterrissent les premières questions d'un acheteur. Ils n'ont jamais été conçus pour arrêter un adversaire déterminé qui contrôle les entrées de l'éditeur, et ils ne disent presque rien sur la sécurité du code que Cursor écrit. Tout ce qui transforme « Cursor est installé » en « Cursor est gouverné » vit dans les pratiques qui suivent.

Bonnes pratiques pour sécuriser Cursor

Ces neuf pratiques comblent l'écart entre la base native et une vraie posture de sécurité. Aucune n'est exotique ; la discipline réside dans leur application cohérente à travers une équipe qui avance vite.

1. Activez Workspace Trust, et traitez les dépôts non fiables comme hostiles. Activez Workspace Trust comme partie standard de la configuration, afin qu'un dossier ouvert ne puisse pas exécuter automatiquement une tâche. Ouvrez d'abord les dépôts que vous n'avez pas écrits dans un environnement en bac à sable (sandbox) ou un autre éditeur, auditez .vscode/tasks.json et tout hook Git avant de leur faire confiance, et ne parcourez jamais un dépôt public alléchant dans votre instance Cursor principale sans vérifier ce qu'il est autorisé à exécuter.

2. Gardez le Privacy Mode activé pour le travail sensible, et assumez le compromis. Le Privacy Mode est le contrôle qui empêche votre code d'être stocké ou utilisé pour l'entraînement. Traitez-le comme la valeur par défaut pour tout dépôt contenant une vraie logique métier, des données réglementées ou du code propriétaire. Là où une équipe choisit de le désactiver pour une fonctionnalité, faites-en une décision explicite et documentée, limitée au travail à faible sensibilité, et non un réglage par défaut discret que tout le monde a oublié de vérifier.

3. Soignez .cursorignore comme un artefact de sécurité. Excluez les fichiers .env, les magasins d'identifiants, la configuration d'infrastructure, les chaînes de connexion et tout module sensible, à la fois du contexte IA et de l'indexation. Révisez le fichier d'exclusion comme vous révisez le contrôle d'accès : selon un calendrier, après chaque nouveau secret ou service ajouté, et dans le cadre de l'intégration d'un nouveau dépôt. Un .cursorignore obsolète est la façon la plus courante pour qu'un secret finisse dans le contexte d'un modèle.

4. Gardez un humain dans la boucle sur le code généré. Traitez la sortie de Cursor comme un brouillon, et non comme une implémentation finie. Faites passer tout code généré ou modifié par la revue en pull request et les tests automatisés, avec un examen renforcé sur l'authentification, la validation des entrées, les requêtes SQL et les chemins privilégiés, précisément les domaines que les données SusVibes montrent le modèle rater. Le but n'est pas la défiance envers l'outil ; c'est qu'un éditeur produisant des milliers de lignes par jour produit des failles subtiles plus vite qu'elles n'apparaissent d'elles-mêmes.

5. Scannez le code généré par l'IA avec un SAST en CI. Parce que seule une petite fraction des solutions IA est sécurisée par défaut, un garde-fou d'analyse statique n'est pas optionnel. Exécutez un SAST sur chaque pull request, faites échouer le build sur les résultats de haute sévérité (injection SQL, XSS, pollution de prototype, autorisation manquante), et renvoyez les résultats aux développeurs pour que les mêmes classes cessent de réapparaître. Les tests fonctionnels n'attraperont pas un endpoint vulnérable mais fonctionnel ; seule une vérification soucieuse de la sécurité le fera.

6. Gouvernez les dépendances, les paquets et les serveurs MCP. Restreignez les installations aux registres de confiance ou aux miroirs internes, exigez une approbation pour les nouveaux paquets, et scannez tout avec une analyse de composition logicielle. Inspectez chaque serveur MCP comme une frontière de confiance : utilisez ceux que vous avez écrits ou en qui vous avez réellement confiance, limitez chacun aux données et actions les plus étroites dont il a besoin, et tenez un inventaire afin qu'un paquet typosquatté comme les serveurs « Sandworm_Mode » ne puisse pas se glisser sans être remarqué.

7. Gardez les secrets hors de portée. Maintenez les secrets en clair hors de l'espace de travail que l'agent peut voir. Utilisez un coffre-fort et injectez à l'exécution, expurgez les valeurs sensibles dans les journaux et les sorties, et ne laissez jamais de fichiers d'identifiants là où l'indexation de Cursor peut les atteindre. Si un secret apparaît un jour dans une transcription, un fichier généré ou un commit, faites-le tourner immédiatement et enquêtez sur la manière dont il est arrivé là.

8. Exécutez le travail à risque dans des environnements isolés et à moindre privilège. Utilisez des conteneurs ou des VM en bac à sable (sandbox) pour le travail assisté par IA sur du code non fiable, exécutez Cursor sans privilèges élevés, et bloquez les connexions sortantes non approuvées afin qu'une session compromise ne puisse pas exfiltrer. Segmentez les environnements par sensibilité pour que le travail à haut risque soit contenu et que le rayon d'impact d'une compromission unique reste réduit.

9. Définissez la politique par sensibilité de dépôt et d'environnement. Classez les dépôts (public, interne, réglementé, production) et appliquez des contrôles plus stricts aux plus sensibles : Privacy Mode activé, indexation restreinte, sortie réseau restreinte, revue plus exigeante. Pour les systèmes critiques, n'utilisez Cursor que dans des environnements sans chemin direct vers les identifiants de production, et documentez la politique pour que les développeurs sachent où l'aide de l'IA est autorisée et sous quelles contraintes.

Là où les contrôles natifs s'arrêtent : sécuriser l'agent au moment du prompt

Reparcourez les risques et un schéma émerge. Workspace Trust, le Privacy Mode, .cursorignore et le SAST agissent tous sur ce que l'éditeur a déjà décidé de faire, ou sur du code qu'il a déjà écrit. Ils se regroupent autour de la pull request, parce que c'est là que la sécurité applicative a toujours vécu. Mais la PR n'a jamais été un point de contrôle que parce qu'un humain la lisait, et à la cadence des agents plus personne ne la lit de bout en bout.

L'endroit où appliquer une règle n'est plus le diff ; c'est le prompt, avant que la ligne non sécurisée ne soit écrite. Quelle que soit la règle que vous voulez que Cursor suive, elle doit être entre ses mains au moment où il écrit, et non en attente dans un scanner qui arrive une fois que le code est sur le disque et que l'agent est passé à la tâche suivante.

C'est la couche qu'ajoute VibeDefend. C'est un CLI npm gratuit qui s'installe en environ cinq secondes et raccorde Cursor (en plus de Claude Code, OpenAI Codex, Windsurf et VS Code Copilot) à trois couches de gouvernance qui s'exécutent à l'intérieur de la boucle de l'agent.

Règles métier Les conventions de votre dépôt qui n'ont jamais été écrites (utiliser Decimal128 pour l'argent, l'autorisation passe par requireOwner). VibeDefend les extrait de la façon dont votre équipe code déjà et les charge dans le contexte de Cursor avant chaque modification. Règles de sécurité OWASP Top 10, SOC 2, RGPD et ISO 27001, chargés dès le jour de l'installation. L'agent lit le rappel applicable avant d'écrire, de sorte que l'exigence du référentiel devient une partie du code au lieu d'une case à cocher au moment de l'audit. Action Guard Les appels destructeurs (un sudo rm -rf, une lecture brute d'une variable d'environnement à l'allure de secret, un psql ad hoc contre un hôte de production) sont interceptés avant de se déclencher. Avertir ou bloquer selon la règle, avec chaque interception dans la piste d'audit.

Surtout, rien de votre code ne traverse le réseau. Les décisions se prennent localement, à côté de l'agent ; seules des métadonnées de gouvernance structurées (la règle qui s'est déclenchée, le chemin du fichier, la sévérité, un horodatage) atteignent le backend. Les tenants UE et US sont physiquement séparés, et vous choisissez la région au moment de l'installation. Ce modèle de confidentialité est ce qui permet à un contrôle de se placer aussi près du code sans devenir lui-même un risque d'exfiltration de données, la même préoccupation qui fait du propre Privacy Mode de Cursor un compromis.

Ce n'est pas un remplacement des pratiques ci-dessus. C'est la couche manquante qu'elles supposent exister : celle qui met vos règles entre les mains de Cursor au moment du prompt, afin que la ligne non sécurisée soit réécrite avant même d'être suggérée, au lieu d'être attrapée trois étapes plus tard par un scanner lisant un diff que personne n'avait le temps de lire. Workspace Trust empêche l'éditeur de faire ce qu'il ne doit pas faire ; VibeDefend façonne ce qu'il écrit en premier lieu.

Foire aux questions

Cursor est-il sûr ?

Cursor est sûr à utiliser quand il est configuré et contenu, et risqué quand il ne l'est pas. Sa conformité SOC 2 Type II, son Privacy Mode, .cursorignore et Workspace Trust préviennent une vraie catégorie de fuites de données et d'accidents. Le risque résiduel vient des valeurs par défaut (Workspace Trust historiquement désactivé, indexation large), du code qu'il génère (seule une petite fraction est sécurisée d'emblée), des entrées (injection de prompt, fichiers de règles empoisonnés, serveurs MCP malveillants), et de l'environnement alentour (secrets exposés, dépôts non fiables). Traitez-le comme un agent puissant qui a besoin de filtrage par la confiance, d'exclusion des secrets, de revue humaine et de SAST, et non comme un outil sécurisé par défaut.

Cursor envoie-t-il mon code dans le cloud ?

Oui. Les fonctionnalités IA de Cursor envoient du code vers une API externe pour générer des réponses, ce qui peut inclure le contenu des fichiers et le contexte environnant de votre tâche. Le Privacy Mode change ce qui advient de ce code du côté de Cursor : avec lui activé, votre code n'est ni stocké ni utilisé pour entraîner des modèles. Pour une logique métier sensible, gardez le Privacy Mode activé, excluez les secrets et les données réglementées du contexte avec .cursorignore, et confrontez la politique de traitement des données de Cursor sur cursor.com/security à vos propres exigences.

Qu'est-ce que .cursorignore et pourquoi est-ce important ?

.cursorignore est un fichier (similaire dans l'esprit à .gitignore) qui indique à Cursor quels chemins exclure du contexte de l'IA et de l'indexation de la base de code. C'est important parce que, par défaut, tout ce qui est ouvert dans l'espace de travail peut être aspiré dans le contexte du modèle, y compris les fichiers .env, les configurations et les chaînes de connexion. Un .cursorignore bien maintenu est le levier principal qui garde les secrets et les modules sensibles hors de portée du modèle. Un fichier obsolète est la façon la plus courante pour qu'un identifiant finisse dans une requête IA.

Devrais-je activer Workspace Trust dans Cursor ?

Oui. Workspace Trust place les fonctionnalités d'exécution de code d'un dossier ouvert derrière une décision de confiance explicite. C'est la mesure d'atténuation directe pour la faille de septembre 2025 où un dépôt piégé pouvait exécuter automatiquement une tâche et exécuter du code à l'instant où vous ouvriez le dossier. Parce que Cursor était historiquement livré avec Workspace Trust désactivé par défaut, son activation devrait faire partie standard de votre configuration. Associez-la au fait d'ouvrir d'abord les dépôts non fiables dans un bac à sable (sandbox) ou un autre éditeur.

Cursor peut-il exécuter du code d'un dépôt automatiquement ?

Il le peut, si Workspace Trust est désactivé. En tant que fork de VS Code, Cursor honore les tâches configurées avec runOn: folderOpen, donc un .vscode/tasks.json malveillant dans un dépôt que vous clonez et ouvrez peut s'exécuter immédiatement, sans aucun prompt, dans votre contexte utilisateur. C'était le fondement de la faille d'exécution de code silencieuse rapportée en septembre 2025. Activer Workspace Trust comble la brèche, mais le comportement par défaut est la raison pour laquelle vous ne devriez jamais ouvrir un projet non fiable dans votre instance Cursor principale.

Le Privacy Mode de Cursor le rend-il sûr ?

Non, et il est important d'être précis ici. Le Privacy Mode est un contrôle de données : il garantit que votre code n'est ni stocké sur les serveurs de Cursor ni utilisé pour l'entraînement. Il ne dit rien sur la sécurité du code que Cursor génère, sur le fait qu'un dépôt puisse exécuter automatiquement une tâche, sur le fait qu'une injection de prompt puisse orienter l'agent, ou sur le fait qu'un serveur MCP soit malveillant. Le Privacy Mode protège vos données ; il ne protège pas votre application. Vous avez toujours besoin de Workspace Trust, de .cursorignore, d'un SAST, d'une revue humaine et d'un contrôle au moment du prompt.

En quoi la sécurité de Cursor diffère-t-elle de celle de Claude Code, GitHub Copilot ou Codex ?

Les fondamentaux sont partagés (moindre privilège, exclusion des secrets, revue humaine, analyse des dépendances), mais les surfaces diffèrent. Les problèmes distinctifs de Cursor sont Workspace Trust livré désactivé par défaut et un taux élevé de code généré non sécurisé ; celui de Claude Code est son intégration profonde de MCP et du shell ; celui de GitHub Copilot est les suggestions non sécurisées et la fuite de secrets à grande échelle ; celui de Codex est l'injection de commandes et les incidents de chaîne d'approvisionnement. Nous couvrons chaque agent dans son propre guide : Claude Code, GitHub Copilot et OpenAI Codex.