Le risque caché dans les connecteurs d’IA

La partie la plus dangereuse d’un connecteur d’IA n’est peut-être pas le code que votre équipe a relu. Elle peut tenir dans une phrase discrète, placée dans la description de l’outil, qui indique à l’agent ce qu’il doit obéir.

C’est la leçon dérangeante d’une recherche sur la sécurité MCP publiée le 5 mai 2026. Un article de modélisation des menaces du Journal of Cybersecurity and Privacy a identifié le tool poisoning comme la vulnérabilité côté client la plus fréquente et la plus importante dans sept grands clients MCP. Pas un ransomware, pas un logiciel malveillant spectaculaire, mais des métadonnées : descriptions, schémas, exemples et consignes.

MCP, ou Model Context Protocol, devient la plomberie qui permet aux agents d’IA de parler à des calendriers, bases de données, dépôts de code, navigateurs et outils internes. La promesse est simple : donner des mains utiles au modèle. Le risque caché l’est tout autant : chaque nouvelle main peut chuchoter une instruction.

La faille précède le premier appel d’API

Le tool poisoning fonctionne parce que les agents ne lisent pas seulement la demande de l’utilisateur. Ils ingèrent aussi les descriptions d’outils, les schemas, les noms, les exemples et les consignes qui expliquent comment utiliser chaque connecteur. Si cette couche contient un ordre malveillant, l’agent peut le traiter comme un contexte opérationnel.

Cela renverse le récit classique de la sécurité. Une organisation peut approuver un connecteur parce que l’endpoint paraît normal, que le périmètre OAuth semble raisonnable et que le fournisseur inspire confiance. Pendant ce temps, l’attaque se loge dans la couche la plus souple de l’intégration : les mots qui orientent le comportement du modèle.

Si vous avez déjà lu comment hidden web prompts hijack AI browser agents, le mécanisme est familier. Il se rapproche simplement de la pile d’entreprise. Le prompt ne se cache plus sur une page web quelconque. Il arrive emballé dans le connecteur que l’équipe a installé volontairement.

La chaîne d’approvisionnement inclut désormais des consignes

Pendant longtemps, la chaîne d’approvisionnement numérique désignait des paquets, des dépendances, des scripts de build et des conteneurs. Les agents d’IA y ajoutent une catégorie plus étrange : des instructions fiables venues d’outils qui ne le sont qu’à moitié.

La revue 2026 de Stacklok sur l’écosystème MCP donne la mesure du problème. Dans un scan de 15.923 serveurs MCP et AI skills, l’entreprise a rapporté 757 cas de clés API divulguées par les sorties d’outils, et indiqué que 36% obtenaient une note insuffisante. Le signal est clair : l’hygiène des connecteurs progresse moins vite que leur adoption.

Le lien avec AI agent servers that are hackable and rarely checked est évident. Mais la nuance est essentielle : l’exposition d’un serveur relève du périmètre; les métadonnées empoisonnées relèvent de la frontière de confiance.

La gouvernance ennuyeuse devient décisive

IBM X-Force a averti en avril 2026 que l’adoption de l’IA agentique dépasse la gestion des vulnérabilités, au moment même où les agents gagnent en autonomie et en accès aux outils. La formule sonne très entreprise, mais la réponse pratique commence par des questions simples.

Avant de connecter un serveur MCP à de vrais identifiants, il faut demander : qui peut modifier la description, le schéma ou les exemples après validation? Le client affiche-t-il les changements de métadonnées avant l’exécution suivante? Les sorties de l’outil peuvent-elles contenir des secrets ou des consignes ressemblant à des commandes système? L’agent peut-il appeler cet outil sans nouvelle confirmation humaine? Les journaux montrent-ils quel outil a influencé une action sensible?

Il ne s’agit pas de céder à la panique. Il s’agit de traiter le texte du connecteur comme une influence exécutable. Si l’équipe relit le code mais ignore les descriptions d’outils, elle audite la serrure tout en négligeant le mot collé sur la clé.

Ce qu’une équipe peut faire cette semaine

Commencez par un inventaire MCP. Listez chaque connecteur, les identifiants qu’il peut atteindre, son responsable et sa capacité réelle : lire des données ou déclencher des actions. Séparez ensuite les outils en lecture seule de ceux qui peuvent envoyer des messages, modifier des enregistrements, créer des tickets, déplacer de l’argent ou toucher la production.

Pour les outils capables d’agir, la confirmation humaine doit intervenir au moment de la conséquence, pas seulement pendant l’installation. Un connecteur empoisonné devient dangereux lorsque l’approbation a lieu une fois et que l’autorité persiste indéfiniment.

Enfin, retenez une leçon des prompt injection defense programs : les instructions vont entrer en conflit. Système, utilisateur, page web, connecteur et sortie d’outil peuvent tous revendiquer l’autorité. L’architecture doit décider qui l’emporte avant qu’un agent ne se retrouve face à des identifiants de production.

La sécurité MCP n’est pas condamnée. Elle est simplement plus jeune que la confiance que nous lui accordons déjà. Les équipes les mieux placées ne seront pas celles qui accumulent les connecteurs, mais celles qui savent lequel peut chuchoter et lequel peut agir.

À lire aussi :

• Votre agent d’IA se laisse manipuler plus que vous
• Why 88% of enterprise AI agents fail before going live