Comprendre les flux toxiques dans MCP et les risques cachés des systèmes natifs de l’IA

La plupart des discussions sur la sécurité de l’IA portent encore sur les prompts, les modèles et l’accès direct aux données. Ces aspects sont importants, mais dès qu’un agent IA peut appeler des outils, invoquer des API et agir sur plusieurs systèmes, le risque réel se déplace. Il ne s’agit plus seulement de ce que le modèle peut voir, mais de ce que l’agent peut faire lorsqu’il commence à combiner des outils de son propre chef.

C’est dans ce contexte que la notion de flux toxique prend toute son importance.

Un flux toxique est une séquence d’actions d’un agent qui fait passer un environnement d’instructions contrôlées par un attaquant à des données sensibles, puis à un point d’exfiltration. Aucune des étapes prises individuellement n’a besoin d’être malveillante. Chaque outil peut remplir exactement la fonction pour laquelle il a été conçu. Le danger réside dans le parcours de bout en bout créé lorsque des outils, des données et des instructions sont combinés sous le contrôle d’un agent IA.

Le Model Context Protocol (MCP) amplifie les deux aspects de cette équation. MCP normalise la façon dont les modèles et les agents se connectent aux outils, aux dépôts, aux services et aux sources de données. Pour les équipes de développement, c’est un avantage évident : elles disposent d’une méthode cohérente pour intégrer l’IA aux tâches quotidiennes, comme consulter des problèmes, mettre à jour des tickets, interroger des journaux, modifier du code et déclencher des scripts. Mais MCP offre également aux agents une boîte à outils flexible qui facilite la création involontaire de flux toxiques.

Dans une application déterministe traditionnelle, une entrée donnée suit un parcours défini dans le code. Les ingénieurs peuvent répertorier ces parcours, les tester et évaluer leurs propriétés de sécurité. Un agent basé sur MCP fonctionne autrement. Il peut choisir parmi de nombreux outils, dans différents ordres, en fonction des instructions en langage naturel, du contexte et des descriptions des outils. Personne ne rédige explicitement toutes les séquences possibles. Le modèle choisit le parcours au moment de l’exécution.

Ce changement crée une nouvelle catégorie d’exposition. Il ne suffit plus de se demander si un modèle a accès à des secrets ou à des dépôts privés. La question la plus pertinente est désormais la suivante : dans quelles conditions un agent décidera-t-il de faire transiter des données sensibles par une chaîne d’outils qui finira par les exposer à une partie non fiable ?

L’expression « flux toxique » désigne cette chaîne. Elle souligne que le risque est émergent. Il découle de la manière dont les données et le contrôle circulent entre de nombreux composants, plutôt que d’une simple erreur de configuration isolée. Dans les environnements MCP, comprendre et gouverner ces flux est essentiel, car les agents sont déjà connectés à des systèmes importants : environnements de développement, gestion du code source, processus de réponse aux incidents et services proches de la production.

Le trio fatal : comment une chaîne d’outils mène à une compromission

Malgré la variabilité du comportement des agents, le schéma qui sous-tend les flux toxiques est remarquablement constant. L’analyse d’incidents réels fait généralement ressortir trois éléments au cours d’une même exécution d’agent :

• des instructions influencées par un attaquant

• un accès à des données sensibles

• un moyen d’exfiltrer ces données

Lorsque ces trois conditions coexistent dans un même flux, l’environnement est exposé, même si chaque outil impliqué a été ajouté pour une raison légitime.

Les instructions non fiables sont souvent le point de départ. Dans un environnement MCP, elles ne se limitent pas à un prompt de chat. Un attaquant peut influencer le contenu d’un problème GitHub, d’un ticket d’assistance client, d’un message dans un canal de discussion surveillé ou de tout autre élément que l’agent est configuré pour lire. Si l’agent est chargé de trier, résumer ou traiter ces éléments, l’attaquant a trouvé un moyen d’influencer le raisonnement de l’agent.

Les données sensibles se trouvent généralement derrière des outils conçus pour améliorer la productivité. Il peut s’agir d’actions telles que lire le contenu d’un dépôt, récupérer des fichiers de configuration, interroger des outils de suivi des problèmes, extraire des journaux ou accéder à des dossiers internes. Les ingénieurs veulent que l’agent voie les mêmes informations qu’eux utiliseraient pour corriger un bug ou comprendre un problème en production. Par conséquent, la boîte à outils de l’agent inclut souvent un accès direct à des données de grande valeur.

