Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Stratégie de gouvernance de MCP

L'autre fonctionnalité essentielle que MCP offre aux entreprises est la prise en charge de la gouvernance centralisée. Votre stratégie de gouvernance MCP doit prendre en compte l'authentification et l'autorisation des serveurs MCP ainsi que des ressources auxquelles ils accèdent. Il devrait également aborder la limitation du débit pour protéger les ressources en aval, les mesures opérationnelles pour surveiller l'utilisation et les performances des outils, et la gestion des déploiements et de la distribution des serveurs MCP.

Authentification et autorisation

L'un des aspects les plus importants de votre stratégie d'authentification et d'autorisation consiste à gérer l'accès aux ressources en aval depuis les serveurs MCP. Lorsqu'un utilisateur appelle un agent, une authentification et une autorisation sont effectuées pour garantir que l'utilisateur est autorisé à appeler l'agent. L'agent orchestre ensuite l'appel d'outils spécifiques sur les serveurs MCP. Vous devez décider comment autoriser l'accès pour chaque outil.

L'une des options est machine-to-machine l'autorisation, où le consentement ou l'interaction de l'utilisateur ne sont pas requis. Par exemple, un appel d'agent basé sur le temps utilise un serveur MCP pour collecter les journaux d'une application et les analyser. Dans ce scénario, l'agent est préautorisé à accéder aux données spécifiées. La deuxième option est l'accès délégué par l'utilisateur, dans le cadre duquel un utilisateur donne son accord pour accéder à des données et à des ressources spécifiques à l'utilisateur.

Le tableau suivant présente les modèles d'authentification et d'autorisation.

L'accès délégué par les utilisateurs nécessite une mise en œuvre minutieuse et doit être développé avec votre équipe de sécurité. Les agents doivent être en mesure d'évaluer quels outils un LLM a sélectionnés et s'ils nécessitent une autorisation supplémentaire. Les outils MCP doivent inclure des descriptions indiquant leurs exigences en matière d'authentification et d'autorisation et indiquant où récupérer les jetons d'accès. Les applications clientes doivent prendre en charge les demandes d'authentification intermédiaires, et le client MCP doit fournir les informations d'identification récupérées à l'agent pour chaque appel d'outil.

Vous devez vous assurer que les outils MCP disposent toujours de leurs propres jetons pour accéder aux fonctionnalités externes et que l'accès est enregistré et audité. Les informations d'identification de l'utilisateur ne doivent pas être propagées par le biais de votre système agentic. Par exemple, vos serveurs MCP ne doivent pas utiliser le même jeton pour accéder aux données que celui utilisé pour appeler l'agent. Les appels en aval doivent utiliser des jetons explicitement définis et générés à des fins spécifiques. Cela permet de fournir des garde-fous supplémentaires pour empêcher l'accès involontaire aux données pour le compte d'actions. Cela peut également aider à empêcher les hallucinations de produire des résultats imprévus. Imaginez qu'un utilisateur disposant de droits d'administrateur complets demande à un agent de cloner une base de données de production pour une utilisation en pré-production. Pour ce faire, l'utilisateur n'a besoin que READ d'CREATEautorisations. Supposons que le LLM hallucine et pense qu'il doit nettoyer l'ancienne base de données dans le cadre de cette demande. S'il réutilise les informations d'identification de l'utilisateur, il est probable qu'il réussisse, car les informations d'identification d'origine de l'utilisateur disposent d'DELETEautorisations. Au lieu de cela, si le serveur MCP utilise un jeton délimité intentionnellement pour la demande avec des CREATE autorisations justes READ et limitées, la tentative de suppression de la base de données de production échouera.

Vous pouvez utiliser Amazon Bedrock AgentCore Identity pour implémenter ces modèles. Assurez-vous de choisir intentionnellement si les autorisations permettant de répertorier et d'invoquer des outils hébergés par un serveur MCP impliquent l'autorisation d'accéder aux fonctionnalités externes exposées par le serveur MCP. Ce flux d'identité du serveur MCP vers la ressource et de retour vers l'utilisateur dépend du type de service d'authentification et d'autorisation utilisé. Vous devez décider de la manière dont cela est géré à grande échelle pour vos serveurs MCP.

