J’ai lu les prompts des agents de sécurité de Cursor pour que vous n’ayez pas à le faire

Voici le prompt, dans son intégralité :

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.

C’est le cœur de l’automatisation Agentic Security Review de Cursor, qui examine plus de 3 000 PR internes par semaine et détecte plus de 200 vulnérabilités réelles. Une définition de rôle, un objectif, une méthodologie en quatre étapes et une liste de priorités. Pas de chaîne élaborée de raisonnement étape par étape. Pas des pages d’exemples few-shot. Pas de schémas JSON de sortie complexes.

Si vous m’aviez dit il y a deux ans qu’un prompt aussi concis pourrait fonctionner à cette échelle et produire des résultats justifiant de bloquer la CI, j’aurais été sceptique. Nous avons tous été conditionnés à penser que le prompting de l’IA exige une ingénierie complexe : des pages d’instructions, des exemples soigneusement conçus, des spécifications de sortie détaillées. Les modèles open source de Cursor suggèrent que, pour l’analyse de sécurité, une définition claire du rôle et une méthodologie structurée pourraient suffire.

C’est un signe remarquable de l’état actuel des modèles de pointe. Le modèle « sait » déjà à quoi ressemble une injection SQL, comment fonctionnent les contournements d’authentification et ce que signifie une désérialisation non sécurisée. Il lui faut simplement un cadre pour appliquer ces connaissances de manière systématique. Si les modèles peuvent déjà accomplir autant avec si peu d’instructions, les progrès attendus au cours des six à douze prochains mois sont vraiment enthousiasmants.

Bien sûr, le prompt n’est que la partie émergée de l’iceberg. La véritable prouesse d’ingénierie ne réside pas dans ces 15 lignes d’instructions, mais dans tout ce qui se trouve en dessous : le serveur MCP personnalisé qui gère la persistance et la déduplication, le pipeline de déploiement géré par Terraform, l’orchestration par webhook qui sait quel agent déclencher et quand, ainsi que la gestion d’état qui permet aux agents de comparer les résultats d’une exécution à l’autre. Le prompt est simple parce que l’infrastructure qui l’entoure ne l’est pas. C’est une distinction importante, et c’est en fait l’aspect le plus intéressant : Cursor ne s’est pas contenté d’écrire des prompts ingénieux ; l’entreprise a créé une plateforme d’orchestration d’agents de niveau production, puis l’a complétée par des prompts simples.

Mais avant de tirer des conclusions, examinons l’ensemble de ce que Cursor a créé, les points forts de chaque élément et les lacunes. Pour cela, il est utile de disposer d’un cadre de réflexion sur la sécurité dans les environnements de développement agentique.

Les trois dimensions de la sécurité agentique

Chez Snyk, nous envisageons la sécurisation du développement agentique selon trois dimensions : le code généré par les agents, la chaîne d’approvisionnement dont dépendent les agents et le comportement des agents eux-mêmes. La première dimension, celle du code, est celle sur laquelle la plupart des gens se concentrent : l’IA écrit-elle du code sécurisé, et détectons-nous les vulnérabilités avant leur mise en production ? La dimension de la chaîne d’approvisionnement est plus récente et moins évidente : les serveurs MCP, les modèles d’automatisation, les compétences des agents et les plugins sont autant de composants dont dépendent vos agents, et ils présentent les mêmes risques que toute dépendance tierce. La dimension du comportement est la plus nuancée : les agents agissent-ils dans les limites de leur périmètre prévu, prennent-ils des décisions qu’ils ne devraient pas prendre, et avez-vous une visibilité sur ce qu’ils font réellement dans votre organisation ?

Les agents de sécurité de Cursor interviennent principalement dans la première dimension : ils détectent les vulnérabilités dans le code. C’est un travail utile et nécessaire. Mais comme vous le verrez dans l’analyse ci-dessous, les deux autres dimensions sont tout aussi importantes, surtout à l’échelle d’une grande entreprise. Les organisations qui obtiennent les meilleurs résultats, comme Labelbox, qui a résorbé plusieurs années de retard dans le traitement des vulnérabilités en utilisant conjointement Cursor et Snyk, sont celles qui prennent en compte les trois dimensions.

