Le protocole MCP a rendu une chose presque triviale : donner des outils à un agent. Un serveur MCP expose une API, une base, un service interne, et l’agent sait l’appeler. C’est précisément ce qui en fait un sujet de sécurité. Chaque serveur MCP est une porte vers un système. Multipliez les serveurs, et vous multipliez la surface d’attaque, sauf si l’architecture est pensée pour l’éviter.

En environnement régulé, la bonne question n’est donc pas « combien d’outils peut-on brancher ? », mais « comment en brancher beaucoup sans élargir ce qu’un attaquant, ou un agent qui se trompe, peut atteindre ? ». Voici les principes d’une architecture d’agents IA sécurisée quand les MCP servers se comptent par dizaines.

Un serveur MCP est une porte, pas un simple connecteur

Il est tentant de voir un serveur MCP comme un adaptateur technique de plus. C’est une erreur de cadrage. Du point de vue de la sécurité, un serveur MCP est un chemin d’accès : il donne à l’agent, et donc à quiconque peut influencer l’agent, la capacité d’agir sur le système derrière. Une injection de prompt bien menée ne compromet pas l’agent en tant que tel, elle se sert de ses outils.

La conséquence est directe : on ne raisonne pas sur la confiance qu’on accorde à l’agent, mais sur ce que chaque outil rend possible dans le pire des cas. Un agent est aussi dangereux que l’outil le plus permissif auquel il a accès.

Lecture seule par défaut

Le premier principe est une position par défaut : lecture seule. Un agent qui investigue, corrèle et recommande n’a besoin, dans l’immense majorité des cas, que de lire. Les serveurs MCP exposent donc en priorité des capacités de lecture, et toute capacité d’écriture ou d’action est l’exception, justifiée cas par cas.

Concrètement, cela veut dire que le droit n’est pas porté par l’agent mais par l’outil : un serveur MCP « lecture » et un serveur MCP « action » sont deux surfaces distinctes, avec des permissions distinctes. On n’ajoute une action que lorsqu’elle est à la fois nécessaire, réversible et validée, exactement la frontière que décrit notre cadre d’évaluation. Tout le reste reste en lecture, ce qui réduit massivement ce qui peut mal tourner.

Séparer les domaines

Le deuxième principe est le cloisonnement. Un agent connecté à quinze systèmes ne doit pas disposer d’un accès unifié à ces quinze systèmes. Chaque serveur MCP couvre un domaine (supervision, tickets, identité, réseau) avec ses propres droits, sa propre identité technique, son propre périmètre. La compromission ou le dysfonctionnement d’un serveur ne doit pas se propager aux autres.

Cette séparation vaut aussi entre environnements. Isoler les domaines suppose souvent de répartir les accès sur plusieurs comptes ou plusieurs frontières réseau, ce qui introduit ses propres pièges d’autorisation, que nous avons détaillés à propos de l’accès cross-account à un runtime d’agent. Le principe reste le même : le rayon d’action d’un incident doit rester borné au domaine concerné.

La surface d’attaque se compte en permissions, pas en serveurs

Ajouter un serveur MCP n’élargit pas la surface d’attaque en soi. Ce qui l’élargit, ce sont les permissions que ce serveur porte. Dix serveurs strictement en lecture, cloisonnés, tracés, présentent moins de risque qu’un seul serveur capable d’écrire partout.

C’est pourquoi le vrai travail se joue au niveau des rôles et des droits, pas au niveau du nombre d’intégrations. Chaque identité technique doit respecter le moindre privilège, être bornée par des garde-fous d’autorisation, et rester auditable. Nous avons documenté ce travail dans le contexte AWS, avec les patterns concrets pour déployer un runtime d’agent sous une permissions boundary IAM : c’est là, dans le détail des rôles et des politiques, que la sécurité d’une architecture MCP se gagne ou se perd.

Tracer et révoquer

Un dernier principe conditionne tous les autres : chaque appel d’outil doit être tracé, et chaque accès révocable en un geste. La traçabilité permet de comprendre ce qu’un agent a fait, de rejouer un incident, et de prouver qu’un domaine n’a pas été touché. La révocabilité permet de couper un serveur MCP compromis ou défaillant sans démonter tout l’édifice. Dans les faits, cela passe par des identités techniques à durée de vie courte et des jetons d’accès dédiés à chaque serveur, qu’on peut invalider isolément sans toucher au reste.

Ensemble, ces deux propriétés transforment une architecture MCP de boîte noire inquiétante en système gouvernable : on sait qui a accès à quoi, ce qui a été fait, et comment tout arrêter.

Ce qu’il faut retenir

Exposer de nombreux MCP servers à un agent n’est pas un problème de quantité, mais de conception. Lecture seule par défaut, séparation stricte des domaines, permissions au moindre privilège, traçabilité et révocation : ces cinq principes permettent de brancher beaucoup d’outils tout en gardant une surface d’attaque bornée et connue.

C’est cette rigueur qui rend une architecture d’agents acceptable pour une DSI en environnement régulé, et qui s’inscrit dans notre méthodologie d’industrialisation : un agent puissant n’a de valeur que si l’organisation garde la maîtrise de ce qu’il peut atteindre.

Vous connectez des agents IA à des systèmes sensibles et voulez cadrer leur surface d’accès ? Parlons-en.