La promesse du MCP est élégante : offrir aux agents un moyen cohérent et auditable d’appeler des outils. Mais une nuance critique émerge : après qu’un utilisateur a autorisé un serveur, la surface de risque ne diminue pas ; elle se déplace. Une instruction cachée dans la réponse ou le contexte du serveur peut inciter le modèle à utiliser les outils qu’il est autorisé à appeler, désormais orientés vers la fuite de jetons, clés API ou données internes. Ce n’est pas un jailbreak au sens classique ; c’est une attaque de redirection post-approbation qui exploite une capacité légitime.

Le schéma est trompeusement simple. Un utilisateur approuve un serveur et un ensemble d’outils. Plus tard, le serveur renvoie une charge utile apparemment anodine incluant des instructions stratégiquement conçues. Le modèle, opérant dans les permissions accordées, obéit : il invoque une commande approuvée, lit un fichier ou une variable d’environnement, et transmet le résultat à un point de terminaison contrôlé par un attaquant. Comme chaque étape est techniquement conforme, les contrôles naïfs de politique passent et les filtres classiques de jailbreak se déclenchent rarement. La frontière de confiance a glissé du clic à l’ensemble de la boucle conversationnelle et d’invocation d’outils.

Pour les entreprises qui expérimentent des workflows agentiques, les implications sont opérationnelles, pas théoriques. Les contrôles de sécurité doivent régir comment, quand et avec quels paramètres les outils peuvent être utilisés — en particulier pour l’accès aux secrets, l’introspection système et les appels réseau externes. Les équipes conformité et audit doivent traiter les serveurs MCP comme des logiciels tiers : exiger des attestations, les isoler via des contrôles réseau et de namespace, faire tourner les identifiants éphémères, et imposer des journaux inviolables. Surtout, séparer l’autorité d’approuver un outil des circonstances qui permettent son usage sur une requête donnée.

Des mesures d’atténuation existent, mais elles doivent être précises. Appliquer des listes blanches de paramètres et refuser par défaut les jokers dangereux. Exiger des confirmations hors bande pour les opérations à haut risque (lecture de secrets, écriture de fichiers, publication vers des URL externes). Utiliser la signature cryptographique des réponses serveur et lier les approbations à des sessions courtes avec des périmètres restreints. Insérer un pare-feu contextuel pour supprimer ou isoler les instructions cherchant à utiliser des outils provenant de contenus non fiables. Enfin, surveiller les schémas coercitifs — exfiltration soudaine de données, contournement répété de schémas, ou modèles répétant des instructions pour divulguer des jetons — et révoquer automatiquement les sessions lorsqu’ils sont détectés.