MCP et les AI Agent Skills sont-ils sûrs ? 10 risques de sécurité à vérifier avant d’utiliser des outils d’IA tiers en 2026

Cette semaine, n’autorisez un serveur MCP ou un AI Agent Skill qu’après avoir vérifié sa provenance, ses permissions, ses flux de données et son mode d’exécution ; suspendez l’intégration si l’un de ces éléments reste invérifiable. Ces outils ne sont pas sûrs ou dangereux par nature : le risque dépend de la manière dont ils sont conçus, configurés et isolés.

Cet article s’adresse aux développeurs qui ajoutent des services MCP, aux personnes qui évaluent des AI Agent Skills tiers et aux équipes responsables de la sécurité des agents. Il vous aide à décider quoi inspecter avant d’accorder un accès.

Dernière mise à jour : 2026. Vérification documentaire fondée sur les ressources de sécurité du projet MCP, les documents de spécification des Skills, l’OWASP et le NIST cités ci-dessous.

MCP et les AI Agent Skills sont-ils sûrs ? Le verdict dépend des preuves

Évaluez chaque intégration selon des éléments que vous pouvez réellement examiner : qui la publie, qui la maintient, quels accès elle demande, quels contenus elle lit ou transmet, et ce qu’elle exécute. Un nom connu ou une description fonctionnelle ne démontre pas qu’un outil est sûr. À l’inverse, la seule présence d’un accès ou d’un script ne prouve pas qu’il est malveillant : il faut comprendre son rôle et vérifier qu’il correspond à la tâche.

Avant de poursuivre, rassemblez quatre preuves :

• Origine et maintenance : dépôt ou éditeur identifiable, historique des modifications, canal officiel de distribution et indications sur le maintien du projet.
• Permissions : opérations de lecture, d’écriture ou d’exécution possibles, ressources accessibles et limites prévues.
• Comportement : instructions, paramètres transmis, scripts et dépendances que vous pouvez examiner.
• Données : informations reçues, destinations auxquelles elles peuvent être envoyées, conservation éventuelle et traces laissées dans les journaux.

La documentation de sécurité du projet MCP décrit des considérations propres à la sécurité du protocole. Elle constitue un point de vérification, pas une attestation automatique pour chaque serveur tiers. De même, les recommandations de l’OWASP sur les contrôles de sécurité MCP peuvent guider votre revue, mais c’est l’implémentation que vous installez qu’il faut examiner.

Comment juger si un outil tiers est assez vérifiable ?

Utilisez une grille de décision interne. Elle sert à comparer vos options ; elle ne certifie ni le fournisseur ni la sécurité d’un composant.

Pour rendre l’examen reproductible, notez 0 si une preuve manque, 1 si elle est partielle et 2 si vous pouvez la vérifier pour chacun des quatre domaines : origine, permissions, comportement et données. Ce score maison, inspiré par les catégories de contrôle des ressources MCP et OWASP citées plus haut, n’est pas un résultat d’audit ni une norme de sécurité. Un score faible indique surtout quelles preuves obtenir avant de décider. Si vous ne pouvez pas expliquer la destination des données ou limiter une permission, suspendez l’accès même si le total semble acceptable.

Les risques d’accès et de manipulation dans MCP

Un serveur MCP peut présenter des opérations bien définies sans que cela suffise à garantir un usage sûr. Examinez ce que l’agent peut réellement appeler et le contexte dans lequel il le fera. L’analyse de sécurité de l’autorisation MCP est une référence utile pour examiner l’autorisation et les limites d’accès ; ne confondez pas présence d’un mécanisme d’autorisation et configuration correcte.

1. Permissions trop larges. Le risque apparaît si un outil censé consulter des documents peut aussi les modifier, lancer des opérations ou accéder à des ressources sans rapport avec sa tâche. Comparez chaque permission demandée à une action précise. Réduisez les droits au strict nécessaire et refusez ceux qui ne peuvent pas être justifiés.

2. Injection de consignes dans les résultats. Une page, un document ou une réponse d’outil peut contenir du texte qui tente de détourner l’agent : demander de révéler un secret, de changer de tâche ou d’appeler un autre outil. Le problème dépend de la façon dont l’agent interprète les données reçues ; ce n’est pas une conséquence automatique de MCP. Consultez le guide de l’OWASP sur la prévention des injections de consignes. Traitez les résultats externes comme des données non fiables, exigez une confirmation humaine avant les opérations sensibles et vérifiez les appels déclenchés par une réponse.

