Imaginez un agent qui traite les tickets de votre support. Il a le droit de lire les tickets, d’interroger la base client, et de déclencher un remboursement en dessous d’un certain seuil. Toutes ces permissions sont légitimes, documentées, validées.
Un jour, un ticket contient une phrase glissée dans un fichier joint : une instruction adressée non pas à votre agent de support, mais à l’agent qui va le lire.
L’agent l’exécute. Il utilise ses droits — les vrais, ceux qu’on lui a donnés — pour faire quelque chose qu’aucun humain n’aurait validé.
Regardez maintenant ce que voient vos systèmes. L’authentification est valide. L’autorisation est correcte. Le journal enregistre un appel légitime, par une identité légitime, dans les limites définies. Aucune alarme ne se déclenche, parce qu’aucune règle n’a été violée.
C’est le problème du délégué confus — le confused deputy — et l’essor des connecteurs d’outils, MCP compris, le rend beaucoup plus concret qu’il y a deux ans.
Ce qui le rend difficile, c’est que la question de sécurité change de nature. Elle n’est plus « cet appel était-il autorisé ? » mais « cet agent devait-il émettre cet appel, dans ce contexte, à la demande de cette source ? » Une gateway qui ne vérifie que la première question laissera passer toute la seconde catégorie.
Trois choses aident, et elles se testent :
- Séparer les identités — l’utilisateur, l’agent et l’outil ne doivent pas se confondre dans les traces ni dans les droits.
- Vérifier l’accès direct aux outils — un outil ou un serveur MCP joignable sans passer par la passerelle annule tout le reste.
- Exiger une approbation humaine sur les actions destructrices ou financières — et vérifier que cette approbation ne peut pas être rejouée.
Aucun de ces trois points ne se démontre par une configuration. Ils se démontrent en tentant l’attaque et en montrant ce qui se passe.