Les quatre agents : leurs points forts et leurs lacunes

Aujourd’hui, Travis McPeak a publié un article de blog détaillant la manière dont l’équipe de sécurité de Cursor a créé quatre agents de sécurité autonomes reposant sur Cursor Automations (sa plateforme d’agents cloud) et publié leurs modèles en open source pour que tout le monde puisse les utiliser. Leur rythme de PR avait été multiplié par cinq en neuf mois, et l’analyse statique traditionnelle ne parvenait plus à suivre. Ils ont donc créé des agents capables de le faire.

L’ensemble du système repose sur une base qui mérite d’être mentionnée : un serveur MCP (Model Context Protocol) personnalisé, déployé comme fonction Lambda serverless. Il assure le suivi de l’état persistant, une couche de déduplication basée sur Gemini Flash 2.5 (pour éviter que différents agents signalent le même problème avec des mots différents) et un formatage uniforme des messages Slack avec des actions d’exclusion ou de mise en veille. Tout est géré par Terraform. Une ingénierie solide.

Voici les agents, avec ce que je trouve réellement impressionnant et les questions que les équipes de sécurité en entreprise devraient se poser.

Agentic Security Review : le gardien des PR

Fonctionnement : Examine chaque pull request au regard du modèle de menace spécifique de Cursor. Publie les résultats dans un canal Slack privé, commente directement les PR et peut bloquer le pipeline CI en cas de problème de sécurité. Ce qui le distingue d’un bot de revue généraliste comme Cursor’s Bugbot, c’est qu’il peut être ajusté spécifiquement pour la sécurité, sans bloquer chaque détail de qualité du code.

Ce qui est impressionnant : Les résultats parlent d’eux-mêmes. Au cours des deux derniers mois, cet agent a été exécuté sur des milliers de PR et a empêché la mise en production de centaines de problèmes. Et comme je l’ai montré plus haut, le prompt qui pilote tout cela est remarquablement concis. Pour un outil de revue basé sur un LLM, le rapport signal/bruit est vraiment surprenant.

Points à prendre en compte : Les LLM peuvent signaler avec assurance une « injection SQL critique » dans une requête paramétrée parfaitement sûre, parce que le modèle a mal interprété le flux de données. Ils peuvent aussi passer à côté d’une véritable vulnérabilité parce que leur attention se disperse dans une base de code volumineuse. En matière de sécurité, les deux types d’erreurs coûtent cher : les faux positifs érodent la confiance des développeurs, et les faux négatifs laissent de véritables vulnérabilités en production. Lorsque votre couche de détection est entièrement probabiliste, vous acceptez ces deux risques. Le principe est simple : l’agent ne peut pas corriger sa propre copie. Il vous faut une couche de validation indépendante qui confirme les résultats du LLM. C’est pourquoi il est important d’associer au contrôle du LLM une analyse SAST déterministe (comme Snyk Code). Le moteur déterministe détecte avec une précision mécanique les schémas connus ; le LLM repère les bugs logiques inédits qui s’étendent sur plusieurs fichiers et échappent aux outils fondés sur des règles. Il vous faut les deux.

Autre point à noter : regardez la fin du modèle de 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.

L’agent de revue ne propose pas de correctifs. Il détecte, signale et bloque, mais c’est toujours un humain qui décide de la suite. Même l’équipe de sécurité de Cursor maintient une intervention humaine dans sa propre chaîne d’outils. Cela en dit long sur la situation actuelle de la sécurité IA autonome : c’est un puissant accélérateur, pas un substitut au jugement humain. Du moins, pas encore.

Vuln Hunter : analyser la base de code existante

Fonctionnement : Au lieu de surveiller l’arrivée de nouveau code, Vuln Hunter analyse la base de code existante. Il divise le dépôt en segments logiques, recherche les vulnérabilités dans chacun d’eux, puis l’équipe de sécurité trie les résultats depuis Slack. Elle utilise souvent @Cursor directement depuis Slack pour générer des PR de correction.