3. Transmission involontaire de données. Les paramètres d’appel, les extraits de contexte ou les résultats peuvent contenir des informations confidentielles et être envoyés à un service que vous n’aviez pas prévu d’utiliser. Relevez les entrées et sorties de chaque outil, les destinations réseau documentées et les journaux produits. Faites un test avec des données factices avant d’introduire des contenus métier. Si la destination ou la conservation des données ne peut pas être déterminée, ne connectez pas de données réelles.

À vérifier avant l’essai : observez les appels et leurs paramètres avec des données sans valeur. Un outil qui réussit une tâche ne vous dit pas, à lui seul, quelles informations il a reçues ni où elles ont été transmises.

Pour les contenus créatifs, cette distinction compte aussi. Un agent qui analyse des rushes audio, des références vidéo ou des fichiers de design peut avoir besoin de lire un dossier précis, mais pas d’accéder à l’ensemble du poste de travail. Définissez un espace de travail limité aux médias nécessaires et contrôlez les sorties avant de connecter l’agent à des fichiers de production.

La chaîne d’approvisionnement, les données sensibles et les outils en chaîne

L’examen ne s’arrête pas au composant principal. Des instructions, scripts, bibliothèques et autres outils peuvent intervenir entre le téléchargement et l’action finale. La documentation de la spécification des Skills pour MCP et les consignes de création d’un Skill peuvent aider à identifier les éléments à examiner. Elles ne remplacent pas la vérification de la copie que vous allez réellement utiliser.

4. Source ou dépendance compromise ou indéterminée. Ce risque est pertinent si vous ne pouvez pas rattacher le paquet à son éditeur, vérifier son historique ou comprendre les dépendances qu’il introduit. Contrôlez le canal de distribution, les changements récents et les avis publiés par le mainteneur. Si le contenu installé ne correspond pas à une source vérifiable, interrompez l’installation plutôt que de supposer qu’il est identique à la documentation.

5. Instructions de Skill qui contournent l’intention. Des instructions peuvent inciter l’agent à ignorer des restrictions, à traiter des données externes comme des ordres ou à poursuivre une action sans validation. Lisez le fichier d’instructions comme vous liriez une procédure d’exploitation : cherchez les demandes de secrets, les consignes de contournement et les actions sans lien avec le but annoncé. Limitez le Skill à une tâche définie et faites confirmer les opérations à impact élevé.

6. Scripts ou dépendances exécutant des opérations inattendues. Le risque existe lorsqu’un Skill lance des commandes, installe des dépendances ou modifie des fichiers sans que l’utilisateur en comprenne la portée. Examinez les scripts et les commandes avant exécution ; testez-les dans un espace séparé, avec des droits réduits et sans identifiants réels. Si un script est illisible ou obfusqué, ne l’exécutez pas sur votre environnement de travail.

7. Exposition de secrets dans la configuration ou les journaux. Une clé peut se retrouver dans un fichier de configuration partagé, dans le contexte fourni à l’agent ou dans un journal accessible à d’autres personnes. Vérifiez où les identifiants sont stockés, qui peut lire ces emplacements et si les traces conservent les entrées ou les résultats. Préférez des identifiants limités à l’usage prévu, gardez-les hors des instructions et remplacez-les dès qu’une exposition est soupçonnée.

8. Enchaînement d’outils et confusion d’autorité. Un outil peut sembler inoffensif isolément, mais fournir des données ou une capacité qu’un autre outil utilise ensuite pour accomplir une action non autorisée. Le scénario dépend de votre configuration et des autorisations accordées ; ne le généralisez pas à toutes les intégrations. Cartographiez les données qui passent d’un outil à l’autre, séparez les identités et imposez une confirmation avant une action qui modifie, publie ou transmet des informations.

Une revue limitée à chaque outil pris séparément peut manquer cet effet de chaîne. Pour le détecter, tracez un scénario complet : origine de la demande, outils appelés, données transmises, identité utilisée et conséquence finale. L’approche de l’OWASP sur l’excès d’autonomie des agents aide à examiner si l’agent dispose de plus de capacité que nécessaire. Réduisez le nombre d’actions qu’il peut réaliser sans confirmation, surtout lorsqu’une opération touche des comptes, des fichiers ou des communications externes.

Identités, audit et décision avant mise en production

Les contrôles doivent rester utiles après l’installation : vous devez pouvoir savoir qui a autorisé l’outil, retracer ses actions et interrompre son accès. Le NIST souligne l’importance d’une base solide pour l’identité des agents et des identifiants dans son article sur l’identité et les agents autonomes. Appliquez cette idée à votre cas d’usage : un agent, un compte humain et un service distant ne doivent pas être confondus dans vos journaux ou vos autorisations.