Les points d’exfiltration sont des outils ou des canaux qui permettent de faire sortir des données de leur périmètre sécurisé. Parmi les exemples courants figurent les clients HTTP capables d’appeler n’importe quelle URL, les connecteurs qui écrivent dans des systèmes tiers, les intégrations qui envoient des e-mails ou des messages de chat et, dans certains cas, la réponse du modèle elle-même lorsque l’appelant n’est pas fiable. Ces fonctionnalités sont souvent ajoutées progressivement, à mesure que les équipes connectent leurs agents à davantage de processus.

Un scénario MCP simple illustre la façon dont le trio fatal se met en place. Prenons l’exemple d’un serveur MCP connecté à GitHub qui alimente un assistant de développement. L’assistant lit les problèmes d’un dépôt, utilise des outils MCP pour récupérer les fichiers et les détails de configuration pertinents, puis produit des résumés utiles aux responsables de la maintenance. Pour permettre les tests d’intégration, un outil HTTP capable d’envoyer des requêtes à n’importe quel point de terminaison est également mis à sa disposition.

Un attaquant ouvre un problème dans ce dépôt et y ajoute des instructions détaillées. Il affirme qu’il est impossible de diagnostiquer un bug complexe sans recueillir les fichiers d’environnement et les données de configuration de la base de code, puis les envoyer sous forme de charge utile JSON à une URL précise afin qu’un système d’analyse externe les examine. Du point de vue de l’agent, cette demande semble détaillée et raisonnable.

Si l’agent suit ces instructions, il lira le problème (instructions non fiables), parcourra le dépôt pour récupérer les fichiers de configuration et d’environnement (données sensibles), puis invoquera l’outil HTTP pour transmettre ces informations à l’URL de l’attaquant (point d’exfiltration). Aucun outil pris isolément ne présente de mauvaise configuration évidente. La compromission résulte de la manière dont ces outils sont combinés sous le contrôle du modèle.

Les contrôles traditionnels de sécurité de l’IA peinent à contrer ce schéma. Les filtres de prompts et les pare-feu pour LLM inspectent les prompts et les réponses individuellement. Ils ont peu de visibilité sur les appels d’outils intermédiaires et les transferts de données qui relient ces prompts aux systèmes externes. L’analyse de code vérifie l’implémentation des outils, pas la façon dont ils seront combinés à l’exécution. Les revues des accès confirment que chaque outil a une raison d’être légitime, mais évaluent rarement si un contenu non fiable peut déclencher une séquence reliant ces outils en un flux toxique.

Il en résulte une lacune. Les organisations peuvent croire avoir sécurisé leurs prompts, leurs modèles et leurs outils, alors que le risque réel réside dans les chaînes d’actions dynamiques orchestrées par MCP. Considérer cette lacune sous l’angle du « trio fatal » permet de se concentrer sur le véritable problème : dès lors que des instructions contrôlées par un attaquant, des données sensibles et une voie d’exfiltration sont accessibles au sein d’un même flux, l’environnement est exposé, quel que soit le soin apporté à l’introduction de chaque composant.

Pourquoi la plupart des approches de sécurité de l’IA passent à côté des flux toxiques

Une fois le trio fatal compris, il apparaît clairement que de nombreuses approches actuelles de la sécurité de l’IA sont conçues pour une autre catégorie de problèmes. Elles se concentrent sur ce que le modèle voit et dit, plutôt que sur ce que l’agent fait dans les systèmes interconnectés.

Les contrôles des prompts, les filtres de contenu et les pare-feu pour LLM figurent généralement parmi les premiers moyens de défense déployés par les organisations. Ces systèmes inspectent les entrées et les sorties à la recherche de violations des politiques ou de termes sensibles. Ils peuvent limiter les abus manifestes et empêcher certaines catégories d’injection de prompt. Cependant, les flux toxiques se déroulent souvent en une série d’étapes qui semblent parfaitement légitimes. Dans l’exemple GitHub, l’assistant semble répondre à une demande détaillée de débogage. Rien dans la réponse finale ne révèle nécessairement que des secrets ont été exfiltrés par des appels d’outils intermédiaires.

