Chaque nouveau serveur MCP constitue une nouvelle frontière d'autorisation
L’intérêt de MCP est facile à comprendre : un modèle capable d’interagir avec des systèmes réels cesse d’être une simple démonstration pour devenir réellement utile. Grâce à un protocole unique, un agent de codage peut inspecter un dépôt, interroger une base de connaissances, ouvrir un ticket, récupérer des journaux ou préparer une pull request au sein d’un workflow réel. C’est là tout l’intérêt. MCP réduit les frictions d’intégration et uniformise l’utilisation des outils. Mais cette même simplicité transforme également une simple interface de chat en une passerelle vers de nombreux outils, de nombreuses identités et de nombreux modes de défaillance. Dès qu’un modèle est capable de faire plus que simplement décrire un plan, la question ne se pose plus ainsi : « L’agent est-il assez intelligent ? », mais : « Qui contrôle ce à quoi l’agent est autorisé à accéder ? »
Ce changement est important car l’accès aux outils n’est pas simplement une fonctionnalité de plus. Il s’agit d’une décision de confiance. Un assistant de codage connecté à un serveur Git opère déjà dans un environnement privilégié. Connectez-le à un système de tickets, à un référentiel de secrets, à un fournisseur d’intégration continue et à un outil de visualisation des journaux de production, et le champ d’impact s’élargit à chaque intégration. La même automatisation qui permet de gagner vingt minutes peut également divulguer un jeton, suivre une invite malveillante dissimulée dans un document, ou transformer une petite erreur en une erreur majeure et difficile à corriger. Le risque n’est pas théorique ; c’est le prix normal à payer pour donner à un logiciel la capacité d’agir en votre nom.
Une façon utile d’envisager le MCP est de considérer qu’il ne s’agit pas seulement d’une couche de transport. C’est une couche de délégation. Le protocole facilite la découverte des outils et la récupération du contexte, mais il facilite également l’agrégation des privilèges. Si une équipe considère que « nous utilisons le MCP » résout définitivement le problème de conception, elle ne se rendra compte des lacunes que la première fois qu’un agent demandera une portée d’écriture qu’il n’aurait jamais dû avoir en premier lieu.
Le MCP n’est pas seulement une couche de transport. C’est une couche de délégation.
Pourquoi le protocole en lui-même n’est pas le modèle de sécurité
Le MCP est utile précisément parce qu’il normalise la manière dont les agents découvrent les outils et le contexte. L’article technique d’Anthropic sur l’exécution de code avec le MCP explique l’avantage de cette norme : lorsqu’il existe de nombreux outils, charger toutes les définitions dans la ligne de commande gaspille du contexte, tandis qu’un harnais basé sur du code ne peut récupérer que ce qui est nécessaire. C’est du bon travail d’ingénierie. Mais une norme n’est pas une politique de sécurité. Un protocole peut rendre élégant un workflow risqué sans pour autant le rendre sûr.
Les problèmes de sécurité sont bien connus de toute équipe ayant déjà géré des identifiants de production. L’exfiltration de données, l’usurpation d’identité, l’injection dans la ligne de commande et l’attribution floue ne disparaissent pas lorsque l’interface est plus soignée. En réalité, ils deviennent souvent plus difficiles à détecter, car l’agent opère au sein d’un flux de travail qui semble productif. Un appel d’outil renvoyant un résumé soigné peut masquer le fait que l’agent a eu accès à plus de données que nécessaire. Une action bien formulée peut tout de même être une mauvaise action. Une modification d’apparence correcte peut tout de même être non autorisée.
L’injection de prompt devient plus dangereuse lorsque les agents peuvent accéder à plusieurs systèmes. Un commentaire de ticket piégé, un document malveillant ou une réponse truquée provenant d’un service connecté peut orienter un modèle vers des actions qu’un humain n’aurait jamais prévues. Si l’agent peut également réécrire dans des référentiels, des systèmes de déploiement ou des API externes, la surface d’attaque passe alors de « texte malveillant » à « texte malveillant associé à une action privilégiée ». C’est pourquoi le modèle de sécurité doit se situer au-dessus du protocole, et non à l’intérieur de celui-ci.
Les récents principes de sécurité « agentic » de GitHub expriment clairement ce que l’on sous-entend généralement : plus un produit devient « agentic », plus il a besoin d’un élément « human-in-the-loop ». Les directives Codex d’OpenAI expriment la même idée en langage opérationnel : maintenir l’agent à l’intérieur de limites techniques claires, laisser se dérouler les flux de travail à faible risque et rendre explicites les actions à haut risque. Il ne s’agit pas là de simples notes de bas de page prudentes. Ce sont les fondements mêmes d’une délégation responsable.
À quoi ressemblent de bonnes limites ?
Commencez par un accès en lecture seule par défaut
Si un serveur MCP sert principalement à récupérer du contexte, rendez-le en lecture seule. Si un workflow nécessite un accès en écriture, ne l’accordez pas simplement parce que c’est pratique ; accordez-le parce qu’un humain a évalué le risque et prévu un plan de secours. Un serveur en lecture seule peut résumer les journaux, inspecter les tickets et récupérer de la documentation. Un serveur avec capacité d’écriture peut modifier l’état. Ces deux rôles relèvent de niveaux de confiance différents.
Limitez l’identité à la tâche, et non à l’organisation
Un agent ne doit pas hériter d’un ensemble gigantesque de permissions « à l’image d’un humain » simplement parce qu’une personne en dispose. C’est l’identité la plus petite et la plus utile qui prévaut. Si la tâche consiste à mettre à jour un fichier README, l’agent n’a pas besoin d’un magasin de secrets. Si la tâche consiste à proposer une correction dans une branche, l’agent n’a pas besoin de droits de fusion de branches. Les recommandations de GitHub concernant l’attribution et le contexte autorisé sont importantes ici : l’utilisateur à l’origine de l’action et l’agent doivent tous deux être visibles dans la chaîne de responsabilité, et l’agent ne doit recueillir le contexte qu’auprès des utilisateurs autorisés à le fournir.
Placer les autorisations là où le risque est réel
L’approbation ne doit pas être une simple formalité. Elle doit intervenir là où une action devient coûteuse à annuler : avant toute sortie de réseau vers un hôte inconnu, avant la lecture ou l’écriture de secrets, avant la modification des paramètres de déploiement, avant la publication d’une pull request susceptible de déclencher un pipeline, avant l’appel d’une API de production, avant de transformer une suggestion en changement d’état. Si chaque action nécessite une validation, le système devient inutilisable. Si aucune action ne nécessite de validation, le système devient un risque. Tout l’art consiste à aligner les validations sur les étapes irréversibles ou à fort impact.
Consigner suffisamment d’informations pour reconstituer l’intention
Les journaux traditionnels vous indiquent qu’un processus a modifié un fichier. Les journaux natifs de l’agent devraient vous expliquer pourquoi l’agent a choisi ce fichier, quelles données d’entrée il a envoyées à l’outil, quelles étapes de validation ont été franchies et quel résultat il a renvoyé. L’article Codex d’OpenAI met en avant la télémétrie et les pistes d’audit précisément pour cette raison. Lorsque les choses tournent mal, les équipes de sécurité ont besoin de plus qu’une simple comparaison de fichiers. Elles ont besoin d’un récit qu’elles peuvent retracer. De bons journaux aident également les équipes à ajuster les limites : si l’agent continue de demander un chemin réseau qu’il n’utilise jamais, ou un serveur qui n’apporte aucune valeur ajoutée, la télémétrie vous indique où simplifier ou renforcer la politique.
L’intervention humaine n’est pas un frein
Certaines équipes continuent de décrire la validation comme un frein, comme si le produit idéal était celui qui ne donne jamais matière à réflexion. Ce point de vue est erroné. L’intérêt de la révision humaine n’est pas de punir l’utilisateur par un retard. Il s’agit d’empêcher la machine de prendre des décisions que seul un humain peut prendre de manière responsable. Un modèle peut comparer les résultats des outils plus rapidement que n’importe quelle personne. Il ne peut toutefois pas décider si un résultat a sa place dans une version candidate, si un chemin de données dépasse les limites d’une politique, ou si un compromis est acceptable pour l’entreprise.
C’est pourquoi les meilleurs workflows d’agents rendent le jugement visible. Un bon flux indique : voici le plan, voici les outils, voici les périmètres, voici le risque, voici les tests, voici ce qui a changé, et voici la personne qui valide la dernière étape. Un mauvais flux dit : « Faites-moi confiance, l’agent s’en est chargé. » Les équipes logicielles savent déjà comment cette histoire se termine. Chaque analyse d’incident qui s’ensuit est une leçon qui montre pourquoi une délégation invisible reste une délégation.
En pratique, cela implique de diviser le travail en trois niveaux. Vient d’abord l’exploration : l’agent recueille le contexte, affine le champ de recherche et élabore des options. Vient ensuite la vérification : l’agent effectue des tests, vérifie les hypothèses et produit des preuves. Vient ensuite l’autorisation : un humain décide si l’action proposée a sa place dans le système réel. Les deux premiers niveaux peuvent être rapides. Le troisième niveau doit rester mûrement réfléchi.
MCP facilite la composition d’outils, ce qui implique que la discipline de révision doit devenir plus stricte
La réflexion d’Anthropic sur l’exécution de code avec le MCP est utile car elle met en évidence les avantages de la composabilité. Lorsque les outils se multiplient, les appels directs à ces outils peuvent entraîner un gaspillage de contexte. L’exécution de code permet de ne charger que ce qui est nécessaire et de traiter le reste en dehors du modèle. Cela peut réduire l’utilisation de jetons et rendre les flux de travail plus efficaces. Mais ce même schéma renforce également la leçon fondamentale pour les équipes logicielles : plus le graphe d’outils est puissant, plus le cadre de contrôle qui l’entoure est important.
Un agent de codage capable d’enchaîner des serveurs entre eux écrit en réalité du code opérationnel à votre place. Ce code est peut-être éphémère, mais ses conséquences ne le sont pas. Si l’agent peut lire une transcription provenant d’un système et l’écrire dans un autre, votre politique de validation doit alors couvrir à la fois la source et la destination. Si l’agent peut effectuer une recherche dans plusieurs dépôts, puis ouvrir une pull request, le réviseur doit alors savoir si les résultats de la recherche étaient suffisants ou si l’agent a simplement choisi la voie la plus pratique. Si l’agent peut connecter un outil de documentation à un outil de déploiement, l’humain doit alors se demander si un transfert en apparence irréprochable ne franchit pas également une limite de politique.
C’est pourquoi « automatisé » ne devrait jamais signifier « non révisé ». Cela devrait signifier que le logiciel peut fonctionner dans un cadre limité tandis que l’humain reste le décideur ultime. Il n’y a rien d’anti-IA là-dedans. C’est ainsi que l’on rend l’IA suffisamment utile pour qu’on puisse lui faire confiance. L’équipe capable d’affirmer « l’agent peut proposer, mais seul un humain peut valider » est bien mieux placée que celle qui laisse la machine décider quand une modification est effective.
La politique que les équipes peuvent réellement mettre en œuvre
- Définissez des niveaux de confiance pour chaque serveur. Les systèmes en lecture seule, en écriture seule, à accès confidentiel et touchant à la production ne doivent pas partager les mêmes paramètres par défaut.
- Exigez l’approbation explicite du propriétaire pour tout nouveau serveur. Si une équipe souhaite connecter un nouveau serveur MCP, quelqu’un doit assumer le risque et valider le plan de restauration.
- Rendez les actions d’écriture visibles avant qu’elles n’aient lieu. Un humain doit pouvoir voir la modification prévue, la cible et les conséquences avant l’exécution.
- Privilégiez les identifiants à durée de vie limitée. Révoquez les jetons d’agent à la fin de la tâche et limitez la portée des identifiants à l’environnement le plus restreint possible.
- Enregistrez suffisamment de données télémétriques pour permettre l’audit des décisions. Les appels d’outils, les validations, les refus et les résultats doivent pouvoir être examinés a posteriori.
- Utilisez les tests comme des filtres, pas comme de simples éléments décoratifs. Si un agent propose du code, la question par défaut n’est pas « cela semble-t-il astucieux ? », mais « quelles preuves indiquent que c’est sûr ? ».
Ces règles ne sont pas propres à MCP. Ce sont les mêmes règles que les équipes auraient dû appliquer depuis des années pour les scripts privilégiés, les robots de déploiement et les comptes de service. MCP rend simplement cette lacune plus difficile à ignorer, car il concentre davantage de puissance dans une interface plus épurée. Les interfaces épurées sont une bonne chose. Mais elles font aussi qu’on oublie plus facilement l’étendue des pouvoirs que l’on vient de confier.
Un déploiement pratique doit commencer modestement. Placez un seul serveur dans un périmètre restreint. Testez d’abord un workflow en lecture seule. N’ajoutez une voie d’écriture que lorsque les processus de journalisation, de révision et de restauration fonctionnent déjà correctement. Si l’équipe ne peut pas expliquer ce qui se passe lorsque l’agent commet une erreur, elle n’est pas prête à le laisser agir. Cette règle semble simple, car elle l’est.
Le véritable atout du MCP réside dans la délégation contrôlée
Le principal argument en faveur du MCP n’est pas que les agents puissent remplacer les développeurs. C’est qu’ils peuvent devenir de meilleurs assistants lorsque le système environnant est conçu pour le contrôle. Un agent de codage capable de recueillir le contexte, de rédiger un correctif et de proposer des tests peut faire gagner un temps précieux. Un agent doté d’outils, mais capable d’accéder à une douzaine de systèmes sans garde-fous, peut faire gagner quelques minutes, mais aussi entraîner un projet de nettoyage de plusieurs mois. La différence ne réside pas dans l’intelligence, mais dans la gouvernance.
C’est pourquoi la présence humaine doit rester visible dans le flux de travail, et non pas être dissimulée dans un document de politique que personne ne lit. Ce sont les humains qui fixent l’objectif, définissent les limites, examinent les preuves et assument la responsabilité de la fusion. Les agents peuvent accélérer le travail. Ils ne doivent pas en hériter l’autorité. L’avenir des agents de codage ne réside pas dans l’autonomie totale. Il réside dans une délégation disciplinée, avec le commandement humain au centre.
Le MCP rend cet avenir réalisable. Il ne le rend pas facultatif.
Sources
- Journal des modifications GitHub : Validation de sécurité pour les agents de codage tiers
- GitHub : Comment les principes de sécurité « agentique » de GitHub rendent nos agents IA aussi sûrs que possible
- OpenAI : Exécuter Codex en toute sécurité chez OpenAI
- Anthropic : Exécution de code avec MCP : créer des agents plus efficaces
