Passer au contenu principal
Chaque serveur MCP que vous enregistrez, chaque skill qu’un agent installe, et chaque hôte qu’un outil atteint est une dépendance que vous n’avez pas écrite. La chaîne d’approvisionnement d’un agent est dynamique — elle grandit à l’exécution, souvent sans humain dans la boucle — de sorte que le modèle classique « relire le lockfile au moment du build » ne tient pas. Un skill communautaire peut être détourné après que vous lui avez fait confiance ; un serveur MCP distant peut ajouter discrètement un outil ; un outil de fetch peut être orienté vers un hôte contrôlé par l’attaquant. La réponse d’OrcaRouter est de gouverner la chaîne d’approvisionnement là où elle agit — à la passerelle, à la première utilisation — au lieu d’essayer de vérifier chaque dépendance au moment de l’installation. Cette page est la page d’accueil de cas d’usage pour ai supply chain security ; les références Firewall et Skills portent les mécanismes complets.

​
1. Sécurité de la chaîne d’approvisionnement ia pour les agents, à la passerelle

Le point d’étranglement est le chemin de relais. Que la capacité ait été enregistrée à la main, auto-installée par l’agent, ou tirée d’un registre communautaire, son premier appel d’outil franchit api.orcarouter.ai — et c’est là que le Firewall l’évalue. Quatre contrôles se composent en une seule posture :

Passerelle MCP, éval par appel

Chaque tools/call est évalué contre votre politique avant le dispatch — le manifeste n’est jamais la source de vérité.

Bandes de risque & quarantaine des skills

Les capacités installées sont scannées, scorées, et mises en attente de revue jusqu’à ce qu’un humain les approuve.

Identifiants MCP chiffrés

Les secrets d’auth de serveur sont chiffrés au repos et injectés au dispatch — jamais exposés au modèle, à l’agent, ou aux arguments d’appel.

Listes blanches d'egress

Épinglez où les appels d’outils peuvent envoyer des données, de sorte qu’une dépendance compromise ne puisse pas exfiltrer vers un hôte que vous n’avez jamais approuvé.
La détection est à la passerelle, à la première utilisation — pas dans votre gestionnaire de paquets ni votre système de fichiers. C’est délibéré : c’est l’unique chemin qui voit chaque agent et chaque appel d’outil peu importe comment la capacité est arrivée là.

​
2. La menace : une dépendance qui grandit après que vous lui faites confiance

VecteurCe qui se passe
Rug-pullUn serveur MCP enregistré ajoute un outil (shell.exec, un nouveau fetch) que vous n’avez jamais approuvé.
Skill creepUn skill installé utilise des outils ou des hôtes que son manifeste n’a jamais déclarés.
Vol d’identifiantL’implémentation d’outil d’un serveur compromis lit son propre secret d’auth pour téléphoner à la maison.
Exfiltration par egressUne chaîne récupérer→envoyer expédie vos données vers un hôte contrôlé par l’attaquant.
La cause racine commune : « je fais confiance à ce serveur » est traité comme permanent, et l’agent continue d’appeler des outils nouveaux ou modifiés sans revue supplémentaire.

​
3. Un exemple concret — enregistrer et épingler un serveur MCP