Les outils traditionnels de sécurité des applications sont eux aussi axés sur les artefacts statiques et les parcours déterministes. L’analyse statique, l’analyse de la composition logicielle et l’analyse de l’infrastructure en tant que code sont adaptés aux environnements où le code et la configuration définissent chaque action autorisée. Ils peuvent vérifier que les outils MCP sont implémentés de manière sûre, que les dépendances sont à jour et que les jetons d’accès sont correctement gérés. En revanche, ils ne peuvent pas facilement anticiper la décision d’un agent de combiner ces outils de façon inattendue en fonction d’une entrée en langage naturel.

La journalisation et la supervision à l’exécution apportent une couche supplémentaire, mais elles aussi sont limitées dans ce contexte. Les ingénieurs peuvent collecter des traces des appels d’outils, des réponses et des erreurs, puis analyser des incidents particuliers. La difficulté est combinatoire : le nombre de flux possibles augmente en flèche à mesure que les connexions entre outils et systèmes via MCP se multiplient. Compter sur une revue manuelle pour détecter les schémas dangereux devient impraticable, surtout lorsque le comportement de l’agent peut changer à la suite de légères modifications de l’entrée ou du contexte.

Même les offres de sécurité plus récentes, conçues spécifiquement pour l’IA, se concentrent souvent sur des vérifications locales. Elles peuvent imposer des contraintes sur les paramètres d’un outil précis ou limiter l’accès d’un agent à certains secrets. Ces contrôles restent centrés sur les composants. En général, ils n’analysent pas les parcours complets qui commencent par un contenu non fiable et se terminent par la sortie de données hors du périmètre de confiance.

Il en résulte une lacune dans la couverture : les investissements en sécurité des modèles, en validation des prompts et en sécurité des outils individuels ne couvrent pas automatiquement l’espace d’interaction créé par MCP. L’environnement peut sembler bien maîtrisé lorsque chaque élément est considéré séparément, tout en laissant des flux toxiques se produire lorsque ces éléments sont combinés.

Pour remédier à cette situation, les équipes de sécurité doivent poser une autre question : l’environnement permet-il un parcours par lequel des instructions influencées par un attaquant peuvent entraîner l’envoi de données sensibles vers un point d’exfiltration ? Toxic Flow Analysis est conçu pour apporter une réponse structurée.

Présentation de Toxic Flow Analysis

Toxic Flow Analysis (TFA) offre une approche graphique des systèmes intégrant l’IA. Au lieu d’examiner les prompts ou les outils isolément, cette solution cartographie les connexions entre les agents, les serveurs MCP, les outils et les systèmes sous-jacents. Elle recherche ensuite les parcours susceptibles de réunir les éléments du trio fatal.

Tout commence par une représentation de l’environnement. Dans un contexte MCP, celle-ci comprend les serveurs MCP, leurs manifestes d’outils, les configurations des modèles et des agents, ainsi que les systèmes externes auxquels ces outils accèdent, comme les systèmes de gestion du code source, les plateformes de gestion des tickets, les systèmes de messagerie et les points de terminaison HTTP génériques. À partir de ces éléments, TFA construit un graphe des flux qui indique quels composants peuvent appeler quels outils, à quelles données ces outils peuvent accéder et où leurs sorties peuvent être envoyées.

Ce graphe est ensuite enrichi d’attributs pertinents pour la sécurité. Les nœuds et les arêtes sont annotés pour indiquer si des parties non fiables peuvent influencer les instructions à l’origine du flux, si les données traitées sont sensibles et si l’étape franchit une frontière de confiance. Ces annotations permettent de distinguer les flux internes habituels de ceux qui relient des surfaces contrôlées par un attaquant à des ressources de grande valeur, puis à des destinations externes.

Une fois le graphe annoté, TFA peut rechercher systématiquement les parcours réunissant les trois conditions du trio fatal. La solution identifie les séquences dans lesquelles des instructions non fiables peuvent atteindre un agent, où cet agent peut accéder à des outils exposant des données sensibles et où le même contexte comprend un point d’exfiltration. Ces flux toxiques constituent des vecteurs d’attaque réalistes pour un adversaire déterminé s’appuyant sur le langage naturel et les intégrations existantes, plutôt que sur des logiciels malveillants personnalisés.

