Serveurs MCP gérés dans Claude Code : audit d’un déploiement d’entreprise

La version 2.1.259 de Claude Code ajoute un paramètre administré nommé managedMcpServers. Anthropic indique qu’une organisation peut ainsi fournir à tous ses utilisateurs des entrées de serveurs MCP en HTTP ou SSE. Ces entrées suivent la même structure que celles de .mcp.json. Une entrée qui désigne une commande à exécuter est ignorée par ce mécanisme géré.

La version introduit aussi --permission-prompts none pour les hôtes headless fonctionnant sans supervision. Toute opération qui aurait déclenché une demande de permission est alors refusée automatiquement. Le mode de permission actif continue de décider pour les opérations qu’il peut traiter sans poser cette question.

Anthropic ajoute une sortie JSON à claude plugin validate, corrige des sessions concurrentes qui pouvaient annuler leurs changements respectifs dans ~/.claude.json et élargit la prise en compte des règles de refus pour plusieurs manières de transmettre un fichier à des commandes Bash. La note ne promet ni certification des serveurs, ni élimination générale des risques, ni gain de performance ou résultat commercial. Elle ne précise pas non plus le prix, la résidence des données ou les engagements de disponibilité.

Lecture opérationnelle de CreatikLab : la configuration centrale facilite la lutte contre la dérive, la validation JSON apporte un artefact exploitable et le refus automatique donne un comportement fermé en l’absence d’humain. Ces contrôles ne déterminent toutefois pas si l’usage, les données ou l’action finale sont légitimes.

Avant de distribuer une connexion, décrivez le travail attendu : système interrogé, données nécessaires, action autorisée et conséquence d’un échec. Un accès en lecture à une documentation non sensible ne présente pas le même enjeu qu’une modification de dépôt, un changement de déploiement ou une écriture dans un outil client.

La gestion centralisée ne signifie pas qu’une intégration convient à chaque équipe et à chaque environnement. Elle peut être utile en développement et injustifiée en production. Elle peut aussi être acceptable pour une recherche documentaire, mais pas pour une action externe. Cette segmentation relève de la méthode CreatikLab et non d’une classification automatique annoncée par Anthropic.

• Finalité : tâche permise et usages explicitement interdits.
• Données : systèmes, dépôts, champs et secrets accessibles.
• Exécution : poste interactif, processus contrôlé ou hôte autonome.
• Décision : actions exécutables et validations humaines obligatoires.
• Preuves : journaux, rapports et historique de changement conservés.

Cette matrice est un outil de diagnostic original. Elle s’appuie sur les possibilités techniques confirmées par Anthropic, mais les niveaux de risque et les décisions appartiennent à l’organisation qui déploie le système.

• Lecture à faible conséquence, données non sensibles — Preuve : méthodes documentées et réponses de test. Action : pilote restreint. Responsable : administrateur de l’outil.
• Lecture sensible sans écriture — Preuve : modèle d’identité, restrictions et journaux d’accès. Action : isoler les identifiants et obtenir l’accord sécurité. Responsables : propriétaire du système et sécurité.
• Écriture réversible — Preuve : essais en bac à sable, répétabilité et procédure de retour arrière. Action : conserver une approbation humaine. Responsable : propriétaire du workflow.
• Action irréversible ou visible à l’extérieur — Preuve : mandat explicite, contrôle indépendant et procédure d’incident. Action : ne jamais confondre distribution centrale ou absence de prompt avec autorisation. Responsable : direction métier.
• Capacité inconnue ou trajet de données non documenté — Preuve : insuffisante. Action : refuser l’entrée dans le catalogue géré. Responsable : sponsor de l’intégration.

Règle de décision : ne généralisez une entrée que lorsque sa finalité, son identité, son périmètre de données et sa révocation sont aussi clairs que le bénéfice de sa distribution. À défaut, conservez une expérimentation isolée.