Ce qui est impressionnant : Faire appel au raisonnement d’un LLM pour analyser du code ancien est une bonne idée. C’est là que l’IA excelle : comprendre des bases de code complexes et non documentées, et identifier des vulnérabilités qui échapperaient aux règles d’analyse statique. Bugs logiques répartis sur plusieurs fichiers, schémas de contrôle d’accès défaillants et contournements d’authentification enfouis dans du code vieux de plusieurs années. Les scanners traditionnels peinent dans ce domaine, car ils ont besoin de schémas bien définis à rechercher.

Points à prendre en compte : C’est l’agent le plus susceptible de produire des faux positifs à grande échelle. Analyser une base de code entière (au lieu d’un diff de PR ciblé) signifie que le modèle doit gérer un contexte beaucoup plus vaste, ce qui rend la dispersion de l’attention du LLM particulièrement préoccupante. BaxBench, un benchmark de l’ETH Zurich, de l’UC Berkeley et d’INSAIT, a révélé que 62 % des solutions générées par les meilleurs modèles sont incorrectes ou contiennent des vulnérabilités de sécurité. Lorsque le modèle raisonne sur des bases de code volumineuses et complexes, le principe selon lequel « l’agent ne peut pas corriger sa propre copie » s’applique doublement : vous voulez une validation déterministe qui confirme ou réfute les résultats du LLM avant que quiconque consacre du temps à un correctif.

Anybump : automatiser la mise à jour des dépendances

Fonctionnement : S’attaque à la tâche la plus fastidieuse de la sécurité des applications : la mise à jour des dépendances. Il exécute une analyse d’atteignabilité pour isoler les vulnérabilités ayant un impact réel, trace les chemins de code, lance des tests, vérifie qu’ils ne provoquent pas de régression et ouvre une PR si les tests réussissent. Le tout est automatisé, avec le pipeline de déploiement canary de Cursor comme dernier garde-fou.

Voici le cœur du 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.

Ce qui est impressionnant : Cela répond à un problème que toutes les équipes de sécurité connaissent bien. La mise à jour des dépendances prend tellement de temps que la plupart des équipes finissent par abandonner et par confier la tâche aux équipes d’ingénierie, où elle reste en attente pendant des mois, voire des années. Automatiser l’analyse d’atteignabilité, les tests et la création de PR améliore réellement le processus.

Points à prendre en compte : Anybump résout la partie la plus difficile de la gestion des dépendances : appliquer réellement le correctif, le tester et l’intégrer à une PR. Mais son périmètre s’arrête là. Il ne génère pas de SBOM, ne vérifie pas la conformité des licences et ne fournit pas de piste d’audit à votre équipe chargée de la conformité. Ce ne sont pas tant des lacunes de l’agent que des problèmes d’une tout autre catégorie. La mise à jour automatisée et l’analyse de composition logicielle pour les entreprises se recoupent, mais ce n’est pas la même chose. Si vous travaillez dans un secteur réglementé ou livrez des logiciels dans le cadre de contrats clients assortis d’exigences de conformité, vous aurez toujours besoin de cette infrastructure plus vaste, en complément de l’automatisation.

Si vous êtes une start-up avec un seul dépôt, Anybump pourrait vous suffire. Si vous exercez à l’échelle d’une grande entreprise (des centaines de dépôts, des secteurs réglementés, des contrats clients exigeant des certifications de conformité spécifiques), vous devez savoir exactement ce que contient votre logiciel, quelles licences vous utilisez et être en mesure de le prouver. C’est ce qui distingue la mise à jour automatisée de l’analyse de composition logicielle de niveau entreprise : elles se recoupent, mais répondent à des problèmes fondamentalement différents.

Invariant Sentinel : détecter les dérives de conformité

Fonctionnement : S’exécute chaque jour pour détecter les écarts par rapport à un ensemble de propriétés de sécurité et de conformité. Il lance des sous-agents pour chaque segment logique du dépôt, compare l’état actuel aux exécutions précédentes en s’appuyant sur la mémoire de l’automatisation et avertit l’équipe de sécurité en cas de changement.