9. Authentification ou gestion des jetons insuffisantes. Le risque est présent si un jeton peut être réutilisé au-delà de sa tâche, si plusieurs agents partagent les mêmes identifiants ou si la révocation est incertaine. Vérifiez le propriétaire de chaque identité, la durée et la portée des autorisations, ainsi que la procédure pour retirer un accès. Évitez de réutiliser un jeton personnel dans des environnements ou des agents différents.

10. Audit, détection et retour arrière insuffisants. Sans journal exploitable, vous pouvez ne pas savoir quel outil a agi, avec quel compte et sur quelles données. Vérifiez que les opérations importantes sont enregistrées sans exposer les secrets, que les modifications peuvent être examinées et que vous savez désactiver l’intégration. Avant la mise en production, testez concrètement le retrait d’un accès et la restauration d’un état sûr.

Quels risques vérifier avant d’utiliser MCP ou un AI Agent Skill ?

Suivez un ordre qui vous oblige à produire des preuves, plutôt qu’à vous fier à une impression générale :

1. Identifiez la source : notez l’éditeur, le canal de distribution, le dépôt disponible et les informations de maintenance.
2. Comparez les permissions à la tâche : pour chaque accès en lecture, écriture ou exécution, indiquez pourquoi il est nécessaire. Retirez les accès superflus.
3. Examinez le comportement : lisez les instructions, les paramètres d’appel, les scripts et les dépendances. Recherchez les demandes de contournement ou les actions sans justification.
4. Suivez les données : repérez ce que l’agent transmet, à quel service, et ce qui peut apparaître dans les journaux. N’utilisez d’abord que des données factices.
5. Testez sous isolement : séparez l’environnement de test des comptes, fichiers et secrets de production. Réduisez les capacités disponibles et observez les appels réels.
6. Vérifiez les contrôles après installation : assurez-vous que les actions importantes sont journalisées, que les mises à jour sont vérifiables et que vous pouvez révoquer l’accès.

Comment régler les permissions et isoler l’exécution ? Commencez par des droits minimaux, un répertoire de travail limité et des identifiants distincts de ceux de vos comptes personnels ou de production. N’autorisez pas par défaut l’accès à tout le disque, à tous les dépôts ou à des commandes générales. Si vous ne pouvez pas limiter les droits, l’isolement doit être renforcé avant l’essai ; s’il reste impossible, refusez l’intégration.

Quand faut-il suspendre l’intégration ?

Suspendre signifie ne pas connecter de données réelles et ne pas donner d’identifiants, même si l’outil paraît utile. Faites-le lorsque vous ne pouvez pas confirmer l’origine ou la destination des données, lorsqu’un accès dépasse la tâche sans possibilité de le réduire, ou lorsque l’exécution d’un script reste opaque. Reprenez l’examen uniquement après avoir obtenu des éléments vérifiables ou modifié la configuration pour supprimer la cause du blocage.

Scénario hypothétique : votre équipe veut installer un Skill qui résume des maquettes et appelle un serveur MCP pour récupérer des documents. Le Skill demande aussi un accès en écriture à un espace de fichiers partagé, et la documentation ne précise pas où sont envoyés les extraits. Vous pouvez d’abord retirer l’accès en écriture, utiliser des fichiers factices et demander des précisions sur les destinations. Si les flux restent inconnus, la décision raisonnable est de ne pas connecter les maquettes ni les comptes réels ; l’utilité du résumé ne compense pas l’absence de contrôle.

Le poste local reste adapté si vous maîtrisez déjà son isolation, ses comptes et ses journaux. En revanche, faire les essais sur votre poste quotidien peut mêler environnement personnel, fichiers de travail et outils de test ; une machine de développement partagée peut aussi rendre moins claire l’attribution des accès. Si vos tests exigent macOS, une machine Mac louée auprès de VPSSpark peut être une autre façon de séparer un environnement d’essai du poste que vous utilisez chaque jour. Cela ne garantit pas la sécurité de MCP ou des Skills : vous devez toujours vérifier les accès, les données, les journaux et la procédure de révocation. Vous pouvez consulter une page de location Mac sans en déduire des propriétés de sécurité qui ne sont pas établies ici.

Pour un usage durable et fortement sollicité, l’achat et l’administration d’une machine peuvent être plus adaptés ; si vous avez besoin d’interfaces physiques ou d’un accès local direct, la location distante ne répondra pas forcément au besoin. Avant de retenir une solution, vous pouvez également présenter votre besoin à VPSSpark et consulter les informations sur VPSSpark. Dans tous les cas, la décision de louer un Mac ne remplace pas votre contrôle de sécurité : reprenez la grille, exigez des preuves pour les points non vérifiés et n’accordez les accès qu’après avoir défini leur limite et leur retrait.