Établissez une vision sécuritaire de chaque appel d’outil avant d’en ajouter d’autres. Le Model Context Protocol (MCP) est un protocole permettant à une application d’IA de découvrir et d’appeler des outils et des services de données externes. Un agent utilisant des outils est une application d’IA qui sélectionne un outil et lui fournit les arguments nécessaires pour accomplir une tâche. Cette connexion accroît l’utilité du système, mais elle transforme également les descriptions d’outils, les arguments d’appel, les identifiants et les données renvoyées en éléments critiques pour la sécurité de l’ensemble.
Pour une équipe de développement, la question n’est pas de savoir si un serveur MCP est distant ou local. Il s’agit plutôt de déterminer quelle identité, quelle autorisation et quelle traçabilité s’appliquent lorsque l’agent déclenche l’action d’un outil. Ce cours vous aidera à gérer cette frontière sans compromettre l’auditabilité ni le contrôle.
Chez Northbridge Health, l’agent CareOps peut utiliser JiraMCP, DriveMCP et un KubeAdminMCP local. Une instruction malveillante peut s’introduire via des métadonnées ressemblant à des informations d’outil ordinaires, influencer la sélection de l’agent et atteindre un service en amont en utilisant les identifiants du serveur MCP. Le résultat visible peut sembler être une simple récupération de fichier, alors que le chemin d’autorisation sous-jacent dépasse les droits d’accès de l’ingénieur à l’origine de la demande. Identifiez les points où la requête acquiert des droits et où la traçabilité disparaît :
Simulation — chaîne d’attaque :
Les métadonnées d’un outil comprennent la description, le schéma des paramètres et les annotations qui présentent l’outil à l’agent. Comme l’agent interprète ces éléments comme du contexte, un attaquant capable de les modifier peut tenter d’orienter les actions exécutées sur les serveurs connectés. Les résultats renvoyés par l’outil ainsi que le texte copié depuis un ticket présentent le même risque lorsqu’ils sont intégrés au contexte de l’agent.
Un serveur disposant de privilèges étendus (via ses identifiants de service) soulève un second problème. Le service en amont risque de percevoir l’identité du serveur plutôt que celle de l’ingénieur à l’origine de la demande. Il s’agit d’une vulnérabilité de type « confused deputy » (mandataire abusé) : un composant utilise ses propres droits pour traiter une requête qui aurait dû être restreinte aux droits de l’appelant. Le rapport d’incident illustre la manière dont ces faiblesses se conjuguent :
Simulation — note d’incident interne :