Ce qui est impressionnant : La gestion de l’état est ingénieuse. En s’appuyant sur la mémoire de l’automatisation pour comparer les exécutions, l’agent peut détecter les changements de posture de sécurité, et pas seulement produire des instantanés ponctuels. La possibilité d’écrire et d’exécuter du code de validation en complément de l’analyse apporte une rigueur que le seul raisonnement d’un LLM ne pourrait offrir.

Points à prendre en compte : Détecter les dérives de conformité est utile, mais la gouvernance de la conformité est un défi plus vaste. Invariant Sentinel vous indique quand un changement s’est produit, mais ne fait pas appliquer des politiques sous forme de code à des centaines de dépôts, ne génère pas de rapports de conformité pour les auditeurs et ne fournit pas à votre CISO de tableau de bord présentant l’évolution des tendances de risque. Ce sont des fonctionnalités de plateforme qui dépassent ce qu’un agent isolé peut offrir.

La sécurité ne devrait pas commencer dans la CI

Voici ce qu’il est facile de manquer lorsqu’on examine les schémas d’architecture et l’orchestration des agents : au fond, Cursor a créé une couche CI très sophistiquée. Les agents se déclenchent via des webhooks GitHub à l’ouverture ou à la mise à jour de PR. Ils examinent les diffs, publient des commentaires, bloquent les pipelines et ouvrent des PR de correction. C’est fondamentalement le même point de contrôle que celui utilisé depuis des années par les outils de sécurité traditionnels, mais il est désormais plus intelligent grâce à un LLM qui réalise l’analyse, plutôt qu’à un moteur de règles fondé sur des expressions régulières.

Et soyons clairs : c’est une véritable amélioration, là-dessus, aucun doute. Mais la CI reste le mauvais endroit pour commencer à sécuriser.

Pourquoi la CI intervient trop tard pour la sécurité

Réfléchissez : si vous utilisez Cursor pour écrire du code dans votre IDE et que le code vulnérable arrive jusqu’à une PR avant que quelqu’un ne le détecte, vous avez déjà perdu du temps. Le développeur doit interrompre son travail sur le code qu’il vient d’écrire, le cycle de revue de la PR ajoute des délais et, si le contrôle CI bloque la PR, il doit alors revenir en arrière, comprendre le problème, le corriger, pousser à nouveau ses modifications et attendre un nouveau cycle de revue. C’est mieux que de découvrir la vulnérabilité en production, bien sûr, mais cela reste le modèle « analyser et créer un ticket », simplement condensé dans le cycle de la PR.

À quoi ressemble concrètement le décalage vers la gauche

Ce qu’il vous faut vraiment, c’est un outil de sécurité directement intégré à votre IDE, qui lance des analyses et applique immédiatement des correctifs dès que du nouveau code est ajouté. Ainsi, le code vulnérable n’est jamais intégré à un commit. L’historique Git reste propre. Vos PR ne sont pas bloquées, car les problèmes de sécurité sont détectés et corrigés dans le flux de travail, avant même que le développeur ne prépare ses modifications. Et vous réduisez considérablement le besoin de coûteuses revues avec intervention humaine : si la vulnérabilité n’arrive jamais dans une PR, personne n’a besoin de la trier et aucun pipeline n’est bloqué à 16 h 30 un vendredi.

Sécurité intégrée à l’IDE ou à la CI

Avec Snyk Studio, c’est exactement comme ça que ça fonctionne. Les garde-fous de sécurité interceptent le code non sécurisé avant même que le développeur n’accepte la suggestion de l’IA. L’assistant IA exécute snyk_code_scan sur le nouveau code en temps réel et, s’il détecte des problèmes de sécurité, les corrige directement dans le flux de travail. La solution fonctionne directement dans Cursor et dans tous les principaux assistants de programmation IA. Aucun blocage du pipeline CI, changement de contexte ou historique Git encombré.

Pourquoi la sécurité à plusieurs niveaux est indispensable

