Deux briques qui élargissent la surface d’attaque

Un serveur MCP expose des outils — lire un ticket, créer un événement, interroger une base — et parfois des ressources. Le client, par exemple un assistant de code ou une application d’agent, décide de les appeler. Le RAG, ou génération augmentée par récupération, cherche les passages pertinents dans une base documentaire, souvent une base vectorielle, et les place dans le prompt. Dans les deux cas, le modèle reçoit du texte qu’il n’a pas écrit et dispose de capacités qu’il n’avait pas : c’est exactement le terrain de l’injection de prompt indirecte et des permissions excessives.

MCP : les attaques décrites par la spécification

La page « Security Best Practices » de la spécification MCP (version 2026-07-28) détaille plusieurs classes d’attaques et leurs parades :

  • Député confus : un serveur MCP qui sert de relais vers une API tierce avec un identifiant client unique peut, sans consentement propre à chaque client, laisser un attaquant obtenir un code d’autorisation. Parade : consentement par client, vérifié avant de transmettre la demande.
  • Retransmission de jetons : accepter un jeton émis pour un autre service et le transmettre tel quel est explicitement interdit. Un serveur MCP ne doit accepter que les jetons qui lui sont destinés.
  • Requêtes forgées côté serveur : pendant la découverte OAuth, un serveur malveillant peut fournir des URL internes, comme celles des services de métadonnées du cloud. Parade : HTTPS obligatoire, blocage des plages d’adresses privées, validation des redirections, proxy de sortie.
  • Détournement d’identifiants d’état : un identifiant de panier ou de flux deviné ne doit jamais valoir authentification ; il doit être aléatoire et lié côté serveur à l’utilisateur authentifié.
  • Compromission d’un serveur local : un serveur installé en un clic exécute une commande sur votre machine. Le client doit afficher la commande exacte et obtenir un accord explicite ; l’exécution en bac à sable est recommandée.
  • Portée minimale : commencer par des permissions de lecture et n’accorder des droits supplémentaires qu’au moment où une opération les demande.

Choisir et installer un serveur MCP

  1. Préférer les serveurs que vous écrivez vous-même ou ceux de fournisseurs de confiance : Anthropic rappelle qu’il examine les connecteurs de son annuaire sans auditer la sécurité des serveurs MCP.
  2. Lire la commande exacte de démarrage et le code du serveur, épingler la version et suivre ses mises à jour.
  3. Relire la configuration MCP d’un dépôt avant de faire confiance à l’espace de travail, comme le recommande VS Code.
  4. Utiliser le transport local stdio pour un serveur local, ou exiger une authentification pour un serveur HTTP.
  5. Accorder des jetons à portée minimale, distincts par serveur, révocables.
  6. Activer l’approbation des appels d’outils, en lecture comme en écriture, comme le conseille OpenAI.
  7. Exécuter les serveurs non maîtrisés dans un conteneur, avec un accès réseau et fichiers restreint.

RAG : empoisonnement et fuite par les sources

L’OWASP Top 10 LLM 2026 consacre deux risques à ce sujet : l’empoisonnement des données et du modèle (LLM05) et les faiblesses des vecteurs et des embeddings (LLM09). Concrètement :

  • Un document piégé ajouté à la base peut orienter les réponses de tous les utilisateurs qui le font remonter, ou contenir des instructions d’injection. Contrôlez qui peut alimenter la base, gardez la provenance de chaque document et surveillez les ajouts.
  • Une base partagée sans contrôle d’accès laisse un utilisateur obtenir des extraits de documents qu’il n’aurait pas le droit d’ouvrir. Le filtrage doit se faire au moment de la récupération, selon les droits de la personne qui pose la question, et les espaces de différents clients doivent rester séparés.
  • Des embeddings exposés ne sont pas anonymes : ils dérivent du texte d’origine et doivent être protégés comme lui.
  • Des réponses non sourcées empêchent de vérifier. Faites citer les passages utilisés et refusez de répondre quand aucune source fiable n’est trouvée.

La CISA, la NSA et le FBI insistent sur la provenance et l’intégrité des données utilisées par l’IA ; le NIST classe l’empoisonnement parmi les grandes familles d’attaques adverses.

Exemple : un assistant interne branché sur le drive

Une entreprise veut un assistant qui répond aux questions de l’équipe à partir de son drive. Conception prudente : un connecteur en lecture seule, avec un jeton propre à l’assistant ; une récupération qui respecte les droits de chaque utilisateur ; les dossiers RH et financiers exclus par défaut ; chaque réponse accompagnée de ses sources ; toute instruction trouvée dans un document signalée et ignorée ; aucun outil d’envoi ou de partage externe ; un journal des questions et des documents consultés, sans leur contenu complet. Notre article sur la version 2026-07-28 de MCP détaille les évolutions récentes du protocole.

Ce que Prompt OS ajoute à la mission

Lorsqu’une mission mentionne MCP, des connecteurs, des plugins, une base documentaire ou un RAG, Prompt OS recommande « Sécurité MCP, plugins et connecteurs », « Sécurité RAG et base de connaissances » et « Provenance et sources », en plus de la protection contre l’injection indirecte et des permissions minimales. La mission demande alors explicitement la liste des connecteurs et de leurs droits, le filtrage des documents par utilisateur et le traitement des documents comme des données non fiables. Voir aussi la sécurité des agents IA.

Conclusion

MCP et RAG ne sont ni dangereux ni sûrs par nature : ce sont des canaux. Leur sécurité dépend des droits qu’on leur donne et de la confiance qu’on accorde à ce qui y circule. Appliquez-leur la même rigueur qu’à une dépendance logicielle ou à une API exposée.