En 2026, mener un test d’intrusion sans agent IA commence à ressembler à un train de retard. Mais il y a un piège que presque personne ne voit. Lors de BarbHack 2026, un orateur a construit un serveur MCP exposant une centaine d’outils de pentest Active Directory, l’a soumis à des milliers d’exécutions de benchmark, et en a tiré un constat sans appel : la manière dont presque tout le monde bâtit ses serveurs MCP casse en silence sur tout modèle qui n’est pas un gros modèle cloud.

C’est le troisième volet de notre couverture de BarbHack, et sans doute le plus contre-intuitif. Voici pourquoi, et ce que ça change pour quiconque outille l’IA, en sécurité comme ailleurs.

Le décor : l’IA au pentest, sans vendre la mèche au cloud

La thèse de départ est assumée : intégrer agents et modèles au pentest n’est plus « tricher », c’est un gain opérationnel que les clients attendent. Mais un pentest manipule des données extrêmement sensibles. Les envoyer à un modèle cloud (Claude, GPT et consorts) pose un problème de confidentialité majeur. D’où une contrainte qui commande tout le reste : faire tourner des modèles open source en local, on-prem, pour que rien ne fuite.

Retenez bien cette contrainte. C’est elle qui transforme un détail d’architecture en problème de fond.

Le MCP comme « wiki opérationnel »

L’outil au cœur de la démo est NetExec, un couteau suisse multi-protocoles de l’audit AD, puissant mais pensé pour des opérateurs humains : ses sorties sont lisibles, pas structurées. Confier ça brut à un modèle, c’est l’inviter à halluciner. La réponse : un serveur MCP qui s’intercale et joue le rôle de source de vérité à jour. Ses vertus :

  • normaliser les sorties dans un format structuré, ce qui réduit d’un coup les hallucinations et la consommation de tokens ;
  • orchestrer les enchaînements (l’agent propose l’étape suivante d’une chaîne d’attaque au lieu de la deviner) ;
  • faire respecter le périmètre : vérification du scope avant chaque action, blocage hors périmètre ;
  • servir de garde-fou avec des modes gradués, du « le modèle propose, l’humain exécute » au mode lecture seule, jusqu’aux actions plus intrusives. Du moindre privilège appliqué à l’agent.

Jusqu’ici, tout va bien. Sauf que.

Le piège : le MCP statique noie les modèles locaux

La façon habituelle de construire un MCP consiste à tout exposer d’emblée : la liste complète des outils et leur documentation, injectées dans le contexte du modèle dès le départ. Sur un gros modèle cloud, ça passe. Sur un modèle local, c’est la noyade.

Les chiffres présentés sont éloquents : un MCP couvrant seulement deux protocoles pèse déjà des dizaines de milliers de tokens ; en visant la cinquantaine de protocoles de l’outil, on sature la fenêtre de contexte. Résultat concret montré sur scène : un modèle local de 14 milliards de paramètres perd le fil, oublie des instructions, se désorganise, là où un modèle cloud réussit la même tâche.

Le MCP statique vous enferme dans un choix perdant : soit le cloud (et l’exfiltration de données que vous vouliez justement éviter), soit l’élagage de la documentation (et la perte de capacités). C’est là que « presque tout le monde construit son MCP de travers ».

La correction : le mode dynamique (Progressive Disclosure)

La solution tient en une idée : ne pas montrer cent outils d’un coup. On expose seulement quelques méta-outils : un pour suggérer les outils pertinents face à une tâche, un pour lister un catalogue, un pour décrire un outil précis, un pour l’exécuter. Le modèle découvre les capacités au fur et à mesure et construit sa stratégie étape par étape, au lieu d’avaler tout le manuel avant de commencer.

L’effet, mesuré sur le benchmark, est spectaculaire :

  • la consommation de tokens s’effondre (de l’ordre de 14 000 tokens contre 62 000 en statique sur un cas donné) ;
  • les taux de réussite bondissent : des modèles quasi inutilisables en statique approchent des scores très élevés en dynamique ;
  • même un gros modèle cloud y gagne, avec plusieurs fois moins de tokens pour un résultat équivalent ;
  • surtout, les petits modèles locaux redeviennent utilisables, ce qui débloque tout le scénario on-prem.

Enseignement qui fait réfléchir : la taille du modèle n’est pas déterminante. Bien outillé, un modèle de 8 milliards de paramètres peut dépasser un modèle bien plus gros sur des tâches ciblées. Le comportement compte autant que la puissance : certains modèles vont droit au but, d’autres s’arrêtent trop tôt ou tournent en rond. D’où le dernier principe martelé : benchmarkez les modèles que vous comptez réellement faire tourner.

Ce n’est pas qu’une astuce de conférence

Ce constat dépasse largement le pentest. Tout serveur MCP un peu fourni a ce problème, et l’écosystème l’a compris : le chargement des outils à la demande plutôt que tout en contexte (recherche d’outils, découverte progressive) devient un motif de conception de premier plan. Autrement dit, la leçon de ce talk sécurité est en train de devenir une bonne pratique générale de l’outillage IA.

Les principes retenus par l’orateur pour un bon MCP valent pour tout le monde : révéler l’information progressivement, ne jamais renvoyer une réponse vide (toujours proposer une alternative ou corriger l’erreur), démarrer par un MCP minimal pour valider ses outils, et connaître ses outils en profondeur.

Ce qu’on en retient chez Humanix

  • Si vous construisez des serveurs MCP, en sécurité ou ailleurs, ne déversez pas toute votre surface d’outils dans le contexte. Commencez petit, dévoilez progressivement, normalisez les sorties, et benchmarkez sur les modèles que vous utiliserez vraiment.
  • La confidentialité est l’enjeu clé. Un MCP bien conçu est précisément ce qui rend viable un audit assisté par IA en local, sans envoyer les données du client dans un cloud tiers.
  • L’IA au pentest n’est pas de la triche. Cadrée (périmètre vérifié, modes lecture seule, validation humaine), elle rend les audits plus fiables, reproductibles et accessibles, y compris pour les défenseurs.
  • C’est exactement le genre d’outillage qui nous intéresse : expertise offensive et IA, sans sacrifier la souveraineté de la donnée.

À retenir

  • Un MCP « statique » qui expose tous ses outils d’emblée sature la fenêtre de contexte des modèles locaux : seul un gros modèle cloud s’en sort, au prix de la confidentialité.
  • Le mode dynamique (Progressive Disclosure) n’expose que des méta-outils et laisse le modèle découvrir les capacités à la demande : tokens en chute libre, réussite en hausse, petits modèles locaux viables.
  • La taille du modèle n’est pas déterminante ; le bon outillage et le bon comportement, si.
  • Ce principe vaut pour tout serveur MCP, pas seulement en sécurité.

Note. Compte-rendu, à visée pédagogique, d’une conférence de BarbHack 2026 sur l’usage d’agents et de modèles d’IA pour les tests d’intrusion Active Directory. Les outils cités (NetExec, et l’approche dynamique « Falcon MCP » du projet Crossfallt) sont des projets publics. Troisième volet de notre couverture de l’événement. Envie d’un audit assisté par IA qui reste chez vous, ou d’en parler ? Contactez-nous.