La détection ne suffit pas. Pour être utile sur le plan opérationnel, TFA doit également permettre de hiérarchiser les risques et d’agir. Tous les flux potentiels ne présentent pas le même niveau de risque. Un parcours susceptible de divulguer des secrets de production vers un point de terminaison externe quelconque n’a pas le même impact qu’un parcours pouvant exposer des métadonnées non sensibles à un système interne contrôlé. Toxic Flow Analysis peut attribuer des scores d’impact en fonction de facteurs tels que la classification des données, la facilité d’exploitation, l’étendue des accès et la nature du point d’exfiltration, afin d’aider les équipes à déterminer où concentrer leurs efforts.

Cette approche tenant compte des graphes permet aux équipes de sécurité et de plateforme de répondre à des questions autrement difficiles à traiter. Quels serveurs MCP exposent des combinaisons d’outils susceptibles de créer des flux toxiques ? Quels agents sont à la fois connectés à des sources d’instructions non fiables et à des points d’exfiltration ? Comment l’ajout d’un nouvel outil, comme un client HTTP générique, modifie-t-il l’ensemble des flux possibles ?

Il est important de noter que l’analyse des flux toxiques (TFA) n’est pas une opération ponctuelle. À mesure que les agents évoluent, que les configurations MCP changent et que de nouveaux outils sont ajoutés, le graphe des flux doit être mis à jour et réévalué. Lorsqu’elle est considérée comme une capacité continue, l’analyse des flux toxiques devient le fondement d’une approche plus mature des risques liés aux applications natives de l’IA : une approche qui tient compte du comportement de l’environnement dans son ensemble, et pas seulement de la configuration de ses composants individuels.

Cela nous amène à l’étape suivante. Une fois qu’une organisation peut détecter et évaluer les flux toxiques, elle doit décider comment empêcher leur exécution dans la pratique. La visibilité sans contrôle ne suffit pas dans un environnement où les agents sont déjà habilités à agir.

Pourquoi les environnements MCP ont besoin de garde-fous, et pas seulement de visibilité

L’analyse des flux toxiques révèle où se situent les risques liés aux applications natives de l’IA, mais les informations seules ne suffisent pas à prévenir les incidents. Si un système peut identifier qu’une combinaison spécifique d’agent, de serveur MCP et d’outil est susceptible de créer un flux toxique, il lui faut tout de même un mécanisme pour intervenir au moment où ce flux est sur le point d’être exécuté.

MCP renforce l’urgence de cette exigence, car il connecte des systèmes hétérogènes au moyen d’un protocole unique. Par l’intermédiaire de MCP, un agent peut accéder au contrôle de version, aux pipelines de compilation, aux systèmes de supervision, aux plateformes de collaboration et aux services internes. Ces intégrations sont administrées par différentes équipes et différents fournisseurs. En général, aucun point central dans ces systèmes sous-jacents ne permet d’appliquer une politique unique pour régir tous les flux qui les concernent.

Le moyen le plus pratique d’appliquer une politique se trouve au sein même de la couche IA : au niveau des serveurs MCP, des agents qu’ils exposent et de la logique d’orchestration qui détermine quels outils sont disponibles et comment ils peuvent être utilisés. Dans ce contexte, les garde-fous sont des mécanismes d’application concrets capables d’examiner des séquences d’actions prévues ou en cours, de les comparer aux résultats de l’analyse des flux toxiques et aux politiques, puis d’autoriser, de modifier ou de bloquer ces séquences.

Pour fonctionner efficacement, les garde-fous ont besoin de contexte. Ils doivent disposer de plus que de la requête actuelle ou d’un seul appel d’outil. Ils doivent savoir quel agent est en cours d’exécution, quels outils sont disponibles dans l’environnement, comment ces outils sont configurés et quelles données et quels systèmes externes ils touchent. C’est là que l’AI-BOM et l’analyse MCP jouent un rôle essentiel.

L’AI-BOM fournit une description structurée de la pile IA : modèles, jeux de données, frameworks, serveurs MCP et intégrations clés. L’analyse MCP fournit un inventaire réel de ce qui est effectivement déployé sur les terminaux des développeurs et des opérateurs : les serveurs MCP installés, les outils qu’ils exposent et leur configuration. Ensemble, ces capacités permettent à une couche d’orchestration de faire correspondre les résultats de l’analyse TFA aux contextes d’exécution concrets.