Imaginez maintenant que vous utilisiez les deux : Snyk Studio au niveau de l’IDE, qui détecte la grande majorité des problèmes dès leur apparition, et les agents de sécurité de Cursor au niveau de la CI, en filet de sécurité contre les problèmes qui passent entre les mailles du filet. Vous bénéficiez d’une défense en profondeur : l’essentiel du travail se fait discrètement dans l’IDE, tandis que les coûteuses revues humaines sont réservées aux cas réellement complexes. Au vu de ce que nous apprend BaxBench sur le taux d’insécurité du code généré par l’IA (62 % des solutions des meilleurs modèles contiennent des vulnérabilités ou sont incorrectes), cette protection à plusieurs niveaux n’est pas un simple plus. Elle est indispensable.

Et au-delà de la question de la CI, un programme de sécurité ne se résume pas aux contrôles CI. Il s’agit de tableaux de bord centralisés qui regroupent les risques de centaines de dépôts. Il s’agit de mettre en corrélation les résultats SAST et DAST afin de confirmer qu’un même point de terminaison est exploitable à l’exécution. Il s’agit de votre moteur SCA qui détecte que la bibliothèque ORM utilisée présente une CVE connue permettant de contourner la paramétrisation dans certains cas particuliers, et qui relie ce problème au résultat SAST dans la même méthode de contrôleur. Pris séparément, chacun de ces éléments n’est qu’un point de données. Mis en corrélation sur une même plateforme, ils vous indiquent précisément ce qui se passe, pourquoi et ce qu’il faut corriger en priorité. Un analyseur de code, même autonome et doté de quatre agents avec un débit impressionnant de PR, ne peut pas répondre à ces questions. Une plateforme de sécurité, oui.

Une validation, pas une concurrence (et nous sommes déjà intégrés)

J’ai écrit il y a quelques semaines au sujet du lancement de Claude Code Security par Anthropic, en expliquant pourquoi les investissements des plateformes de programmation IA dans la sécurité sont un signe de validation, pas une rupture. Le même raisonnement s’applique ici : lorsque les plus grands noms des outils de développement IA commencent à intégrer des fonctionnalités de sécurité, cela signifie que le secteur a compris que la sécurité du développement assisté par l’IA est une infrastructure, et non une option.

Comment Cursor et Snyk fonctionnent ensemble

Cursor et Snyk ne font pas que se croiser ; Snyk figure déjà dans le répertoire MCP de Cursor. Nous proposons une extension vérifiée. Nous distribuons Evo Agent Guard via Hooks. Depuis deux semaines, Cursor est notre partenaire de l’année pour l’innovation en IA. Il ne s’agit pas d’une relation antagoniste, mais d’une architecture à deux niveaux en action. Voyez les agents IA comme des chercheurs : ils détectent les vulnérabilités et proposent des correctifs avec rapidité et créativité. La validation déterministe joue le rôle d’une évaluation par les pairs, qui confirme de façon indépendante la réalité des résultats et la fiabilité des correctifs.

L’architecture de sécurité à deux niveaux

Vous ne publieriez pas un article sans évaluation par les pairs ; vous ne devriez pas non plus déployer un correctif de sécurité sans validation déterministe. Cursor fournit la couche de recherche (orchestration des agents, déclencheurs de webhook, génération automatique de PR). Snyk apporte l’évaluation par les pairs, la gouvernance et une couverture étendue de toute la chaîne d’approvisionnement logicielle.

Et cette approche fonctionne déjà dans la pratique : Labelbox utilise Cursor et Snyk conjointement en production et a pu résorber un arriéré de vulnérabilités accumulé sur plusieurs années. Cursor automatise les workflows de correction ; Snyk garantit que les correctifs sont fiables et adaptés aux exigences des entreprises.

La chaîne d’approvisionnement agentique est la nouvelle surface d’attaque

Prenons du recul par rapport à l’implémentation de Cursor et regardons ce qui se passe réellement dans le secteur. Au cours de l’année écoulée, une toute nouvelle chaîne d’approvisionnement logicielle a émergé et se développe rapidement : serveurs MCP, compétences d’agents, modèles d’automatisation, extensions d’outils IA et configurations de modèles personnalisées. Appelons-la la chaîne d’approvisionnement agentique. Elle regroupe les composants dont dépendent les outils de développement basés sur l’IA pour fonctionner et, à l’heure actuelle, presque personne ne les sécurise.

