Points clés
- Traitez chaque appel d'outil comme une action d'entreprise authentifiée et autorisée — pas comme une sortie de modèle.
- Placez la découverte, les politiques, les limites de débit et les contrôles d'audit derrière une passerelle MCP sensible à l'identité.
- Évaluez la sélection d'outils et les résultats de bout en bout, pas seulement la qualité des réponses.
- Exigez une approbation humaine explicite pour les actions irréversibles ou à fort impact.
Un protocole résout la connectivité — pas la gouvernance
Le Model Context Protocol offre aux applications et agents un moyen cohérent de découvrir des outils, de récupérer du contexte et d'invoquer des capacités. Cette interopérabilité est importante, mais elle ne détermine pas quels outils un employé peut utiliser, à quelles données un agent peut accéder, ni si une action devrait nécessiter une approbation.
En production, le travail difficile se situe autour du protocole : propagation de l'identité, propriété des outils, limites des identifiants, application des politiques, versionnage, observabilité et réponse aux incidents. Un serveur MCP exposé directement à chaque client déplace simplement la complexité d'intégration vers un autre endroit.
Utiliser une passerelle sensible à l'identité comme plan de contrôle
Une passerelle fournit une frontière gouvernée unique entre les hôtes d'agents et les outils organisationnels. Elle peut authentifier l'utilisateur et la charge de travail appelants, résoudre les serveurs approuvés, appliquer les politiques, limiter le débit et le périmètre, et émettre des événements d'audit cohérents.
La passerelle ne devrait pas devenir un lieu pour la logique métier. Sa responsabilité est la connectivité contrôlée : valider les jetons, transmettre le contexte d'identité, appliquer les listes d'autorisation, enregistrer les appels et empêcher un client compromis d'atteindre des outils hors de son autorisation.
- Maintenir un registre avec les propriétaires, versions, classifications de données et statut de support.
- Autoriser la combinaison utilisateur, agent, outil, tenant et opération demandée.
- Émettre des identifiants éphémères en aval au lieu de partager des secrets à longue durée.
- Séparer les outils en lecture seule des actions qui modifient les systèmes ou contactent des tiers.
Concevoir les outils autour de tâches, pas d'APIs brutes
Exposer des centaines de points d'accès de bas niveau rend la sélection d'outils plus difficile à évaluer et élargit la surface de sécurité. Un outil de production devrait représenter une tâche délimitée avec un contrat d'entrée clair, une sortie prévisible et des effets de bord explicites.
Par exemple, « préparer un dossier de renouvellement à partir des dossiers clients approuvés » est plus facile à gouverner qu'un accès sans restriction à la recherche CRM, au stockage de fichiers et aux APIs de messagerie. L'implémentation peut appeler ces systèmes en interne, mais l'agent reçoit une capacité plus étroite alignée sur le flux de travail réel.
Tracer la décision et l'exécution
Le traçage distribué devrait connecter la requête utilisateur d'origine, la décision du modèle, l'outil sélectionné, le résultat de la politique de la passerelle, l'exécution du serveur et la dépendance en aval. Un contexte de trace compatible OpenTelemetry permet d'investiguer la latence, les erreurs, les appels répétés et les chaînes d'outils inattendues sans inventer une pile d'observabilité séparée.
Les métriques opérationnelles sont nécessaires mais insuffisantes. Les équipes ont également besoin de jeux d'évaluation mesurant si le bon outil a été sélectionné, si les arguments étaient valides, si l'autorisation a été préservée, si la tâche a abouti et si la réponse finale représentait fidèlement le résultat de l'outil.
- Précision de sélection d'outils et taux d'appels inutiles
- Refus d'autorisation et motifs de politique
- Succès de bout en bout, latence et coût
- Nouvelles tentatives, boucles, délais d'attente et tâches abandonnées
- Interventions humaines et motifs de rejet d'approbation
Déployer l'autonomie selon la conséquence
Commencez par des tâches de récupération et de préparation où les utilisateurs vérifient les résultats. Ajoutez ensuite des actions réversibles, avec des clés d'idempotence et confirmation. Les opérations à fort impact — changements financiers, communication externe, changements d'accès ou actions destructrices — devraient rester derrière une approbation explicite jusqu'à ce que des preuves soutiennent un modèle de contrôle différent.
L'objectif n'est pas l'autonomie maximale. C'est la délégation fiable : les utilisateurs comprennent ce que l'agent peut faire, les équipes de sécurité peuvent expliquer pourquoi une action a été autorisée, et les opérateurs peuvent arrêter ou récupérer un flux de travail lorsque les hypothèses échouent.
Sources et lectures complémentaires
À propos de l’auteur
Centillion Edge Engineering
Notre équipe d’ingénierie écrit sur les décisions d’architecture, de sécurité, de données et de livraison derrière des systèmes d’entreprise fiables.