Vous enregistrez un serveur MCP tiers depuis la console (Settings → Firewall → MCP servers ; les écritures nécessitent Developer+). Le secret d’auth du serveur est stocké chiffré — vous le fournissez une fois, la passerelle l’injecte au dispatch, et il est masqué à chaque lecture après cela. Un enregistrement de serveur MCP porte :
ChampValeurs
auth_modenone, bearer, oauth, basic
statusok, degraded, down (défini par la sonde de santé)
credentialschiffrés au repos, jamais renvoyés en clair
Après l’enregistrement, sondez-le depuis la console pour énumérer ses outils actuels. La sonde est une opération de session d’espace de travail (/api/workspace/firewall/*) qui nécessite Developer+, pas une clé de relais — enregistrement, sonde, et rédaction de règles se produisent tous sur le plan de gestion : 
# Console / management plane — workspace session, Developer+.
# (The relay sk-orca-... key is for /v1/* traffic only.)
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/<id>/probe \
  -H "Authorization: Bearer <workspace-session-token>"
La sonde persiste l’accessibilité du serveur et fait un snapshot d’un hash de baseline de son ensemble d’outils annoncé (trust-on-first-use). Ensuite scopez une règle de Firewall avec tool_name_glob: <server>.* à pending_approval jusqu’à ce que vous ayez vu un historique d’appels propre — chaque appel de ce serveur est mis en attente pour un humain avant de s’exécuter. Une fois que vous lui faites confiance, relâchez la règle vers audit ou allow. À partir de ce point, la passerelle MCP évalue chaque tools/call sur la surface mcp avant le dispatch — de sorte que si un rug-pull ajoute plus tard un outil non déclaré, c’est votre politique, pas le manifeste du serveur, qui décide s’il s’exécute.
Re-sondez après toute montée de version amont (POST /api/workspace/firewall/mcp_servers/:id/probe, Developer+). Si l’ensemble d’outils annoncé dérive de la baseline approuvée, le schema_status du serveur bascule à changed et le dispatch fail-closed jusqu’à ce qu’un admin re-baseline (approve_schema) ou le mette en quarantaine — le rug-pull ne peut pas passer en production silencieusement.

​
4. Bandes de risque & quarantaine des skills

Chaque capacité installable — que vous l’ayez enregistrée ou que la passerelle l’ait auto-détectée à l’exécution — est passée à travers le scanner de skills. Les constatations remontent à une bande de risque et à un mode d’application :
low · medium · high · critical. La bande est dérivée de passes de scanner déterministes sur le manifeste et les scopes déclarés (utilisation d’outil non déclarée, egress réseau hors des scopes approuvés, écritures de système de fichiers non sûres, texte de manifeste en forme d’injection).
allow (vos règles de politique décident), quarantine (tout verdict non-deny escalade en pending_approval — un humain approuve chaque appel), block (force deny sur tous les outils de ce skill peu importe les règles). Un skill de bande high se met en quarantaine automatiquement ; critical bloque.
Une capacité qu’un agent s’auto-installe, ou un outil qu’un rug-pull ajoute, est mise en attente pending_approval peu importe son score de scan jusqu’à ce qu’un humain la relise. Un opérateur ne peut pas ajouter discrètement un outil et faire en sorte que vos agents commencent à l’utiliser.
Le mode d’application ne se resserre jamais que d’un cran — approuver un skill ne relâche jamais un block qu’un scan frais a posé.

​
5. Listes blanches d’egress — contenir le « téléphone à la maison »

Le résultat de chaîne d’approvisionnement le plus dommageable est une dépendance compromise qui exfiltre. La surface egress du Firewall évalue la destination sortante (host / IP / CIDR) qu’un outil rapporte, de sorte que vous pouvez épingler où les données sont autorisées à aller. Vous rédigez une règle d’egress vous-même : une liste blanche host/CIDR avec un prédicat cidr_match refuse tout ce qui est hors-liste. Combinez-la avec une règle de séquence qui brise la chaîne récupérer→egress, et un outil empoisonné qui essaie d’expédier un document récupéré vers un hôte inconnu est refusé à la passerelle.
Le niveau d’autonomie tight livre un preset SSRF, mais il refuse les noms d’outils en forme de fetch (http_fetch, web_search, fetch_url, request) — ce n’est pas une denylist CIDR/cloud-metadata. Si vous avez besoin d’un blocage d’egress RFC-1918 / metadata / CIDR-spécifique, rédigez la règle deny d’egress host/CIDR vous-même. Voir Firewall : Règles pour l’opérateur cidr_match et le scoping d’egress.

​
6. Identifiants chiffrés — un serveur compromis ne peut pas lire vos clés

Les secrets d’auth de serveur sont chiffrés au repos et injectés par la passerelle au moment du dispatch. Ils n’atteignent jamais le modèle, l’agent, ou les arguments d’appel d’outil — de sorte qu’un serveur compromis ou malveillant ne puisse pas exfiltrer vos clés API en lisant son propre blob d’identifiant. La console renvoie toujours le secret masqué — même à un Admin. La valeur déchiffrée est remise sur exactement un chemin : une requête portant un token scopé à la passerelle firewall (un type de token dédié qu’un Admin frappe explicitement pour la passerelle/proxy), de sorte qu’une clé de relais ordinaire fuitée ne puisse pas énumérer vos identifiants MCP.

​
7. Le condenser pour un audit

La gouvernance de chaîne d’approvisionnement est aussi un artefact d’audit. OrcaRouter s’aligne sur l’OWASP Top 10 for LLM Applications — y compris le contrôle LLM05 Supply Chain — dans le cadre du moteur de conformité, aux côtés de frameworks comme soc2, iso_27001, iso_42001, nist_ai_rmf, et l’eu_ai_act. Installer un compliance pack (POST /api/compliance/packs/:key/install, Admin d’espace de travail, plan payant) matérialise les guardrails et politiques firewall correspondants et démarre dans une posture observe-first. Les rapports de conformité incluent une section AI-supply-chain evidence — les fournisseurs amont vers lesquels votre espace de travail a réellement routé, plus une revue d’accès privilégié et d’hygiène des clés — et sont signés Ed25519 et publiquement vérifiables. Parcourir le catalogue et la préparation est gratuit pour tout Member ; voir Conformité pour le cycle de vie complet.
La gouvernance MCP est deux couches complémentaires : évaluation firewall par appel sur la surface mcp (application sur ce qu’une dépendance fait), plus une baseline d’intégrité de schéma d’outils (hash trust-on-first-use de l’ensemble d’outils annoncé, re-vérifié à chaque sonde — la dérive bascule le schema_status du serveur à changed et fait échouer le dispatch en mode closed jusqu’à ce qu’un admin re-baseline ou mette en quarantaine). Avec les bandes de risque et la quarantaine des skills, c’est une application sur à la fois ce qu’une dépendance fait et un enregistrement vérifiable de ce qu’elle a déclaré.

​
8. Une baseline de chaîne d’approvisionnement

Enregistrez-le, sondez son ensemble d’outils, et scopez une règle <server>.* à pending_approval ou audit. Lisez les constatations du scan — toute constatation d’outil non déclaré ou d’egress externe est une raison de le garder en quarantaine. Vérifiez qui contrôle l’URL de l’endpoint.
Gardez une liste blanche d’egress épinglée pour tout agent avec des outils de fetch/search/export. Surveillez la vue Discovered tools pour les capacités apparues sans règle, et le flux d’anomalies pour les chemins d’outil à outil nouveaux.
Désactivez le serveur (PUT .../mcp_servers, "enabled": false) — ses identifiants ne sont jamais déchiffrés tant qu’il est désactivé. Re-sondez pour faire surface les nouveaux outils, re-scannez le skill, et relisez la file pending_approval plutôt que d’approuver en masse.

​
9. Menaces & concepts liés

Firewall : Serveurs MCP

Enregistrez les serveurs MCP derrière la passerelle, sondez leurs outils, et appliquez un verdict par appel avant qu’aucun appel n’atteigne le vrai serveur.

Firewall : Skills

Scannez et scorez le risque de chaque capacité installable. Mettez en quarantaine ou bloquez les skills risqués avant que leurs outils ne s’exécutent.