Sécurité et dépannage MCP
MCP peut échouer au niveau de la mise en réseau, de l'authentification, de la découverte ou de l'exécution.
Ce que vous apprendrez
- Expliquez : hôte, client et serveur
- Appliquez l'idée dans un exemple : sécurité et dépannage MCP
- Reconnaître les limites et vérifier le résultat de l'exercice
MCP peut échouer au niveau de la mise en réseau, de l'authentification, de la découverte ou de l'exécution. Séparez ces étapes pour éviter les changements aléatoires.
Ces étapes font référence aux fonctionnalités identifiées dans le code de l'application. Ce matériel n'a pas été validé sur une instance réelle ; vérifiez la documentation et les options de votre version.
Comment ça marche, étape par étape
Hôte, client et serveur
MCP est un protocole connectant les applications d'IA à des capacités externes. L'hôte fournit l'expérience, le client gère la connexion et le serveur expose des outils, des ressources ou des invites en fonction de la prise en charge. Les outils exécutent des opérations ; les ressources fournissent un contenu adressable ; les invites fournissent des modèles. Tous les serveurs n'implémentent pas les trois. Le transport transporte les messages, l'authentification identifie les appelants et l'autorisation contrôle l'accès. Vérifiez la révision du protocole et les extensions prises en charge aux deux extrémités. La compatibilité ne peut pas être déduite de la seule étiquette « MCP ».
Vérifier l'accès avant utilisation
Les autorisations doivent être appliquées par les serveurs et la couche de données. Ne laissez pas le modèle décider si un utilisateur peut voir un document. Filtrez les sources avant qu'elles n'entrent dans le contexte, et non après avoir généré la réponse. Utilisez des informations d'identification à accès minimal, gardez-les à l'écart des invites, des captures d'écran et du code du navigateur, et faites pivoter les clés exposées. Une liste blanche de domaines de widgets ne remplace pas l'authentification API. L'authentification vous identifie ; l’autorisation détermine les opérations et les données que vous pouvez utiliser. Test d'accès refusé également.
Les erreurs nécessitent des chemins explicites
Un délai d'attente diffère d'une erreur d'autorisation. Réessayez uniquement les erreurs transitoires, avec des tentatives limitées et des délais croissants. Une opération avec des effets secondaires peut s'exécuter avant que sa réponse ne soit perdue ; réessayer sans clé d'idempotence peut dupliquer l'effet. Le streaming montre la progression mais ne garantit pas l'achèvement. Les points de contrôle peuvent permettre la reprise des étapes ayant échoué dans les limites d'exécution. Stockez l'identifiant d'exécution, l'étape, la durée et l'erreur tout en supprimant les secrets des journaux. Mesurez les chemins lents ainsi que les moyennes.
Le schéma explicatif
Suivez les flèches pleines pour le flux principal. Les flèches bleues en pointillés fournissent des données ou un contexte ; les flèches roses en pointillés affichent des commentaires ou des résultats renvoyés. Les couleurs et les formes distinguent les modèles, les magasins, les décisions et les sorties. Sur un petit écran, faites défiler horizontalement pour suivre le schéma complet.
Un exemple complet
Une mauvaise clé entraîne un refus d'accès. Un mauvais point de terminaison peut renvoyer une page HTML. Un délai d'attente de l'outil ne prouve pas un problème de schéma de découverte.
Essayez-le vous-même
- Testez une mauvaise clé, un mauvais point de terminaison et des arguments non valides à l'aide des données de démonstration.
- Enregistrez l’entrée, la source et le résultat attendu avant d’exécuter l’expérience. Utilisez uniquement les données fictives de l'exemple.
- Suivez les étapes du diagramme. À chaque étape, enregistrez les informations reçues et produites ; ne confondez pas le résultat intermédiaire avec le résultat final.
- Répétez après avoir supprimé les informations nécessaires ou rendu la saisie ambiguë. Vérifiez si le système clarifie, arrête ou invente une réponse.
- Comparez avec la solution expliquée. Conservez la configuration, la date, le résultat et une explication des différences. Changez une chose et retestez.
Une solution expliquée
Classez l'erreur et corrigez la configuration sans copier les secrets dans les journaux ou les captures d'écran. Un exercice réussi vous permet de montrer le lien entre les contributions, les étapes et les résultats. Lorsqu’une information manque, une réponse prudente est plus utile que des détails inventés. Comparez bien plus que le style : vérifiez également les conditions, les sources et les opérations.
Quand cette approche est utile et quelles sont ses limites
Un serveur connecté peut toujours avoir un outil indisponible. Choisissez cette approche lorsqu’elle améliore un besoin mesuré. Gardez une base de référence simple et comparez les résultats en utilisant des entrées identiques. Un exemple réussi n’établit pas la fiabilité dans toutes les situations.
Vérifiez vos connaissances
Un serveur doté d’outils propose-t-il automatiquement des ressources et des invites ?
Non. Les fonctionnalités sont facultatives et doivent être découvertes et vérifiées.
Pourquoi supprime-t-on une source privée après avoir répondu trop tard ?
Les données sont déjà entrées dans le contexte du modèle et peuvent être divulguées.
Quel résultat cet exercice devrait-il produire ?
Classez l'erreur et corrigez la configuration sans copier les secrets dans les journaux ou les captures d'écran.
Les mots à retenir
- Serveur MCP: Un service exposant des capacités via Model Context Protocol.
- Autoriser / Autorisation: Vérification du droit d'accès à une opération ou une ressource.
- Idempotence: Répétition contrôlée sans dupliquer un effet.
Sources et votre prochaine étape
- Model Context Protocol — Spécification
- OWASP — Injection de prompt
- LangGraph — Flux de travail et agents
Pour préparer : M02 — Connexion d'un serveur MCP dans l'application