~5 minutes
Un adversaire compromet les outils dont dépend ton agent IA. Résultat : l’agent fait ce que l’attaquant veut, tout en croyant travailler normalement. Le Tool Poisoning, c’est le supply chain attack version IA.
Partie de la série OWASP MCP Top 10
Description du risque
Je considère le Tool Poisoning comme l’une des attaques les plus vicieuses du monde MCP.
Le Tool Poisoning se produit quand un adversaire compromet les outils, plugins ou leurs sorties dont dépend un agent IA. En injectant du contenu malveillant, trompeur ou biaisé dans ces outils, l’attaquant manipule le comportement du modèle sans jamais toucher au modèle lui-même.
L’agent croit faire son travail normalement. Il utilise ses outils habituels mais ces outils lui mentent. C’est la supply chain attack version IA.
Vecteurs d’attaque
On distingue quatre vecteurs principaux pour l’empoisonnement d’outils :
1. Empoisonnement de la base de connaissances
L’attaquant injecte des données malveillantes dans une source consultée par un outil MCP (base vectorielle, wiki interne). L’outil retourne des informations falsifiées au modèle.
2. Plugin MCP malveillant
L’attaquant publie un serveur MCP tiers avec un nom trompeur (typosquatting). Le développeur l’installe sans méfiance. Ce vecteur croise avec MCP04 - Supply Chain Attacks.
3. Manipulation des sorties d’outil légitime
L’attaquant intercepte ou modifie les résultats retournés par un outil via Man-in-the-Middle ou compromission du serveur. Les résultats contiennent des instructions cachées.
4. Injection dans les descriptions d’outils
L’attaquant modifie la description d’un outil MCP pour y inclure des instructions cachées destinées au LLM. Le modèle lit ces descriptions dans son contexte et les exécute.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Oui | Un outil empoisonné usurpe l’identité d’un outil légitime. Le modèle ne distingue pas un outil authentique d’un outil compromis. |
| Tampering (Falsification) | Oui (PRIMAIRE) | C’est le coeur du Tool Poisoning. Les données retournées par l’outil sont altérées. Le modèle raisonne sur des données falsifiées et propage l’erreur. |
| Repudiation (Répudiation) | Oui | Les actions effectuées par le modèle sur la base de données empoisonnées sont difficiles à attribuer. Qui est responsable ? L’agent, l’outil, le développeur ? |
| Information Disclosure (Divulgation d’informations) | Oui | Un outil empoisonné peut exfiltrer des données du contexte MCP : variables d’environnement, tokens, historique de conversation. |
| Denial of Service (Déni de service) | Modéré | Un outil corrompu peut retourner des résultats qui crashent le pipeline de l’agent. |
| Elevation of Privilege (Élévation de privilèges) | Oui | Un outil empoisonné peut instruire le modèle d’exécuter des actions privilégiées via d’autres outils MCP. |
Impact potentiel
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Élevé | Exfiltration de données sensibles via les outils compromis : secrets, tokens, code source propriétaire. L'outil empoisonné agit comme un canal d'exfiltration invisible. |
| Intégrité | Critique | Corruption de l'ensemble de la chaîne de raisonnement de l'agent. Des décisions critiques sont prises sur la base d'informations falsifiées. Dans un contexte multi-agents, la contamination se propage d'agent en agent. |
| Disponibilité | Modéré | Dégradation ou interruption des workflows automatisés. Un outil empoisonné qui retourne des données incohérentes paralyse l'agent et tous les processus dépendants. |
| Réputation | Élevé | Un agent IA qui produit des résultats incorrects ou malveillants à cause d'un outil empoisonné détruit la confiance des utilisateurs. Les incidents de type "l'IA a recommandé d'envoyer les mots de passe en clair" font le tour des réseaux sociaux en quelques heures. |
Recommandations de mitigation
1. Valider l’intégrité des outils MCP
If faut traiter chaque outil MCP comme une dépendance logicielle tierce : il ne faut faire confiance qu’à ce que vous pouvez vérifier. Concrètement, ça veut dire :
- Épingler les versions : N’installez jamais un outil MCP sans version fixée dans mon fichier de configuration (
mcp-server@1.2.3, jamaismcp-server@latest). Unlatestpeut silencieusement embarquer du code malveillant dans la prochaine release. - Vérifier les hash SHA-256 : pour chaque outil installé, vérifiez que le hash du package correspond au hash publié par l’auteur sur un canal authentifié (GitHub release, page officielle). Un seul bit différent = refus.
- Maintenir un registre interne : ne laissez pas les développeurs installer des outils MCP depuis n’importe quelle source. Imposez un registre privé qui n’accepte que les outils audités par l’équipe sécurité.
- Auditer le code source : avant d’approuver un outil dans le registre, lisez son code. Recherchez les appels réseau inattendus, les accès fichiers système, et surtout toute lecture des variables d’environnement.
- Isoler en sandbox : Exécutez les outils tiers dans des conteneurs sans accès réseau sortant. Si l’outil a besoin d’appeler une API externe, routez ça via un proxy qui loggue chaque requête.
2. Sanitiser les sorties des outils
Ne jamais faire confiance à ce qu’un outil retourne. Avant d’injecter un résultat dans le contexte du LLM, il faut le passer systématiquement par un filtre de sanitisation. Le principe est simple : chercher les patterns connus d’injection et les refuser ou les neutraliser.
Les patterns à détecter en priorité :
- Marqueurs de hijacking de prompt :
[SYSTEM],<|im_start|>,RÈGLE :,Ignore previous instructions,### New Instructions,<!-- SYSTEM. - URLs non whitelistées : toute URL dans une sortie d’outil qui ne correspond pas à la liste des domaines autorisés est suspecte.
- Instructions cachées dans les métadonnées : pour les documents (PDF, DOCX, HTML), nettoyer les métadonnées et le contenu caché (texte blanc sur blanc, balises HTML commentées, metadata XML) avant de passer le contenu au modèle.
- Sorties hors schéma : si un outil est censé retourner du JSON avec 3 champs, et qu’il en retourne 10, c’est un signal d’alerte. Valider les outputs contre un schéma strict.
Une sortie d’outil n’est pas du texte inerte, c’est du contenu qui va alimenter le raisonnement du LLM. Il faut la traiter avec la même méfiance qu’une entrée utilisateur.
3. Mesures organisationnelles
- Vérifier l’intégrité des outils MCP (signatures, hashes)
- Valider et sanitiser les sorties des outils avant injection dans le contexte
- Restreindre les sources d’outils autorisées (registre interne)
- Monitorer les comportements anormaux des outils (appels réseaux inattendus)
- Isoler les outils tiers dans des sandboxes
- Exiger une validation humaine pour toute action destructive
Quelques références pour aller plus loin
- OWASP MCP Top 10
- OWASP Top 10 LLM - Supply Chain Vulnerabilities
- OWASP Guide - Securely Using Third-Party MCP Servers
À retenir
