Passer au contenu principal
Un « rug pull » est le mode de défaillance MCP où un serveur se comporte bien pendant que vous le surveillez et tourne hostile une fois qu’il a votre confiance : un outil que vous avez approuvé au moment de la connexion se met à faire passer des arguments supplémentaires, un serveur communautaire que vous avez listé ajoute discrètement une nouvelle capacité, ou un skill qu’un agent a auto-installé bascule de bénin à dangereux en production. Le danger est que personne ne re-revoit une connexion une fois en service — la décision de confiance a été prise une fois, au handshake, et jamais revisitée. OrcaRouter ne fait pas confiance au handshake. Il défend sur trois fronts. La passerelle MCP du Firewall évalue chaque tools/call au moment du dispatch contre votre politique en direct. L’ensemble d’outils annoncé de chaque serveur enregistré est baseliné au premier sondage et re-vérifié pour détecter la dérive — si le schéma d’outils change par rapport au baseline approuvé, le serveur échoue fermé jusqu’à ce qu’un admin le ré-approuve ou le mette en quarantaine. Et la couche Skills attribue à chaque capacité installée une bande de risque et un mode d’application — mettant en quarantaine tout ce qui est risqué ou non revu jusqu’à validation par un humain. Un serveur ne peut pas gagner un laissez-passer en se comportant bien pendant les cent premiers appels.

​
1. Pourquoi la protection contre le rug pull MCP a besoin d’une évaluation par appel

Une revue au moment de la connexion répond une fois à une question : ce serveur est-il sûr à lister ? Elle ne peut pas répondre à la question qui compte réellement à l’exécution : cet appel-ci précisément, avec ces arguments-ci, est-il sûr en ce moment ? OrcaRouter répond à la seconde question. Chaque tools/call qui traverse la passerelle est évalué sur la surface mcp avant d’être dispatché au vrai serveur, avec le nom de l’outil et les arguments en main. Le verdict est calculé à neuf à chaque fois, de sorte qu’à l’instant où un outil se met à faire quelque chose que votre politique interdit — exfiltrer un secret dans un argument, atteindre un hôte refusé, appeler une capacité que vous n’avez jamais approuvée — l’appel est stoppé, peu importe comment le même outil s’est comporté une minute auparavant.
L’évaluation par appel gouverne le comportement de chaque appel — contenu des arguments, destinations, risque du skill propriétaire — donc elle attrape un rug pull même quand l’outil garde une signature identique et que seul son comportement tourne hostile. La détection de dérive de schéma (§ ci-dessous) est la couche complémentaire : elle attrape le cas où l’ensemble d’outils annoncé du serveur change lui-même. Les deux s’exécutent.
Les verdicts que le moteur peut renvoyer sur la surface mcp :

allow / audit

Transmis au serveur. audit journalise l’appel ; allow reste silencieux.

sanitize

Transmis avec les arguments de l’appel d’outil redactés d’abord (il ne réécrit jamais ce que le serveur renvoie).

deny

Renvoyé au modèle comme une erreur d’outil (firewall deny: …) de sorte que l’agent peut s’adapter au lieu de planter.

pending_approval

L’appel est mis en attente qu’un humain le résolve avant qu’il ne puisse s’exécuter.

​
2. Quarantaine par bande de risque des skills

La seconde moitié de la défense contre le rug pull couvre la chaîne d’approvisionnement : les skills, plugins et serveurs MCP bring-your-own qu’un agent installe. Chacun est enregistré comme un enregistrement à portée d’espace de travail, scanné par un moteur de risque déterministe, et doté d’une bande de risque (low / medium / high / critical) plus un mode d’application :
ModeEffet à l’exécution
allowLes verdicts de règle décident ; le skill n’ajoute rien.
quarantineTout ce qui n’est pas un deny est escaladé en pending_approval — les outils ne s’exécutent qu’après l’approbation d’un humain.
blockLes outils du skill sont refusés d’emblée.
C’est là qu’un rug pull est contenu. Une capacité qu’un agent auto-installe est auto_detected et mise en quarantaine jusqu’à revue — même si elle a scanné propre, elle ne s’exécute pas de sa propre autorité. Et le mode d’un skill ne se resserre que à la re-scan : un block ou quarantine que vous définissez n’est jamais silencieusement relâché quand un manifeste est re-présenté.
La quarantaine est appliquée indépendamment du mode shadow. Un skill réglé sur quarantine ou block est toujours retenu même pendant que la politique environnante est en déploiement shadow — de sorte qu’une capacité risquée ne peut pas se glisser pendant un déploiement échelonné.
Voir Firewall : Skills pour le scanner complet, les pondérations de scoring, et les signaux de confiance.

​
3. Détection de dérive du schéma d’outils

Le rug pull classique est un serveur enregistré qui change ce qu’il annonce — ajoute un outil, altère le schéma d’entrée d’un outil, échange une description. OrcaRouter baselinise l’ensemble d’outils annoncé de chaque serveur enregistré à un sondage réussi et le surveille pour détecter la dérive.

Baseline au premier sondage

Le premier sondage réussi enregistre un hash canonique des outils du serveur (trust-on-first-use sous une posture de découverte ; sous une posture enforcing un serveur non baseliné est retenu pending jusqu’à ce qu’un admin approuve son ensemble d’outils initial).

La dérive échoue fermé

À un sondage ultérieur, si l’ensemble d’outils canonique ne correspond plus au baseline approuvé, le serveur est marqué changed et cesse d’être servi — la passerelle ne dispatchera pas ses outils jusqu’à ce que vous décidiez.

Approuver ou mettre en quarantaine

