Une connexion MCP est un moyen d'exposer les capacités, et non une raison de faire confiance à chaque opération qu'elle propose. Avant de connecter un analyste d'authentification, spécifiez quel locataire il peut inspecter, quelles preuves il peut récupérer et quelles actions restent indisponibles. Une mission de lecture de rapport ne doit pas hériter de la publication DNS simplement parce qu'un serveur propose les deux outils.
Commencez par le chemin de données réel
Mappez l'application hôte, le client MCP, le serveur, le magasin de rapports et toute API en aval. Enregistrez où se terminent les jetons et quelle organisation exploite chaque composant. Le Spécification d'autorisation MCP décrit l'autorisation pour les transports basés sur HTTP ; ne supposez pas que son flux s'applique inchangé aux serveurs stdio locaux. Un exécutable local peut avoir accès au système de fichiers ou à l'environnement même sans échange OAuth distant.
Séparez la récupération du rapport de la récupération des messages bruts. Les décomptes agrégés peuvent répondre à une question sur la tendance des expéditeurs sans divulguer les objets des messages, les destinataires ou les pièces jointes. Appliquez l'isolation des locataires sur le serveur à l'aide d'un contexte authentifié plutôt que d'accepter un nom de locataire fourni par le modèle comme autorité. Renvoie des identifiants de source stables afin qu'un résumé puisse être retracé sans exposer les URL de stockage sans restriction.
Limiter les identifiants et la portée des outils
Utilisez les informations d’identification avec la portée minimale des ressources et des actions prises en charge. Conservez les secrets dans le mécanisme d'identification approuvé, et non dans les invites, les descriptions d'outils, les champs de rapport ou les journaux. Le Conseils de sécurité MCP interdit le passage de jeton : un serveur ne doit pas simplement accepter et transmettre un jeton en amont destiné à un autre service. Validez le public visé et mettez en œuvre la relation d’autorisation en aval appropriée.
Inventoriez tous les outils exposés, y compris les fonctions génériques HTTP, shell et d'écriture de fichiers. Masquer un bouton spécifique au DNS ne sert à rien si un outil d'exécution générique peut appeler le même fournisseur avec des informations d'identification larges. Supprimez les fonctionnalités inutiles à la limite d’exécution. Les annotations d'outils et les noms descriptifs peuvent aider les clients à présenter les outils, mais ne remplacent pas une autorisation forcée.
Exercer un contenu de rapport hostile
Pour la politique écrite ci-dessous, supposons un locataire A authentifié et une tâche d’analyse de rapport approuvée. Seul read_report pour le locataire A est autorisé. Le contenu du rapport demandant un secret ou une publication DNS ne peut pas étendre cette autorisation. Il s'agit d'une politique proposée, et non d'un test de sécurité exécuté ou d'une configuration de serveur vérifiée.
Traitez le texte du rapport, les échantillons de messages et les instructions renvoyées par le serveur comme des preuves non fiables. Une chaîne prétendant être un administrateur ne devient pas un approbateur. L’analyste peut qualifier cette chaîne de suspecte sans y obéir. OWASP recommande des défenses à plusieurs niveaux, car le libellé des instructions à lui seul n’élimine pas une injection rapide.
Inspecter le grand livre de décisions complet
- Cas de propriétaire connu : locataire A, tâche approuvée, read_report pour A. Autoriser selon la politique proposée ; le calcul utilise uniquement les preuves retournées approuvées.
- Cas de mauvais locataire : A authentifié demande le locataire B. Refuser la lecture quelle que soit l’étiquette du locataire dans le rapport.
- Cas de contenu hostile : signaler les demandes de texte read_secret et publi_dns. Refuser les deux outils ; le read_report autorisé pour A peut continuer, le texte hostile étant traité uniquement comme des données.
- Cas de propriétaire ambigu : un rapport A nomme à la fois l'application A et l'application B comme propriétaires possibles. Autorisez uniquement la collecte de preuves autorisées, marquez l'identité comme non résolue et faites remonter l'attribution plutôt que de choisir un propriétaire.
- Cas de tâche non approuvée : aucune enquête approuvée n'existe. Suspendez la récupération pilotée par les tâches jusqu'à ce que l'autorisation soit clarifiée, même si un identifiant permet techniquement une lecture.
Aucun appel d'outil, évaluation de modèle, délivrance d'informations d'identification ou test de limite n'a été exécuté pour ce grand livre. Ces règles nécessitent des tests de mise en œuvre sur le serveur réel et les autorisations en aval avant que quiconque prétende qu'elles sont appliquées.
Inspecter le fonctionnement et révoquer l’accès
Enregistrez le nom de l’outil, le locataire authentifié, les références de preuves et le résultat de l’autorisation sans copier les jetons. Testez l’expiration et la révocation des accès, y compris les sessions actives et les autorisations en aval. Une déconnexion réussie chez un client ne suffit pas si les informations d'identification d'un fournisseur de longue durée restent valables ailleurs.
Commencez par un pilote en lecture seule et une liste explicite de questions auxquelles l'analyste doit répondre. Vérifiez que les refus sont utiles : ils doivent identifier les preuves ou la portée manquantes plutôt que d'omettre silencieusement un locataire ou de fabriquer un résultat. Développez les autorisations uniquement après un examen séparé de la nouvelle action. Il s'agit d'un modèle de contrôle proposé et non d'une fonctionnalité vérifiée du produit EmailAuth .