Agents IA / Cybersécurité
Cursor, Claude Code et MCP : comment sécuriser les assistants de développement IA
Les assistants de développement ne se contentent plus de proposer quelques lignes de code. Des outils comme Cursor, Claude Code, GitHub Copilot et les environnements connectés au Model Context Protocol peuvent désormais :
8 min de lecture
Introduction
Les assistants de développement ne se contentent plus de proposer quelques lignes de code.
Des outils comme Cursor, Claude Code, GitHub Copilot et les environnements connectés au Model Context Protocol peuvent désormais :
Cette autonomie accélère fortement le travail des développeurs.
Elle transforme aussi la nature du risque.
Lorsqu’un assistant peut uniquement suggérer du texte, une mauvaise réponse crée surtout une erreur de code. Lorsqu’il dispose d’un accès au terminal, au système de fichiers ou à des connecteurs, une instruction malveillante peut devenir une action réelle.
Les vulnérabilités dévoilées en 2026 dans plusieurs outils et frameworks montrent que la prompt injection ne doit plus être considérée comme un simple problème de conversation. Elle peut devenir un vecteur d’exécution de code, de fuite de secrets ou de modification d’un dépôt.
- lire un dépôt complet ;
- créer ou modifier des fichiers ;
- exécuter des commandes ;
- installer des dépendances ;
- interagir avec GitHub ;
- lancer des tests ;
- consulter de la documentation ;
- utiliser des secrets ;
- appeler des API ;
- déployer une application.
Pourquoi les assistants de code créent une nouvelle surface d’attaque
Un assistant de développement reçoit des informations provenant de nombreuses sources :
Le modèle ne distingue pas toujours parfaitement une donnée à analyser d’une instruction à suivre.
Un attaquant peut donc placer une consigne cachée dans une source que l’assistant va lire.
Par exemple, un fichier de documentation pourrait contenir une instruction demandant à l’agent d’ignorer ses règles précédentes, de lire une variable d’environnement puis de l’envoyer vers un service externe.
Pour un humain, cette chaîne peut sembler absurde. Pour un agent disposant des bons outils et de permissions trop larges, elle peut devenir exécutable.
- instructions de l’utilisateur ;
- fichiers du dépôt ;
- commentaires dans le code ;
- issues GitHub ;
- pull requests ;
- pages web ;
- documentation externe ;
- réponses d’un serveur MCP ;
- sorties de commandes ;
- messages d’erreur.
Qu’est-ce qu’une prompt injection indirecte ?
Une prompt injection directe est saisie par l’utilisateur dans la conversation.
Une prompt injection indirecte est présente dans un contenu externe consulté par l’agent :
L’utilisateur ne voit pas nécessairement l’instruction malveillante.
L’agent la découvre pendant son travail et peut l’interpréter comme une consigne légitime.
C’est cette combinaison entre contenu non fiable et capacité d’action qui rend le risque important.
L’OWASP classe la prompt injection comme le premier risque de son Top 10 consacré aux applications reposant sur des modèles de langage.
- page web ;
- document ;
- dépôt ;
- commentaire ;
- courrier électronique ;
- résultat d’un outil ;
- serveur MCP compromis.
Quand un prompt peut devenir une commande système
En mai 2026, Microsoft a publié une recherche montrant comment des vulnérabilit és dans le framework Semantic Kernel pouvaient transformer une prompt injection en exécution de code sur la machine hôte.
Le scénario ne reposait pas sur une pièce jointe classique ou une faille du navigateur. L’agent faisait ce pour quoi il avait été conçu : interpréter une instruction, sélectionner un outil et transmettre des paramètres à du code.
En juin 2026, Microsoft a également présenté AutoJack, une chaîne d’exploitation dans laquelle une page web malveillante pouvait conduire un agent de navigation à interagir avec une interface MCP locale et à exécuter des processus sur la machine.
Les versions concernées ont été corrigées, mais le principe reste essentiel : un agent connecté à des outils doit être sécurisé comme une application capable d’agir, pas comme un simple chatbot.
MCP : puissant, mais pas magique
Le Model Context Protocol facilite la connexion d’un assistant IA à des outils, des fichiers, des bases de données et des services.
Il apporte une structure commune, mais il ne supprime pas les responsabilités de sécurité.
La spécification MCP recommande notamment :
Un serveur MCP communautaire doit être considéré comme un logiciel tiers.
Il peut contenir une erreur, demander trop de droits ou évoluer après son installation.
- de valider les entrées des outils ;
- d’appliquer des contrôles d’accès ;
- de limiter le nombre d’appels ;
- de nettoyer les sorties ;
- de montrer les paramètres sensibles à l’utilisateur ;
- de demander une confirmation avant les actions importantes ;
- de journaliser l’utilisation des outils ;
- de séparer les jetons d’accès selon leurs destinataires.
Les neuf règles essentielles pour sécuriser un assistant de développement
1. Appliquer le principe du moindre privilège
L’agent ne doit avoir accès qu’aux fichiers, dépôts, commandes et services nécessaires à sa mission.
Un assistant chargé de modifier la documentation ne doit pas disposer de secrets de production.
Un agent travaillant sur un dépôt ne doit pas avoir automatiquement accès à tous les dépôts de l’organisation.
2. Séparer les environnements
Les expérimentations doivent être réalisées dans un environnement isolé :
L’assistant ne doit pas expérimenter directement sur la production.
- branche dédiée ;
- conteneur ;
- machine virtuelle ;
- bac à sable ;
- compte de test ;
- données fictives.
3. Exiger une validation pour les actions sensibles
La confirmation humaine doit être obligatoire avant :
La validation doit afficher la commande complète et ses paramètres.
- l’exécution d’une commande destructive ;
- l’installation d’un paquet ;
- la modification d’un workflow CI/CD ;
- l’accès à un secret ;
- la création d’un utilisateur ;
- le déploiement ;
- la suppression de fichiers ;
- l’envoi de données vers l’extérieur.
4. Ne pas exposer inutilement les secrets
Les clés API, jetons, mots de passe et certificats ne doivent pas être placés dans les prompts ou les fichiers de documentation.
Utilisez des gestionnaires de secrets et attribuez des jetons limités :
Un secret disponible dans l’environnement d’un agent peut être lu si une chaîne d’exploitation réussit.
- à un service ;
- à un dépôt ;
- à un environnement ;
- à une durée ;
- à un périmètre d’action.
5. Vérifier les serveurs MCP
Avant d’ajouter un serveur MCP :
Supprimez les connecteurs inutilisés.
- vérifiez son éditeur ;
- examinez son code si possible ;
- contrôlez les permissions demandées ;
- identifiez les données accessibles ;
- lisez les commandes exécutées ;
- testez-le dans un environnement isolé ;
- surveillez ses mises à jour.
6. Traiter le contenu externe comme non fiable
Un fichier, une page web ou une issue GitHub peut contenir des instructions malveillantes.
L’agent doit être configuré pour distinguer les données à analyser des instructions autorisées.
Cette séparation ne sera jamais parfaite. Elle doit être complétée par des limites techniques.
7. Valider les sorties avant exécution
Le code ou les commandes proposés par l’IA doivent être contrôlés comme ceux d’un contributeur externe.
Prévoyez :
L’IA peut accélérer la production de code. Elle peut aussi accélérer la production d’erreurs.
- revue de code ;
- tests ;
- analyse statique ;
- scan de dépendances ;
- détection de secrets ;
- contrôle des changements de permissions ;
- validation des fichiers de configuration.
8. Journaliser les actions
Conservez au minimum :
Ces traces sont utiles pour comprendre un incident, mais aussi pour améliorer les règles de l’agent.
- l’identité de l’utilisateur ;
- l’agent utilisé ;
- les outils appelés ;
- les commandes exécutées ;
- les fichiers modifiés ;
- les validations humaines ;
- les erreurs ;
- les accès aux données sensibles.
9. Maintenir les outils et frameworks à jour
Les assistants, extensions, frameworks et serveurs MCP évoluent rapidement.
Il faut :
L’innovation rapide ne justifie pas l’absence de gestion des versions.
- suivre les avis de sécurité ;
- mettre à jour les versions ;
- retirer les composants abandonnés ;
- contrôler les dépendances ;
- tester les changements ;
- révoquer les anciens jetons.
Une architecture plus sûre pour les équipes techniques
Une architecture minimale peut s’organiser en quatre zones.
Zone 1 — Interaction
L’utilisateur formule la demande et visualise les actions proposées.
Zone 2 — Orchestration
L’agent raisonne, sélectionne les outils et prépare les commandes.
Zone 3 — Exécution isolée
Les commandes sont exécutées dans un environnement limité, sans accès direct à la production.
Zone 4 — Validation et déploiement
Les changements passent par les contrôles habituels : pull request, tests, revue, approbation et pipeline.
Cette architecture évite de transformer l’assistant en administrateur universel.
Faut-il interdire les assistants de développement IA ?
Non.
Une interdiction générale ferait perdre un avantage important et pousserait probablement certains usages hors du contrôle de l’entreprise.
La bonne stratégie consiste à définir :
Un assistant correctement encadré peut améliorer la qualité, la documentation et la vitesse de développement.
Un assistant mal configuré peut concentrer trop de droits dans une interface conçue pour être simple.
- les outils autorisés ;
- les environnements autorisés ;
- les données accessibles ;
- les actions nécessitant une validation ;
- les contrôles obligatoires ;
- les règles de journalisation ;
- le processus de gestion des incidents.
De l’assistant utile à l’agent maîtrisé
Plus un système gagne en autonomie, plus l’entreprise doit renforcer :
La question ne doit pas être uniquement : « Quel modèle est le plus performant ? »
Il faut aussi demander : « Que peut-il faire, avec quels droits, sur quelles données et sous quel contrôle ? »
- l’identité ;
- les permissions ;
- la supervision ;
- la traçabilité ;
- les tests ;
- la capacité à interrompre l’action.
Formez vos équipes à construire des agents IA utiles et sécurisés
Soft Power Formation accompagne les équipes qui souhaitent passer des assistants IA aux agents et aux automatisations, tout en conservant une maîtrise humaine et technique.
Les formations permettent de comprendre les architectures, les connecteurs, les permissions, les risques et les bonnes pratiques avant d’industrialiser les usages.
Recevoir les programmes + un guide IA offert
Pour aller plus loin
Ces ressources internes permettent de prolonger la lecture avec les formations et articles les plus proches du sujet.
Sources de référence
Les sources ci-dessous sont des références officielles ou reconnues utilisées pour cadrer les points de vigilance de cet article.
Passer à la pratique
Passez de la lecture à la pratique
Soft Power Formation accompagne les dirigeants, équipes métiers et profils techniques avec des formations IA concrètes, centrées sur les usages, la sécurité, la gouvernance et l’automatisation.