Ce n’est pas une préoccupation théorique. En janvier 2026, l’équipe de recherche de Snyk a découvert des centaines de compétences malveillantes sur ClawHub, lors de la première grande attaque visant la chaîne d’approvisionnement des écosystèmes d’agents IA. Pensez à cela dans le contexte de ce que Cursor vient de publier en open source : des modèles d’automatisation qui accèdent à votre base de code, à vos pipelines CI, à vos canaux Slack et à vos dépôts GitHub. Un serveur MCP déployé comme fonction Lambda et chargé de traiter chaque résultat de sécurité dans votre organisation. Ce sont des composants puissants et privilégiés. Pourtant, l’écosystème qui permet de les distribuer et de les découvrir (marketplaces, galeries de modèles, dépôts open source) se développe bien plus vite que les pratiques de sécurité qui devraient l’accompagner.

Il a fallu des décennies pour que la chaîne d’approvisionnement logicielle traditionnelle se dote des outils sur lesquels nous comptons aujourd’hui : registres de paquets avec vérification des signatures, SBOM, analyseurs de licences et bases de données de vulnérabilités. La chaîne d’approvisionnement agentique ne dispose pas encore de cette infrastructure, alors qu’elle est déjà adoptée à grande échelle. Chaque organisation qui installe des serveurs MCP, importe des modèles d’automatisation ou connecte des compétences d’agents à son environnement de développement étend sa surface d’attaque d’une manière à laquelle l’analyse du code, aussi sophistiquée soit-elle, ne peut tout simplement pas remédier.

C’est précisément le problème que Evo by Snyk a été conçu pour résoudre. Evo est notre système d’orchestration de la sécurité agentique, conçu pour le développement natif de l’IA : modélisation des menaces par l’IA, qui génère des modèles de menace à partir de votre code et les actualise en continu ; red teaming par l’IA, qui teste en permanence vos modèles et vos agents en simulant des attaques ; AI-SPM, pour savoir précisément quels modèles et frameworks d’IA sont utilisés dans votre organisation, y compris les « IA fantômes » inconnues des équipes de sécurité ; et analyse des agents, pour assurer la visibilité sur toutes les chaînes d’outils et appliquer des garde-fous en temps réel.

Si vous exécutez des agents de sécurité autonomes sur l’ensemble de votre base de code, vous devez également sécuriser ces agents. Les outils de votre chaîne d’approvisionnement agentique sont tout aussi critiques que les paquets npm de votre node_modules, et méritent le même niveau de rigueur.

Et maintenant : les questions que cela soulève

Plutôt que de conclure par une thèse que j’ai déjà exposée, terminons par les questions que l’annonce de Cursor soulève pour l’avenir. Car je trouve ces perspectives plus intéressantes que de revenir sur le passé.

Essayez par vous-même

Snyk Studio est gratuit et sa configuration ne prend que quelques minutes. Il fonctionne dans Cursor, ainsi que dans pratiquement tous les autres assistants de programmation IA. En cinq minutes environ, vous pourrez lancer dans votre IDE une analyse déterministe et la commande de correction /snyk-fix. Si vous souhaitez voir la sécurité à plusieurs niveaux en action, c’est le moyen le plus rapide.

Evo by Snyk est la solution à utiliser pour sécuriser la pile IA elle-même : modélisation des menaces, red teaming, AI-SPM, analyse des agents et orchestration de la sécurité agentique. Si votre organisation déploie des outils de programmation IA à grande échelle (et soyons réalistes, c’est probablement le cas), Evo vous offre la visibilité et les garde-fous nécessaires pour le faire en toute sécurité.

Les modèles d’automatisation de Cursor sont disponibles en open source sur GitHub. Si vous utilisez Cursor, ils méritent d’être explorés. Et si vous les utilisez avec Snyk, vous profitez du meilleur des deux mondes : l’automatisation par des agents, avec une validation répondant aux exigences des entreprises.

Tous les éléments sont réunis. Il est temps de les assembler.