Sécurité de la passerelle MCP : prouvez que chaque appel d'outil franchit la porte

La sécurité de la passerelle MCP n'est pas établie en plaçant un proxy dans le diagramme d'architecture. La valeur par défaut défendable est plus stricte : prouver que chaque appel d'outil de production protégé a traversé la passerelle prévue, a utilisé la révision de politique attendue, portait une identité validée et une portée de moindre privilège, a produit un reçu d'audit et s'est terminé par un effet vérifié ou un état d'attente explicite . Cette distinction est importante car le terme « passerelle » décrit un placement et non un résultat. Les résultats de recherche actuels aux États Unis mélangent des produits de passerelle, des comparaisons, des explications d'architecture et des allégations de sécurité. Leur promesse commune est un point de contrôle central entre les agents et les serveurs MCP. La question opérationnelle est de savoir si ce point possédait réellement un appel particulier. LeSpécification d'autorisation MCPdéfinit l'autorisation pour les transports HTTP, les métadonnées des ressources protégées, la découverte et la sélection de la portée. Le protocolebonnes pratiques de sécuritéexiger que les responsables de la mise en œuvre prennent en compte les risques liés à la confusion des députés, la validation de l'audience des jetons, les dangers liés au passage des jetons, le consentement et l'auditabilité. Aucun des deux documents ne fait de la simple présence d’un intermédiaire la preuve que chaque itinéraire est contrôlé. Définir le contrat de preuve avant d'acheminer le trafic Commencez par un manifeste de route suffisamment petit pour être expédié à côté de la configuration de la passerelle : Le manifeste crée cinq assertions testables : 1. la requête est passée via la passerelle nommée plutôt que via une URL de serveur directe ; 2. la passerelle a validé une charge de travail ou une identité d'utilisateur non secrète ; 3. la décision est venue de la nouvelle révision politique attendue ; 4. le champ d'application accordé couvrait l'outil sélectionné sans élargir silencieusement l'accès ; 5. la passerelle a émis un reçu d'audit qui peut être joint au résultat en aval. L'assertion d'itinéraire n'est pas théorique. Le courant de CloudflareDocumentation des portails du serveur MCPdécrit un chemin de passerelle facultatif pour les appels d'outils, tandis que la synchronisation en arrière plan se connecte directement aux serveurs en amont. Il avertit également qu'un utilisateur bloqué peut toujours utiliser l'URL directe d'un serveur en amont à moins que l'authentification ne soit appliquée sur ce serveur. Il s'agit de comportements légitimes spécifiques à un produit, et non de règles MCP universelles, mais ils démontrent pourquoi un inventaire doit inclure tous les chemins plutôt que de supposer qu'un portail ou une passerelle a éliminé les portes secondaires. Enregistrez une enveloppe sans contenu par décision. Il n'a pas besoin d'invites, d'arguments d'outil, de corps de résultat, de jetons d'accès ou de secrets : Les identifiants opaques suffisent pour tester la propriété de l'itinéraire, l'application de l'identité, la fraîcheur des politiques, la couverture de la portée, l'état d'approbation et la continuité des réceptions. Gardez les valeurs secrètes à leur source. Si un incident nécessite une inspection du contenu, traitez le comme un flux de travail distinct, explicitement autorisé, avec sa propre limite de conservation. L’autorisation et l’application des politiques sont liées mais non interchangeables. La spécification MCP indique que l'autorisation est facultative pour une implémentation ; lorsque l'autorisation HTTP est prise en charge, le serveur protégé agit comme un serveur de ressources OAuth. Une passerelle ne peut donc pas fabriquer de preuve en constatant qu'un jeton porteur a existé. Il doit valider la ressource et l'identité prévues, évaluer la politique relative aux outils pertinents et conserver suffisamment de preuves non secrètes pour expliquer la décision. Les directives de sécurité MCP identifient explicitement le passage de jeton comme un anti modèle, car il peut contourner les contrôles et nuire à la responsabilité. Rejouer huit états que « autorisé » cache Le luminaire qui l'accompagne contient huit requêtes synthétiques. Son classificateur applique les portes dans l'ordre opérationnel : Exécutez le localement : Chaque verdict exige une réponse limitée différente : Verdict Ce que disent les preuves Action suivante GATEWAY BYPASS L'appel protégé a utilisé une autre route ou une autre identité de passerelle Inventaire du client et des points de terminaison en amont ; fermer ou gouverner séparément le chemin direct IDENTITY NOT ENFORCED L'itinéraire était central, mais l'appelant n'a pas été validé Rejetez les appels de production anonymes et corrigez la charge de travail ou l'identité de l'utilisateur à la limite POLICY DRIFT La décision a utilisé une ancienne révision ou des preuves périmées Réconcilier la passerelle en cours d'exécution avec l'artefact de stratégie approuvé avant de réessayer AUTHORIZATION GAP L'outil ou sa portée requise ne correspondait pas à la décision Refuser l'appel, réduire la portée et ajouter un cas de régression au niveau de l'outil AUDIT GAP L'appel a peut être été autorisé, mais aucun reçu pouvant être joint n'existe Réparer le chemin de journalisation/exportation ; garder le verdict inconnu plutôt que vert EFFECT UNCERTAIN Le transport ou l'achèvement de l'outillage n'ont pas prouvé la destination Lisez la destination avant de réessayer, surtout après un délai d'attente WAITING Une action protégée a une dépendance d'approbation nommée Aviser le propriétaire et respecter le délai ; ne pas étiqueter l'agent coincé HEALTHY L'itinéraire, l'identité, la politique, la portée, l'audit, l'approbation et l'effet sont d'accord Conserver les reçus via la fenêtre d'examen des incidents La priorité empêche une attente d’approbation pratique de dissimuler un contournement ou une politique obsolète. WAITING est disponible uniquement après le passage des portes d’itinéraire, d’identité, de stratégie, d’autorisation et d’audit. De même, un effet aval réussi n’excuse pas un appel qui a contourné le chemin de contrôle. L'expérience est délibérément sans contenu. Il vérifie un contrat normalisé, pas un produit de passerelle en direct. Mappez les champs de votre passerelle sur l'appareil plutôt que de copier les noms de champs comme si MCP les avait standardisés. Le protocole définit les messages et le comportement d'autorisation ; les identifiants de révision de politique de passerelle, les formes de reçus d'audit et les vérificateurs de destination restent des choix de mise en œuvre. Séparer l'autorisation de l'effet résultant Une décision d'autorisation prouve uniquement qu'une politique a autorisé une tentative. Cela ne prouve pas que l'outil a fonctionné une fois, a modifié la destination prévue ou a produit le livrable demandé. Pour une mutation, joignez le reçu passerelle à un reçu destination : Ceci est particulièrement important après un temps mort. Réessayer parce que la passerelle n'a pas reçu de réponse peut dupliquer un effet déjà validé par le système en amont. EFFECT UNCERTAIN demande à l'opérateur de rapprocher d'abord la destination. Une passerelle peut limiter le débit ou autoriser une nouvelle tentative, mais la destination est généralement la source la plus puissante permettant de savoir si l'effet d'origine existe. Pour les outils en lecture seule, le résultat peut être une vérification de schéma, une affirmation de fraîcheur ou une comparaison déterministe avec les champs obligatoires de la tâche. Pour les écritures, préférez une relecture d'API, une version d'objet immuable, un ID de message du fournisseur, un hachage de validation plus des contrôles ou un autre reçu appartenant à la destination. Le résultat de réussite JSON RPC d'un outil est plus faible lorsque le résultat promis se trouve ailleurs. Un déploiement pratique peut rester restreint : 1. Choisissez un serveur MCP de production et un outil à fort impact. 2. Énumérez chaque point de terminaison client et l’URL directe en amont qui peut l’atteindre. 3. Épinglez une identité de passerelle et une révision de politique dans les preuves de déploiement. 4. Envoyez une sonde autorisée et une sonde refusée avec des ID de demande opaques. 5. Vérifiez l'identité de l'appelant, la portée requise, la décision relative à l'outil, la fraîcheur et un reçu d'audit pour les deux. 6. Essayez l'itinéraire direct documenté et prouvez qu'il est bloqué ou explicitement régi. 7. Effectuer un appel nécessitant une approbation et le conserver comme WAITING jusqu'à ce qu'un propriétaire nommé décide. 8. Simulez un délai d'attente après l'effet en amont, puis prouvez que le runbook lit la destination avant de réessayer. 9. Répétez les sondes après les modifications de la passerelle, du fournisseur d'identité, de la stratégie, du client ou du serveur MCP. Il y a des limites. Cet appareil ne teste pas l'analyseur, le moteur DLP, les défenses d'injection rapide ou le scanner de vulnérabilités d'un fournisseur particulier. Cela ne prouve pas qu'une passerelle centrale soit la bonne architecture pour chaque serveur STDIO local. Un processus local peut nécessiter des contrôles au niveau de l'hôte au lieu d'une passerelle réseau. Cela ne fait pas non plus de Sidewisp un modèle ou une passerelle d’outils obligatoire. Le rôle prévu de Sidewisp est adjacent : intégrer l'accessibilité, les progrès, les outils, les résultats, le temps et les données budgétaires dans une vision de la santé de l'agent et préserver l'autorité humaine autour du rétablissement. Sidewisp est actuellement en préversion privée. L'expérience en direct est un site Web à accès anticipé et une démonstration interactive ; un adaptateur de passerelle MCP de production, un moteur de surveillance en direct et un exécuteur de récupération automatisée ne sont pas livrés. Utilisez le récépissé d'exécution avec vos systèmes de passerelle et de destination actuels plutôt que de supposer que Sidewisp les surveille ou les corrige actuellement. La solution est concrète : inventorier les itinéraires, épingler la porte et la politique, vérifier l'identité et la portée du moindre privilège, exiger un reçu d'audit joignable, préserver l'attente légitime et vérifier la destination avant de déclarer le succès. La sécurité de la passerelle MCP ne devient une preuve opérationnelle que lorsque le chemin de contrôle et l'effet concordent.