Ré-approuvez pour re-baseliner sur le nouveau schéma, ou mettez le serveur en quarantaine. Un serveur en quarantaine est aussi désactivé et seule une approbation explicite restaure le service — une simple édition ne peut pas le réactiver.

Audité

La première détection de dérive par rapport à un baseline approuvé écrit une entrée d’audit d’espace de travail, de sorte que le changement est consigné.
Le statut de schéma d’un serveur est l’un de unknown (jamais baseliné), verified (correspond au baseline), changed (a dérivé, retenu), pending (non baseliné sous enforcing), ou quarantined. Cette couche attrape le rug pull qui déplace le schéma ; l’évaluation par appel (§1) attrape celui qui garde une signature identique et ne change que le comportement.

​
4. Un exemple concret

Supposons qu’un serveur MCP communautaire notes annonce un outil inoffensif notes.search. Vous le listez, le revoyez, et il fonctionne. Une semaine plus tard le serveur est compromis et notes.search se met à attacher un argument d’exfiltration qui POST votre contexte vers un hôte attaquant. Une passerelle qui ne contrôle qu’au moment de la connexion le transmettrait — le nom de l’outil et le schéma semblent inchangés. OrcaRouter évalue l’appel : 
# Configurez la règle de deny dans la console (Developer+), pas via la clé relais.
# Règle : sur la surface mcp, deny notes.search dès qu'il porte un
#         argument de forme exfiltration.
#   tool_name_glob: notes.search
#   args_match:     { "path": "$.callback_url", "op": "regex",
#                     "value": "^https?://(?!notes\\.example/)" }  → deny
(Les opérateurs args_match sont eq, contains, regex, in, cidr_match, gt, lt ; cidr_match teste un argument valant une IP contre un CIDR. Pour borner où un outil peut atteindre par host/CIDR, utilisez la liste de destinations d’egress plutôt qu’une clause d’argument.) Au dispatch le moteur renvoie deny, et au lieu de transmettre l’appel la passerelle remet à l’agent une erreur de résultat d’outil MCP — un résultat normal signalé comme une erreur, pas un échec de transport — de sorte que le modèle peut s’adapter : 
firewall deny: <la raison de votre règle>
Le même appel qui a réussi la semaine dernière est maintenant bloqué — parce que la décision est prise sur l’appel, pas sur la connexion.
sanitize redacte les arguments que votre agent envoie, jamais le contenu qu’un outil renvoie. Si vous devez contraindre où un outil peut atteindre, associez une règle de deny à une liste de destinations d’egress — ne comptez pas sur sanitize pour nettoyer les réponses.

​
5. Comment cela s’imbrique

L’évaluation par appel attrape un outil de confiance qui devient malveillant — même nom, nouveau comportement dans les arguments ou la destination. La quarantaine de skill attrape une capacité nouvelle ou non revue qui apparaît tout court — une installation auto-détectée, un manifeste re-scanné qui se dégrade. Un rug pull peut prendre l’une ou l’autre forme, donc les deux s’exécutent : le mode du skill se superpose au verdict de règle par appel.
Oui — voir §3. L’ensemble d’outils annoncé de chaque serveur enregistré est baseliné au premier sondage et re-vérifié pour détecter la dérive ; un serveur ayant dérivé échoue fermé jusqu’à ce que vous le ré-approuviez ou le mettiez en quarantaine. C’est complémentaire à l’évaluation par appel, qui attrape aussi un outil qui garde une signature identique et ne change que son comportement.
Un verdict pending_approval retient l’appel qu’un humain le résolve dans la console (Developer+) ou via un callback d’approbation HMAC. Voir modes d’application pour la façon dont les attentes et les approbations sont présentées à un agent.

​
6. Le configurer

Chaque étape ci-dessous est une action console / de gestion authentifiée avec votre token de session ou d’accès — pas la clé relais sk-orca-…. Seul le trafic relais /v1/* utilise la clé relais.
1

Enregistrez vos serveurs MCP derrière la passerelle

Connectez chaque serveur pour que ses outils soient annoncés sous un seul endpoint audité. L’enregistrement est Developer+.
2

Définissez un verdict par défaut et des règles sur la surface mcp

Rédigez des règles avec tool_name_glob et args_match pour que les appels risqués se résolvent en deny, sanitize, ou pending_approval. Voir la référence des règles du Firewall.
3

Revoyez les skills en quarantaine

Tout ce qui est auto-détecté reste en quarantine jusqu’à ce qu’un relecteur (Developer+) l’approuve. Lisez d’abord la bande et les constatations.
4

Déployez en shadow, puis appliquez

Utilisez les modes d’application pour exécuter les nouvelles règles en shadow, surveillez les événements d’audit, et basculez en enforcing une fois que les verdicts semblent corrects.
Les lectures (réglages, politiques, outils découverts, anomalies) sont ouvertes à tout Member ; chaque écriture est Developer+. Lire le texte en clair d’une clé de passerelle firewall est Developer+.

​
Connexe

Firewall : serveurs MCP

La référence complète de la passerelle MCP — enregistrement, sondage, dispatch.

Firewall : Skills

Les passes du scanner, le scoring de risque, et la dérivation de la quarantaine.

Empoisonnement d'outils MCP

Le modèle de menace que la défense contre le rug pull existe pour contrer.

Limites d'egress

Rédiger des règles de deny host/CIDR pour borner où les outils peuvent atteindre.

Checklist de confiance

La checklist de bout en bout pour faire confiance à un serveur MCP.

Guardrails vs. Firewall

Quand la politique de contenu s’applique et quand le firewall le fait.