Inventoriez d’abord les configurations .mcp.json. Distinguez les connexions HTTP ou SSE des entrées qui lancent une commande locale. Puisque Anthropic indique que les entrées avec commande sont ignorées, comparez la configuration attendue à celle effectivement reçue. Une absence silencieuse ne doit pas être enregistrée comme une migration réussie.

Créez ensuite un registre contenant le nom du serveur, l’endpoint approuvé, le transport, la finalité, la sensibilité des données, le propriétaire des identifiants, les environnements autorisés et le contact chargé de la révocation. Testez le paramètre géré dans un périmètre non productif. Vérifiez la distribution aux utilisateurs prévus et l’échec visible de l’authentification lorsque les identifiants manquent ou sont révoqués.

Lancez la validation des plugins et archivez sa sortie JSON. Ce rapport atteste un résultat de validation, pas la justesse du processus métier. Complétez-le par des essais fonctionnels, des cas interdits et une revue des journaux. L’élargissement du déploiement doit ensuite faire l’objet d’une décision attribuée.

1. Recenser les entrées et leur transport.
2. Approuver endpoint, identité, finalité et données.
3. Préparer des tests positifs, négatifs et de révocation.
4. Valider les plugins et conserver le rapport JSON.
5. Piloter avec des utilisateurs et dépôts nommés.
6. Examiner les refus, erreurs et prompts inattendus.
7. Étendre, suspendre ou annuler par décision documentée.

L’option --permission-prompts none répond à l’absence d’un opérateur. Anthropic explique que l’action qui aurait demandé une permission est refusée, tandis que le mode actif continue à statuer sur le reste. Il ne s’agit donc ni d’une permission globale, ni d’un remplacement de la politique de permission.

Pour toute action importante, prévoyez trois résultats : autorisation explicite, refus explicite, ou refus faute d’interaction possible. Le workflow doit conserver le contexte, arrêter la branche concernée et prévenir un responsable. Il ne doit pas assouplir ses propres permissions, recommencer sans limite ou signaler comme réussie une opération incomplète.

CreatikLab recommande des identités distinctes pour les automates et les développeurs, un périmètre système limité par workflow et des tests portant sur des identifiants expirés, un endpoint indisponible et des fichiers interdits. L’amélioration des règles de refus annoncée par Anthropic couvre davantage de formes de commande, mais elle ne démontre pas la couverture de toute composition shell ou de tout outil externe.

• Documenter la représentation d’un refus dans les logs et alertes.
• Limiter les reprises réseau sans relancer un refus de permission.
• Transmettre l’action métier bloquée à une personne nommée.
• Interdire au workflow de changer son propre mode de permission.
• Révoquer les identifiants et fermer les sessions lors du retour arrière.

L’audit doit produire des éléments contrôlables. Une déclaration générale de gestion centralisée ne suffit pas. Pour chaque ligne, exigez une preuve, une action corrective et un responsable.

• Catalogue géré — Preuve : fichier managedMcpServers versionné. Action : comparer les endpoints au registre approuvé. Responsable : plateforme.
• Entrées ignorées — Preuve : comparaison de migration. Action : supprimer, remplacer ou encadrer localement chaque commande. Responsable : intégration.
• Authentification — Preuve : cartographie et test de révocation. Action : éliminer les secrets partagés. Responsable : sécurité.
• Plugins — Preuve : rapport JSON de validation. Action : bloquer la livraison en cas d’échec non résolu. Responsable : release.
• Permissions — Preuve : transcription de tests autorisés et refusés. Action : aligner les résultats sur la politique. Responsable : workflow.
• Concurrence — Preuve : test multisession et version installée. Action : confirmer l’absence de perte d’état. Responsable : opérations d’ingénierie.
• Fichiers protégés — Preuve : tests négatifs avec plusieurs formes de commande. Action : analyser toute lecture inattendue. Responsable : tests de sécurité.
• Retour arrière — Preuve : exercice chronométré. Action : retirer la configuration, révoquer les accès et confirmer l’arrêt. Responsable : incident.

