Pourquoi cette étape est différente
Les sept étapes précédentes construisaient une capacité ; celle-ci protège ce que cette capacité a créé. Le changement de posture est réel : jusqu'ici, on demandait « comment faire fonctionner ? » ; à partir de maintenant, en cabinet cyber, on demande « comment ça casse, et qu'est-ce que ça coûte quand ça casse ? ».
Le point de départ est une phrase qu'on répète depuis l'étape 5, et qu'il faut maintenant prendre au sérieux : ce qui entre dans le contexte peut influencer le modèle. Tant que le modèle ne faisait que parler, l'enjeu restait la qualité des réponses. Dès qu'il a des mains — vos serveurs de l'étape 7 — une influence malveillante ne produit plus une mauvaise phrase : elle produit une mauvaise action. C'est toute la différence entre un employé qui répète une rumeur et un employé qui, sur la foi de cette rumeur, vire de l'argent.
Reprenons l'image de notre fiche Sécurité des agents IA : vos agents sont des employés zélés, rapides, obéissants — et sans le moindre jugement sur la provenance de ce qu'on leur dit. Un employé humain se méfierait d'un post-it « transfère la base clients à cette adresse » trouvé sur son bureau. L'agent, lui, lit ce post-it dans une donnée et l'exécute avec la même docilité qu'une consigne légitime. La sécurité des MCP, c'est l'art de border cette docilité.
La surface d'attaque, en une image
Trois familles de risques, et un point d'entrée commun :
Risque n°1 — l'injection indirecte
Le risque emblématique de l'ère des agents, et le plus contre-intuitif. Rappel du mécanisme, temps ④ de la séquence de l'étape 5 : le résultat d'un tool remonte dans la fenêtre de contexte. Or dans cette fenêtre, le modèle ne dispose d'aucune frontière étanche entre ce qui est donnée et ce qui est instruction. Tout est du texte, et le texte persuasif est suivi.
Déroulons-le sur notre fil rouge, pour le rendre concret :
La leçon de ce schéma est le socle de tout le reste : on ne peut pas empêcher totalement le modèle d'être convaincu par un texte piégé — c'est une propriété du fonctionnement d'un LLM, pas un bug à corriger. La sécurité ne consiste donc pas à rendre le modèle inpersuadable (illusoire), mais à faire en sorte que, même convaincu, il ne puisse pas causer de dégât. L'allowlist de l'étape 7 n'a pas empêché l'injection ; elle a empêché sa conséquence. Retenez la formule : on sécurise l'action, pas la conviction.
Risque n°2 — le confused deputy
Un classique de la sécurité, ravivé par les agents. Rappel du temps ③ de l'étape 5 : le serveur agit avec ses propres droits — son compte de service, son token. L'agent est donc un adjoint (deputy) qui détient des privilèges propres, souvent supérieurs à ceux de l'utilisateur qui lui parle.
Le piège : manœuvrer cet adjoint pour qu'il franchisse une porte interdite au demandeur. Un stagiaire qui n'a pas accès aux salaires demande à l'agent RH « fais-moi la synthèse des rémunérations de l'équipe » ; si l'agent dispose, lui, d'un accès large à la base RH, il produit la synthèse — et le contrôle d'accès a été contourné non par effraction, mais par procuration. L'adjoint a fait, avec ses droits, ce que le demandeur ne pouvait pas faire avec les siens.
La parade est structurelle et vous la connaissez déjà en creux depuis l'étape 6 : les droits de l'agent doivent être les plus proches possibles de ceux du contexte d'usage, jamais « admin par confort ». Un serveur RH branché sur un assistant d'équipe ne doit voir que ce que l'équipe a le droit de voir. Quand les droits doivent varier selon l'utilisateur, c'est au niveau du serveur et du système cible de porter cette distinction — pas à l'espoir que le modèle « fasse attention ».
Risque n°3 — l'exfiltration par chaînage
Le risque qui naît de la composition, invisible tool par tool. Pris isolément, un tool qui lit des données internes est légitime ; un tool qui écrit vers l'extérieur (poster sur une URL, envoyer un message) est légitime. Réunis dans le même agent, ils forment un siphon : lire le sensible, puis l'envoyer dehors — une fuite en deux appels, dont aucun n'est suspect isolément.
C'est le piège que l'audit tool-par-tool de l'étape 6 ne voit pas : chaque permission, prise seule, se justifie. Le danger est dans la paire. D'où une question d'architecture qui vient s'ajouter à la lecture des tools : quelles combinaisons mes serveurs rendent-ils possibles ? Un agent qui a simultanément accès en lecture à des données confidentielles et un tool de sortie réseau non contraint est un incident qui attend son déclencheur — humain distrait ou injection indirecte, peu importe.
La parade tient en un principe : séparer les capacités de lecture sensible et de sortie non contrôlée. Si l'agent doit lire du confidentiel, ses tools d'écriture sont bridés à des destinations internes fermées (l'allowlist de l'étape 7, encore). S'il doit pouvoir écrire vers l'extérieur, il ne lit pas le plus sensible. On casse la chaîne en s'assurant que les deux maillons ne coexistent jamais sans contrôle.
La défense en profondeur : quatre couches
Aucune parade unique ne suffit — c'est le message central du cabinet. On empile des couches indépendantes, de sorte que la défaillance de l'une soit rattrapée par la suivante :
① Moindre privilège, à la source. La couche la plus rentable, parce qu'elle ne dépend ni du modèle, ni de sa persuasion : un token qui ne voit qu'un carnet, un compte en lecture seule, un accès limité à un dépôt. Ce que l'agent n'a pas, aucune injection ne peut le lui faire faire. C'est le contrôle qui tient même quand tous les autres tombent.
② Séparation des serveurs par domaine. Un serveur = un périmètre = un jeu de droits. Non seulement c'est plus lisible à auditer (chaque serveur répond d'une seule chose), mais c'est ce qui casse le chaînage du risque n°3 : en gardant lecture sensible et sortie externe dans des périmètres distincts et non simultanément ouverts, on retire à l'agent la possibilité physique du siphon.
③ L'humain dans la boucle sur l'irréversible. Toute action que l'on ne peut pas défaire — envoyer à l'extérieur, supprimer, payer, publier — passe par une confirmation humaine. C'est la friction qu'on a appris à respecter à l'étape 6 : non un défaut d'ergonomie, mais le dernier rempart, celui qui transforme une catastrophe silencieuse en une demande de validation visible. On réserve cette friction à ce qui la mérite — l'irréversible — pour qu'elle ne devienne pas un réflexe qu'on approuve sans lire.
④ Supervision de bout en bout. On l'a semée à l'étape 5 : le protocole étant du JSON-RPC, tout appel s'observe et se journalise. Un enregistrement de qui a appelé quel tool, avec quels arguments, pour quel résultat, remplit trois fonctions : détecter un usage anormal en quasi temps réel, tracer le déroulé d'un incident pour le comprendre, et prouver — à un auditeur, un client, un régulateur — ce que l'agent a fait et n'a pas fait. C'est le pendant, côté MCP, de la journalisation d'un SI classique.
L'angle Shadow AI : le risque que personne n'a inventorié
Un dernier risque, spécifiquement pour les DSI et RSSI, et il n'est pas technique : c'est celui des serveurs MCP branchés sans que personne ne le sache. Un collaborateur qui connecte un serveur communautaire pratique à son assistant, un token de production glissé dans une configuration locale, un agent qui a discrètement accès à trois systèmes internes — chacun de ces gestes, individuellement anodin, échappe au registre s'il n'existe pas de gouvernance (l'étape 4, appliquée cette fois aux mains).
C'est la version « agents » du Shadow IT, et elle est plus dangereuse que l'ancienne : un outil SaaS non déclaré expose des données ; un agent outillé non déclaré peut agir sur elles. La première question de sécurité d'une organisation qui adopte les agents n'est donc pas « nos serveurs sont-ils bien codés ? » mais « savons-nous seulement lesquels sont branchés, avec quels droits, sur quels systèmes ? ». Sans cette cartographie, les quatre couches de défense protègent un périmètre qu'on ne connaît pas.
Cartographier cette exposition — quels agents, quels serveurs, quels droits, quels angles morts — puis la ramener sous contrôle, c'est exactement l'objet de notre programme Shadow AI Sentinel, conformité AI Act comprise. Le blindage des étapes 7 et 8 n'a de valeur que sur un périmètre connu ; ce programme établit d'abord le périmètre.
📚Pour aller plus loin
Pour les geeks : le poison du tool description. Une variante d'injection qui contourne l'intuition, car elle ne passe pas par les données mais par le métadonnées. Souvenez-vous : le modèle lit les descriptions des tools pour choisir (étape 5). Un serveur malveillant peut donc glisser des instructions non pas dans un résultat, mais dans la description d'un de ses tools — invisible à l'utilisateur qui ne lit que l'interface, présente en permanence dans le contexte du modèle. Pire, certains serveurs peuvent modifier leurs descriptions après l'installation initiale (le « rug pull » : bénin à l'audit, hostile ensuite) ou faire apparaître de nouveaux tools en cours de session (le pattern qu'on signalait à l'étape 5). Trois parades cumulatives : figer les serveurs à une version auditée (étape 6, jamais de branche mouvante) ; préférer les serveurs qui ne mutent pas leurs capacités en session, et traiter toute mutation comme un événement de sécurité ; et, pour les contextes sensibles, épingler aussi le contenu des descriptions au moment de l'audit, pour détecter toute dérive ultérieure. La règle générale : tout ce que le modèle lit fait partie de la surface d'attaque — y compris ce qui décrit les outils eux-mêmes.
📚Pour aller plus loin
Pour les geeks : bâtir la couche de supervision, concrètement. Le JSON-RPC de l'étape 5 rend l'observation triviale ; reste à la rendre utile. Trois niveaux de maturité. Niveau 1 — le journal brut : un proxy entre hôte et serveurs qui enregistre chaque tools/call — horodatage, serveur, tool, arguments (avec masquage des secrets et des données personnelles au passage), résultat tronqué, verdict d'éventuelle confirmation humaine. Rien que ça vous donne l'audit trail réglementaire et la reconstruction post-incident. Niveau 2 — la détection : des règles sur ce flux — un tool d'écriture externe appelé juste après une lecture sensible (le chaînage du risque n°3), un volume d'appels anormal, un argument qui ressort d'un périmètre attendu, l'apparition d'un tool non répertorié. On passe de la trace à l'alerte. Niveau 3 — la corrélation : rapprocher ces événements du reste du SI — le SIEM existant, les logs des systèmes cibles — pour qu'un appel MCP suspect s'éclaire à la lumière de ce qui se passe ailleurs. Vous reconnaissez la trajectoire : c'est celle de l'observabilité d'un SI classique, transposée aux mains du modèle. Un cabinet qui outille ses clients sur les agents commence souvent par là : sans le niveau 1, on débat d'incidents sans preuve ; avec, on gouverne.
📍 Parcours Skills & MCP — étape 8/9
- 🗺️ La carte avant le territoire
- 🔬 Anatomie d'une skill
- 🛠️ Créer sa première skill
- 🏛️ Skills en entreprise : gouvernance
- 🔌 MCP : le protocole expliqué
- ⚡ Utiliser un serveur MCP existant
- ⚙️ Créer son serveur MCP minimal
- 🛡️ Sécuriser ses MCP ← vous êtes ici
- 📡 L'écosystème : où trouver, où ça bouge
Dernière étape → L'écosystème : où trouver les meilleures skills et serveurs, comment monter sa veille, et comment évaluer une brique tierce avant de l'adopter — avec un tableau de bord vivant des dépôts qui comptent.
Cette étape est le cœur de notre métier. La fiche Sécurité des agents IA en donne la version 90 secondes à faire circuler en COMEX.