Empoisonnement d'outils MCP & rug-pulls

Un serveur MCP tiers ou un skill installé est une dépendance de chaîne d’approvisionnement. Deux modes d’échec se distinguent :

• Empoisonnement — le serveur était malveillant dès le premier jour. Son manifeste semblait bénin ; le comportement dangereux était dans l’implémentation de l’outil, pas dans les portées déclarées.
• Rug-pull — vous lui faisiez confiance, puis il a changé. Un nouvel outil est apparu que l’opérateur du serveur a ajouté discrètement, ou une entrée de registre communautaire a été piratée et mise à jour pour appeler à la maison.

Les deux menaces partagent une cause racine : après que vous avez dit « je fais confiance à ce serveur », vos agents continuent d’appeler ses outils — même les nouveaux ou les modifiés — sans aucune revue supplémentaire.

​

1. Comment l’empoisonnement d’outils MCP atteint vos agents

Chaque tools/call que votre agent émet voyage à travers l’ensemble d’outils déclaré du serveur MCP. Un serveur empoisonné ou rug-pullé exploite cette confiance de quelques manières :

​

2. Les défenses d’OrcaRouter

​

2.1 Chaque tools/call est évalué par le firewall avant de s’exécuter

Les serveurs MCP se connectent à vos agents via la passerelle MCP du Firewall à /api/v1/firewall/mcp. La passerelle ne transfère pas un appel d’outil tant que le moteur firewall ne l’a pas évalué contre votre politique. Cela signifie que votre liste blanche est la source de vérité — pas le manifeste d’outils du serveur. Si un rug-pull ajoute shell.exec et que votre politique n’a pas de règle le permettant, le verdict est deny et l’appel ne quitte jamais la passerelle. Le modèle reçoit une erreur d’outil (firewall deny: …) et peut réagir ; l’outil ajouté par l’attaquant est mort à l’arrivée. Verdicts que le moteur peut retourner :

​

2.2 Les capacités auto-détectées sont mises en quarantaine jusqu’à revue

Quand un agent auto-installe une capacité — ou qu’un rug-pull ajoute de nouveaux outils qui n’étaient pas présents quand vous avez enregistré le serveur — le Firewall auto-détecte la nouvelle capacité hors du chemin à chaud, synthétise un manifeste, le scanne et attribue une bande de risque et un mode d’application. Crucialement, les capacités auto-détectées sont toujours mises en quarantaine peu importe le résultat du scan : elles sont maintenues en pending_approval jusqu’à ce qu’un humain les révise. C’est ainsi que les rug-pulls sont contenus. Un opérateur ne peut pas ajouter discrètement un nouvel outil et avoir vos agents qui commencent à l’utiliser — ces appels sont mis en attente jusqu’à ce que vous inspectiez et approuviez la nouvelle capacité.

​

2.3 Le scanning de skills attribue une bande de risque et un mode d’application

Chaque capacité installable — que vous l’ayez enregistrée ou que le Firewall l’ait auto-détectée — est passée dans le scanner de skills. Le scanner exécute des passes déterministes sur le manifeste et les portées déclarées :

• prompt_injection — texte de manifeste qui tente de détourner les instructions.
• tool_creep — outils que le manifeste utilise mais ne déclare jamais.
• network_egress — hôtes HTTP(S) en dehors des portées réseau approuvées.
• fs_write_unsafe — accès au système de fichiers en mode écriture en dehors de /tmp.

Les résultats se cumulent en une bande de risque (low / medium / high / critical) et un mode d’application : Un skill de bande high est automatiquement mis en quarantaine ; critical est bloqué. Un seul résultat error (ex. tool_creep pour un shell.exec non déclaré) est suffisant pour bloquer un skill même quand son score numérique semble bas. Le mode ne s’allège jamais — approuver un skill ne détend jamais un block établi par un scan récent.

​

2.4 Les identifiants sont stockés chiffrés

Les secrets d’authentification du serveur sont chiffrés au repos avec une clé de secrets d’espace de travail et injectés par la passerelle au moment du dispatch. Ils n’atteignent jamais le modèle, l’agent ou les arguments de l’appel. Un serveur compromis ne peut pas exfiltrer vos clés API en lisant son propre auth_json.

​

3. Que faire après un rug-pull suspecté

1. Désactivez le serveur immédiatement — un serveur désactivé est supprimé du registre d’exécution et ses identifiants ne sont jamais déchiffrés. Utilisez PUT /api/workspace/firewall/mcp_servers avec "enabled": false.
2. Re-sondez pour faire apparaître les changements — POST /api/workspace/firewall/mcp_servers/:id/probe exécute tools/list et retourne tous les nouveaux outils apparus depuis votre dernier sondage.
3. Rescannez l’enregistrement du skill — POST /api/workspace/firewall/skills/:id/rescan ré-exécute le scanner contre le manifeste mis à jour. Si le verdict se dégrade en flagged ou blocked, le Firewall émet un événement dans votre flux.
4. Examinez la file d’attente pending_approval — tous les appels mis en attente depuis le rug-pull sont dans la file. Inspectez-les et refusez-les plutôt que d’approuver en masse.
5. Auditez le journal d’appels — vérifiez la piste d’événements du Firewall pour les appels qui sont passés avant que vous ne détectiez le changement.

​

4. Associer le scanning de skills avec les règles firewall

Le scanning de skills et les règles firewall sont complémentaires et se composent :

• Une règle avec tool_name_glob: community.* définie sur pending_approval garantit que vous examinez chaque appel d’un serveur source communautaire, peu importe la bande de risque.
• Un skill mis en quarantaine remplace une règle allow — même si votre politique permet http.fetch largement, un skill en quarantaine qui le possède met quand même l’appel en attente.
• Utilisez skill_name_glob dans une règle pour scoper des politiques plus strictes aux serveurs non fiables sans affecter vos intégrations de première partie.

Voir Firewall : Serveurs MCP pour le modèle complet de passerelle et Firewall : Skills pour la référence du scanner et du mode d’application.

​

5. Menaces associées

• Appels d’outils dangereux — règles pour bloquer les actions d’outils destructrices ou irréversibles peu importe la source.
• Exfiltration de données — règles d’egress qui restreignent où les appels d’outils peuvent envoyer des données.
• Modèle de menace — la surface d’attaque complète qu’OrcaRouter est conçu à défendre.