Grâce à ces informations, les garde-fous peuvent être appliqués à des points précis. Si l’analyse des flux toxiques révèle qu’un agent et une configuration MCP spécifiques permettraient à des tickets GitHub non fiables de faire parvenir des secrets à un point de terminaison HTTP externe, une politique peut être déployée pour empêcher cette combinaison précise, tout en laissant les autres flux intacts. On évite ainsi les restrictions générales et brutales qui nuisent à l’utilité des agents.

Sans une telle application intégrée des politiques, les organisations risquent de reproduire un schéma bien connu : des tableaux de bord riches, des résultats pertinents, mais peu d’impact sur les pratiques quotidiennes. Les garde-fous bouclent la boucle entre analyse et action, afin que la prise de conscience des flux toxiques se traduise par des limites concrètes à ce que les agents sont autorisés à faire.

De l’analyse au contrôle : les garde-fous en pratique et l’intérêt d’une gouvernance unifiée

Pour transformer les résultats de l’analyse des flux toxiques en garde-fous MCP efficaces, il faut des politiques, de l’orchestration et une intégration aux outils existants.

Les politiques constituent le point de départ. Les équipes de sécurité, de plateforme et de développement s’accordent sur les limites à ne pas franchir. Par exemple, elles peuvent interdire les flux dans lesquels des agents exposés à des tickets externes peuvent accéder aux secrets de production et envoyer des données vers des URL quelconques, ou exiger des contrôles supplémentaires pour les flux impliquant des données réglementées. L’analyse des flux toxiques fournit les éléments nécessaires pour définir et justifier ces politiques.

Une couche d’orchestration évalue ensuite le comportement des agents au regard de ces politiques. Lorsqu’un agent s’apprête, via MCP, à exécuter une séquence d’appels d’outils qui aboutirait à un flux toxique, le garde-fou peut intervenir. Il peut bloquer la séquence, demander une autorisation supplémentaire ou acheminer la requête selon un schéma plus sûr. L’application des règles se fait au plus près du point de décision de l’agent, où le contexte complet du flux est visible.

Pour déployer cette approche à grande échelle, les organisations ont besoin d’une couche de gouvernance qui coordonne l’ensemble de leur écosystème. L’AI-BOM et l’analyse MCP fournissent à cette couche des informations exactes et à jour sur les environnements MCP gérés de manière centralisée comme sur ceux installés localement. La couche de gouvernance peut ensuite appliquer des garde-fous cohérents, que l’agent s’exécute sur une plateforme partagée ou sur la machine d’un développeur.

La remédiation locale reste essentielle. L’objectif n’est pas de remplacer les systèmes CI/CD, les assistants d’IDE, les plateformes de gestion des tickets ou les outils de gouvernance des données, mais de veiller à ce qu’ils s’appuient sur une compréhension commune des risques. Lorsque l’analyse TFA détecte un nouveau flux toxique, la plateforme d’orchestration peut ouvrir des tickets, proposer des modifications de configuration ou mettre à jour les règles d’accès dans les systèmes déjà utilisés par les équipes. La couche de gouvernance devient le point de coordination ; les outils existants restent les moteurs d’exécution des changements.

À mesure que l’adoption progresse, ces capacités permettent aux organisations de passer de contrôles expérimentaux à un programme cohérent de sécurité de l’IA. Elles peuvent commencer par la visibilité offerte par l’analyse des flux toxiques, ajouter des garde-fous ciblés pour les flux les plus risqués, puis les étendre au fil du temps. Tout au long de ce processus, l’AI-BOM et l’analyse MCP garantissent que les politiques restent alignées sur l’état réel de l’environnement.

MCP est appelé à devenir un élément central des systèmes natifs de l’IA. L’analyse des flux toxiques, associée à des garde-fous reposant sur des inventaires exacts et une gouvernance unifiée, permet d’en tirer parti tout en maîtrisant les risques les plus lourds de conséquences. À mesure que ces capacités évoluent, la voie à suivre se dessine clairement : les organisations ont besoin de moyens pratiques pour mettre ce type d’analyse en œuvre.

Envie d’en savoir plus ? Découvrez comment Snyk renforce la protection des systèmes natifs de l’IA et essayez Snyk MCP Scan dès aujourd’hui.