Un projet posté sur Hacker News promet un « intercepteur MCP » capable de bloquer en temps réel les lectures de fichiers .env et les commandes dangereuses lancées par des agents IA. Son lien GitHub renvoie une erreur 404 et sa page tient surtout du site vitrine, doublé d'une place de marché de serveurs MCP. Le cas précis importe peu ; il illustre une catégorie d'outils en pleine floraison, les garde-fous placés entre un agent et les outils qu'il actionne.

Un agent branché sur vos secrets

Le Model Context Protocol (MCP), standard ouvert publié par Anthropic fin 2024, permet à un modèle de langage d'appeler des outils externes, des fichiers locaux aux bases de données en passant par le shell. Cette connexion fait l'utilité de l'agent et son exposition. Un agent capable de lire des fichiers peut lire un .env bourré de clés d'API ; un agent capable d'exécuter des commandes peut lancer un curl qui exfiltre ces clés vers un serveur distant.

Le vecteur le plus discuté reste l'injection de prompt indirecte, des instructions malveillantes cachées dans une page web, un PDF, un ticket ou un e-mail que l'agent lit au fil de sa tâche. Le modèle ne séparant pas les données des instructions, un texte piégé peut le détourner. Les serveurs MCP eux-mêmes ajoutent un risque, un serveur d'apparence anodine pouvant modifier ses outils après approbation, ce que la communauté appelle le « rug pull ». Le protocole n'impose pas de vérifier que l'outil exécuté correspond à celui qu'a validé l'utilisateur.

Un proxy entre l'agent et ses outils

La parade la plus répandue intercale un proxy, tantôt nommé passerelle, pare-feu d'agent ou intercepteur. Il inspecte chaque appel d'outil avant qu'il n'atteigne sa cible, applique une politique d'autorisation ou de refus, bloque les opérations à risque et journalise le tout pour audit. Plusieurs projets open source occupent déjà ce terrain, dont McpVanguard, Invariant Guardrails, agentgateway et pipelock, ce dernier filtrant le trafic sortant à la recherche d'exfiltration et d'injection.

Le premier commentaire sous le post résume la bonne pratique. Pour une vraie sécurité, on part d'un refus par défaut, pas d'une autorisation par défaut. Bloquer nommément la lecture de .env traite un symptôme ; restreindre l'agent à une liste courte d'actions permises traite la cause. Le même fil relève que le dépôt annoncé était introuvable et que l'interface ressemble à celle de nombreux projets générés par IA, deux raisons de ne pas confondre promesse marketing et outil éprouvé.

Ces garde-fous ne suppriment pas le risque. Un proxy ajoute de la latence, peut être contourné si l'agent emprunte un autre chemin comme un second serveur MCP non médié, et une politique trop laxiste ne protège de rien. Ils déplacent la question vers la gouvernance, celle des identités que portent les agents et des traces à conserver. Le risque d'agent contre agent et le besoin d'observabilité en production prolongent le même chantier.

Le dépôt GitHub annoncé par le projet de Hacker News restait inaccessible au 10 août 2026.