Séparez les indicateurs de contrôle des résultats commerciaux. Le suivi opérationnel peut inclure la proportion d’entrées ayant un propriétaire, le statut de validation par version, les refus inattendus, les échecs de tests d’actions interdites, les résultats de révocation et la dérive de configuration. Anthropic ne fixe pas de seuils pour ces indicateurs ; il s’agit d’une spécification CreatikLab.

Lorsqu’un workflow soutient le marketing ou les ventes, reliez chaque exécution à un enregistrement vérifiable. Définissez un lead qualifié selon des critères convenus : marché servi, adéquation avec l’offre, coordonnées légitimes et acceptation par l’équipe commerciale, par exemple. Un formulaire, une ligne enrichie ou une tâche créée automatiquement ne constituent pas seuls un lead qualifié.

La spécification de mesure doit contenir l’événement, l’horodatage, la version du workflow, l’identité du serveur, l’issue de permission, la fiche d’origine, le résultat final et le propriétaire. Distinguez réussite valide, action bloquée, intervention humaine, sortie incorrecte et acceptation en aval. Cette discipline mesure la contribution sans garantir un volume de leads.

N’assimilez pas configuration gérée et autorisation universelle. HTTP ou SSE n’établit pas à lui seul la confiance, et une validation réussie ne garantit pas une décision métier correcte. La suppression des prompts n’autorise pas l’action : Anthropic annonce son refus automatique. Enfin, une entrée fondée sur une commande n’est pas distribuée par ce paramètre puisqu’elle est ignorée.

Examinez les endpoints trop puissants, identifiants partagés, changements de serveur non revus, journaux incomplets, dépendances cachées et traitements qui interprètent un refus comme une réussite. La note officielle ne précise ni conservation, ni certification des endpoints, ni résidence des données, ni disponibilité du serveur distant. Ces sujets nécessitent une analyse technique et contractuelle distincte.

CreatikLab peut livrer un audit de contrôle d’automatisation IA comprenant le registre MCP géré, le modèle de permission, les tests d’échec des hôtes autonomes, les preuves de validation, les limites d’identifiants, la spécification de journalisation et un exercice de retour arrière. Découvrez notre service d’automatisation par l’IA. Pour poursuivre avec le contexte nécessaire, décrivez à Lia vos serveurs, données, workflows et environnements ; le diagnostic doit partir de cette réalité.

À quoi sert managedMcpServers dans Claude Code ?

Selon Anthropic, ce paramètre permet à une organisation de fournir à tous ses utilisateurs des entrées de serveurs MCP HTTP ou SSE structurées comme dans .mcp.json. Les entrées lançant une commande sont ignorées.

La distribution centrale sécurise-t-elle automatiquement un serveur ?

Non. Anthropic ne donne pas cette garantie. Il faut encore contrôler l’endpoint, l’identité, les données, les actions, les journaux et la révocation.

Que fait --permission-prompts none ?

Sur un hôte headless sans supervision, l’opération qui aurait demandé une permission est refusée automatiquement. Le mode de permission actif continue de décider pour les autres opérations.

Peut-on distribuer une entrée MCP fondée sur une commande ?

Pas avec ce paramètre tel qu’Anthropic le décrit, car ces entrées sont ignorées. Leur suppression, remplacement ou maintien sous contrôle local doit être documenté.

Le rapport JSON de validation suffit-il avant la production ?

Non. Il fournit une preuve de validation utile, à compléter par des tests fonctionnels, négatifs, de permission, de révocation et de retour arrière.

Quels livrables exiger d’un prestataire ?

Exigez un registre des serveurs, les limites de données et d’identité, les tests de permission, les rapports archivés, une spécification de logs et de mesure, les responsables et une procédure de retour arrière démontrée.