Chaque identifiant MCP que votre équipe a distribué était probablement une bonne décision le jour où vous l'avez attribué. Personne ne l'a vérifié depuis. C'est cette faille que les attaquants exploitent, pas un défaut du protocole lui-même.
Le Model Context Protocol (MCP) d'Anthropic est entré en production fin 2024. Il s'est ensuite répandu rapidement. Depuis, des milliers de serveurs MCP ont été créés. Microsoft, Google et OpenAI l'ont adopté. La maintenance du protocole a été confiée à la Linux Foundation. Aujourd'hui, MCP est considéré comme une infrastructure critique. Il se situe entre un agent IA et les outils et données avec lesquels cet agent interagit. Pour la majorité des équipes, il a été mis en place comme n'importe quel autre standard d'intégration : on l'installe et on fait confiance aux paramètres par défaut.
Ce qui s'est révélé vrai en 2026, c'est que le problème ne se situait pas dans l'infrastructure. Le problème se situe dans les permissions sous-jacentes à cette infrastructure.
C'est crucial, car cela change la façon dont on pense résoudre les problèmes de sécurité MCP. Un correctif résout un problème précis sur un serveur particulier. Le changement de permission exige de poser une question plus compliquée : pourquoi ce serveur en particulier avait-il besoin d'un accès dont il n'a jamais eu besoin ? Selon l'enquête SANS 2026 sur les menaces liées à l'identité, qui a interrogé plus de 500 experts en sécurité, 76 % des entreprises ont constaté une augmentation des identités non humaines. 74 % des entreprises utilisent des systèmes IA qui s'appuient sur des identifiants permanents pour fonctionner de façon autonome. Cette même enquête a révélé qu'aucune des mesures de protection, telles que les processus d'approbation, le sandboxing ou la journalisation, n'est utilisée par plus de 40 % des entreprises.
Au-delà des divulgations individuelles, la même cause profonde revient sans cesse. En mai 2025, un attaquant a utilisé l'injection de prompt contre le serveur MCP GitHub pour extraire des données de dépôts privés, non pas parce que le serveur avait un bug au sens classique, mais parce que le jeton d'accès personnel qui le sous-tendait avait une portée bien plus large que la tâche ne l'exigeait. Quelques jours plus tard, une faille logique dans une intégration Asana MCP a permis un accès inter-tenants, car la frontière d'isolation entre clients n'avait jamais été appliquée au niveau des permissions.
Les chercheurs en sécurité regroupent désormais cela sous quelques schémas reconnaissables : l'empoisonnement d'outil (tool poisoning), où la propre description d'un outil de serveur porte des instructions cachées, et le problème du deputy confus, où un agent hérite de plus de confiance que la tâche qui lui est confiée n'en exige.
Ce qu'une refonte des permissions vous demande vraiment de vérifier
La solution qui revient sans cesse n'est pas un meilleur scanner, mais le cloisonnement de l'accès. Le blog d'ingénierie de GitHub, qui traite du développement de serveurs MCP distants sécurisés, propose ce qui suit : chaque instance doit disposer de ses secrets propres à la tâche spécifique, toutes les requêtes doivent être limitées à l'utilisateur effectuant une action, et l'autorisation doit se faire action par action plutôt que d'être supposée après l'authentification de l'utilisateur. Les jetons fixes et permanents devraient être remplacés par des identifiants dynamiques et temporaires générés à la volée.
Cette solution est graduée et fonctionne jusqu'ici. Chez Webflow, nous traitons les intégrations MCP de la même manière que les autres composants tiers ayant accès aux données clients.
Le périmètre ne change pas. Que quelqu'un le vérifie, si.
La même autorisation du jour zéro, deux habitudes, une seule des deux est jamais revue.
Les deux voies partent de la même autorisation, limitée à la tâche qui l'a demandée. La revue planifiée pose les mêmes questions que cet article soulève déjà : que peut atteindre l'identifiant maintenant, par rapport à ce pour quoi il était limité ; l'autorisation est-elle accordée par site ou par workspace plutôt que tout ou rien ; l'agent obtient-il son propre identifiant plutôt que d'hériter d'un identifiant plus large ; existe-t-il une journalisation qui attribue une responsabilité ; un changement passe-t-il toujours par une revue avant la production. Un identifiant à qui personne ne pose ces questions ne devient pas plus sûr avec le temps, il conserve simplement l'accès qu'il avait au départ, ce qui est exactement la configuration derrière à la fois le jeton MCP GitHub devenu plus large que la tâche ne l'exigeait et l'intégration Asana qui n'a jamais appliqué sa frontière de tenant.
Chaque identifiant que l'équipe donne à un agent IA était probablement une bonne idée au moment où il a été attribué. La question difficile n'est pas de savoir si cet accès était une bonne idée à ce moment-là. C'est de savoir s'il l'est toujours, et la plupart des équipes n'ont pas pris l'habitude de se la poser.
Quelques points à considérer lors de l'intégration de tout MCP :
Que peut atteindre cet identifiant maintenant, par rapport à la portée pour laquelle il était prévu. La portée de l'accès a tendance à dériver silencieusement. Aucune revue ne sera planifiée jusqu'à ce que quelque chose casse.
L'autorisation est-elle accordée par site, par dépôt ou par workspace, ou est-ce tout ou rien ? Méfiez-vous de toute intégration qui n'offre qu'un accès au niveau de l'organisation. Si une intégration ne vous donne pas de contrôle sur la portée au moment de la connexion, c'est le constat, pas une note de bas de page.
L'agent IA hérite-t-il des identifiants existants de la personne, ou crée-t-il un identifiant entièrement nouveau qui contourne ces permissions ? C'est cette seconde option qui permet à un jeton d'accès personnel GitHub d'avoir plus d'accès aux dépôts que l'utilisateur qui l'a autorisé.
Existe-t-il une journalisation qui attribue une responsabilité aux actions de l'agent, comme elle le ferait pour un humain ? Si les activités de l'agent sont invisibles ou impossibles à attribuer, la réponse à incident repart de zéro.
Les changements de l'agent passent-ils directement en production, ou traversent-ils d'abord un processus vérifiable comme un brouillon, une branche, une file d'approbation ?Il s'agit simplement d'appliquer à une nouvelle classe d'entités la discipline de sécurité que l'équipe applique déjà aux contrôles d'accès humains.
L'identité vient avant l'accès
Avant de pouvoir parler de ce qu'un agent est autorisé à faire, il faut répondre à une question plus difficile : qu'est-ce qu'un agent, du point de vue de l'identité ? Pour la majeure partie de l'industrie, la réponse honnête aujourd'hui est « le jeton OAuth d'un humain déguisé en trench-coat ». L'agent n'a pas sa propre identité. Il hérite de la portée, du rayon de l'explosion, et souvent de l'identifiant littéral de la personne qui l'a lancé.
Cela devient un problème dès que les agents cessent d'être éphémères. La plupart des agents aujourd'hui vivent quelques minutes à quelques heures : une tâche démarre, l'agent tourne, il meurt. Mais cela change. Nous nous dirigeons vers des agents qui tournent pendant des semaines ou des mois, et une chose qui vit aussi longtemps a besoin de sa propre identité, pas d'une identité emprentée, avec des permissions qui se durcissent, et non se relâchent, à mesure que la durée de vie augmente.
Pensez à la différence entre un prestataire que vous engagez pour un après-midi et un travailleur temporaire intégré à vos systèmes pour un trimestre. Vous ne donneriez pas un badge permanent au prestataire de l'après-midi, et vous ne devriez pas donner à l'agent du trimestre le même accès qu'à un script de cinq minutes.
OAuth n'a pas été conçu pour cela, et ce n'est pas seulement une fonctionnalité manquante, c'est une inadéquation structurelle, et au fond, un échec d'UX : un modèle de consentement conçu pour un humain dans la boucle, appliqué à un processus qui n'en a aucun. Tout son modèle suppose qu'un humain est assis devant une boîte de dialogue de portée et fait un choix informé, et nous savons tous comment cela se passe : personne ne lit la liste des portées, tout le monde clique sur autoriser. Cette hypothèse déjà fragile s'effondre complètement lorsque personne ne lit quoi que ce soit.
La spécification de base n'a aucune notion de « ce client est un agent » ou « cette autorisation doit durer six mois », seulement une expiration fixée après coup par le serveur. Quelques brouillons de l'IETF commencent à esquisser une correction, liant la durée de vie d'un jeton au cycle de vie réel d'une tâche, et étiquetant les agents avec des identités stables distinctes de l'humain qui les a invoqués, mais ce ne sont que des propositions à un stade précoce, pas des normes déployées.
Nous n'avons pas de réponse nette sur l'endroit où placer la limite entre « tâche éphémère, accès plutôt large » et « agent de longue durée, verrouillé strictement ». L'équipe de sécurité de Webflow travaille activement sur cette question, et nous comparons nos observations avec nos pairs du secteur plutôt que de prétendre avoir résolu le problème. Mais le cadrage lui-même compte : traitez la durée de vie d'un agent comme une donnée de premier ordre de votre modèle de permissions, et non comme une réflexion après coup.
Les permissions ne sont pas une case à cocher lors de l'attribution
Une refonte des permissions, une mise à jour du protocole et un modèle d'identité représentent trois niveaux distincts du même problème. Pour que chaque niveau reste efficace, les deux autres doivent l'être aussi. Si vous créez un identifiant avec la bonne portée le premier jour, mais que personne ne vérifie jamais qu'il reste valide, vos efforts ont été gaspillés. De même, si vous développez un nouveau protocole qui distingue enfin un agent de l'humain derrière lui, mais que toutes les intégrations continuent d'offrir par défaut un accès permanent tout ou rien, vous n'avez pas accompli grand-chose. Aucune de ces approches ne répond à la question plus profonde qui les sous-tend toutes deux : ce qu'un agent est autorisé à faire devrait dépendre de la durée pendant laquelle il existera. À l'heure actuelle, presque aucun composant de la pile technologique ne sait même poser une telle question, encore moins y répondre. Les équipes qui réussiront ne seront pas celles qui auront développé un scanner plus efficace. Ce seront plutôt celles qui auront arrêté de considérer la portée, l'identité et la durée de vie comme trois évaluations distinctes réalisées une fois par instance d'agent, et qui auront commencé à les traiter comme un seul paramètre à réévaluer chaque fois que la fonction ou l'existence de l'agent change.