Lorsque vous concevez vos modèles d'authentification et d'autorisation, mettez en œuvre des mécanismes d'isolation des jetons qui récupèrent différents jetons d'accès pour chaque outil consulté. Ne réutilisez pas les jetons entre les outils et les serveurs. AgentCore L'identité fournit cette capacité d'isolation des jetons. Il gère automatiquement à la fois les jetons de charge de travail (pour machine-to-machine l'authentification) et les jetons utilisateur (pour l'accès délégué par l'utilisateur) afin de garantir une séparation appropriée et d'empêcher l'augmentation des autorisations. Cela est particulièrement important lors de l'intégration de serveurs MCP distants ou de passerelles MCP.

Bonnes pratiques pour l'authentification et l'autorisation MCP

Contrôle de la charge

Comme pour tout système distribué, vous devez réfléchir à la manière de contrôler la charge de votre parc de serveurs MCP. Tout d'abord, vous devez déterminer s'il convient d'implémenter la limitation de débit dans vos serveurs MCP et où implémenter les limites. Si vous choisissez de ne pas implémenter de limitation de débit, vous répercutez toute limitation de débit effectuée par les ressources en aval. De nombreux systèmes choisissent de limiter le débit en fonction des attributs de la demande, tels que l'identifiant d'utilisateur ou de compte. Vérifiez que les demandes envoyées aux services en aval comportent les mêmes attributs afin que plusieurs utilisateurs ne soient pas affectés par la charge générée par un autre utilisateur.

Si vous choisissez d'implémenter la limitation de débit, l'approche recommandée consiste à implémenter la limitation de débit principale au niveau du serveur MCP, les services principaux fournissant une protection secondaire et les agents adaptant leur comportement en fonction des commentaires sur les limites de débit. Déterminez si les limites de débit sont par serveur MCP ou par outil. Les limites de débit par serveur MCP aident à protéger votre parc de serveurs MCP et vos services dans un environnement mutualisé. Cependant, cela peut être très grossier. Les limites de débit par outil sont conçues pour éviter de surcharger les ressources en aval qui pourraient ne pas se limiter suffisamment au débit. Si un outil en appelle plusieurs APIs, vous devez définir la limite de débit de manière à ce qu'elle corresponde au débit le plus bas autorisé par ceux-ci APIs.

Les informations sur les limites de débit transmises dans les en-têtes HTTP peuvent également constituer une mesure utile pour les utilisateurs et les systèmes automatisés afin de les aider à gérer leur propre taux de demandes et leur stratégie de nouvelles tentatives. Par exemple, vous pouvez renvoyer ces en-têtes à l'agent depuis votre serveur MCP, comme illustré dans l'exemple suivant :

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1640995200

En outre, envisagez le délestage pour protéger l'ensemble du service lorsqu'aucun client ne dépasse une limite de débit mais que la charge a un impact sur les performances du système.

Meilleures pratiques pour contrôler la charge

Métriques opérationnelles

Les indicateurs clés à saisir pour les implémentations de MCP doivent se concentrer sur l'expérience client qu'ils offrent. Ces indicateurs incluent généralement l'utilisation des jetons, la précision de la sélection des outils, le nombre d'outils enregistrés auprès de l'agent et la latence des outils. Par exemple, la surveillance des jetons de sortie renvoyés par chaque outil vous permet de définir des alarmes lorsque les outils dépassent un seuil d'utilisation de la fenêtre contextuelle. Lorsqu'un outil dépasse ce seuil, vous souhaiterez peut-être revoir son comportement. Cela est également lié à la stratégie de conception des outils MCP. Les indicateurs de précision de la sélection des outils indiquent dans quelle mesure les agents choisissent les outils appropriés pour des tâches données, tandis que la vitesse d'exécution et les taux de réussite mettent en évidence les problèmes de performance et de fiabilité.

Par exemple, pour évaluer les mesures de précision relatives à la sélection et à l'utilisation des outils, les AWS équipes ont créé des ensembles de données exceptionnels pour les tests de régression. Les ensembles de données ont été générés de manière synthétique en utilisant les journaux d'invocation historiques LLMs des API lors des requêtes des utilisateurs. À l'aide des indicateurs prédéfinis de sélection et d'utilisation des outils (tels que la précision de sélection des outils, la précision des paramètres de l'outil et la précision des appels de fonctions multitours), les AWS équipes ont pu évaluer objectivement la capacité de l'agent IA à identifier correctement les outils appropriés, à renseigner ses paramètres avec des valeurs précises et à maintenir des séquences d'invocation d'outils cohérentes tout au long des virages de conversation.

La mesure du nombre d'outils enregistrés auprès d'un agent peut vous aider à identifier les problèmes potentiels liés à la gestion des fenêtres contextuelles ainsi que les modifications des outils disponibles présentés par les serveurs MCP. Vous devez régulièrement consulter les indicateurs opérationnels qui indiquent l'expérience utilisateur avec votre serveur et vos outils MCP.