Serveur MCP pour Claude : Sécurité et Vérification d'Identité

Points clés à retenir

• Un serveur de Protocole de Contexte de Modèle (MCP) de vérification d'identité fournit à Claude des outils typés pour les opérations réelles d'identité et de fraude ; il ne demande pas au modèle d'inventer un résultat de vérification.
• Le serveur hébergé de Didit expose 115 outils à l'adresse https://mcp.didit.me/mcp via HTTP (Hypertext Transfer Protocol) Streamable sans état, en POST seulement.
• L'accès utilise OAuth (Open Authorization) 2.1 avec PKCE (Proof Key for Code Exchange) et l'enregistrement dynamique de clients. Il n'y a pas de mode de clé d'interface de programmation d'application (API) pour le serveur hébergé.
• Le serveur agit en tant qu'utilisateur connecté sous didit:management et didit:verification ; les rôles d'organisation existants continuent de définir ce que Claude peut faire.
• Les réponses contenant des informations d'identification connues sont expurgées et les charges utiles d'erreur sont nettoyées. Les annotations d'outils classent les comportements de lecture, d'écriture et destructeurs ; la suppression générique a une vérification de confirmation côté gestionnaire, mais le schéma annoncé actuel n'expose pas ce champ de confirmation.
• La connexion MCP est gratuite. L'utilisation conserve la tarification publiée de Didit, y compris un forfait complet de connaissance du client (KYC) à 0,33 $ et 500 vérifications gratuites par mois pour chaque fonctionnalité.

Si vous évaluez un serveur MCP de vérification d'identité pour Claude, la question utile n'est pas de savoir si Claude peut appeler un point de terminaison. C'est de savoir si la connexion donne au modèle d'intelligence artificielle (IA) une capacité structurée suffisante pour accomplir un travail réel tout en préservant l'authentification, l'autorisation, l'auditabilité et le contrôle humain. C'est là que les implémentations diffèrent.

Ce guide explique ce modèle d'évaluation en utilisant le connecteur Claude de Didit comme exemple concret. Il ne répète délibérément pas la configuration pas à pas couverte dans le guide d'installation de Claude, l'aperçu de la catégorie dans la référence des outils MCP, ou la séquence de session dans le guide du cycle de vie de la session KYC. Les schémas canoniques et actuels se trouvent dans la documentation et la source publique.

Qu'est-ce qu'un serveur MCP de vérification d'identité ?

MCP est un protocole permettant de fournir des outils à un modèle. Un serveur MCP publie des opérations nommées avec des descriptions et des schémas d'entrée typés. Un client MCP tel que Claude découvre ces opérations, permet au modèle d'en sélectionner une, valide ses arguments et ramène le résultat dans la conversation.

Un serveur MCP de vérification d'identité applique ce modèle au travail réglementé d'identité et de fraude. Au lieu de répondre à partir de connaissances générales lorsqu'on lui demande de vérifier un client, Claude peut créer une session de vérification réelle, récupérer sa décision, exécuter un contrôle de filtrage ou inspecter les flux de travail configurés d'une organisation. Les données renvoyées proviennent du service connecté, et non de la mémoire du modèle.

Cette distinction est essentielle. Le MCP ne fait pas d'un modèle de langage une autorité d'identité, et il ne transfère pas la responsabilité de la conformité au modèle. Il donne au modèle une voie gouvernée vers le système qui effectue les vérifications et enregistre les résultats. Le fournisseur de vérification reste responsable du service ; le client reste responsable de la politique et de l'examen ; Claude coordonne les opérations autorisées.

Une définition utile : un serveur MCP de vérification d'identité est un adaptateur conscient de l'autorisation qui expose les capacités d'identité et de fraude sous forme d'outils typés qu'un client IA peut découvrir et invoquer.

Ce que le serveur de Didit permet dans Claude

Didit est une infrastructure pour l'identité et la fraude. Son catalogue MCP hébergé fournit à Claude 115 outils couvrant 19 domaines au niveau machine. L'intérêt n'est pas seulement le nombre ; c'est l'étendue du travail que Claude peut connecter via une session authentifiée.

Une interaction normale commence par didit_context_get, qui renvoie les organisations et les applications auxquelles l'utilisateur peut accéder. Claude peut ensuite choisir les outils qui correspondent à la tâche :

• didit_session_create crée une session de vérification à partir d'un flux de travail configuré, tandis que didit_session_get_decision récupère la décision résultante.
• didit_verify_id, didit_verify_passive_liveness et didit_verify_face_match exécutent des contrôles documentaires et biométriques ciblés lorsque les fichiers image requis existent sur le système de fichiers du serveur MCP.
• didit_verify_aml exécute le filtrage anti-blanchiment d'argent (AML).
• didit_verify_kyb_search et didit_verify_kyb_select prennent en charge la découverte de registres Know Your Business (KYB) et la sélection d'enregistrements.
• didit_transaction_create enregistre l'activité surveillée, et didit_transaction_screen_wallet effectue le filtrage de portefeuille Know Your Transaction (KYT).
• didit_case_create ouvre un dossier d'enquête, tandis que didit_case_manage prend en charge l'affectation, les commentaires, l'escalade, la réouverture, la résolution et les mises à jour de champs.
• didit_workflow_create et didit_workflow_edit_graph permettent aux utilisateurs autorisés de composer des flux de vérification ; didit_webhook_create connecte les événements résultants aux systèmes en aval.

Ce sont des exemples, et non un substitut à la documentation canonique des outils MCP. Le serveur actuel n'expose que des outils : il ne publie pas de ressources MCP ni de modèles d'invite. La configuration de conformité spécialisée et les rapports statutaires restent des flux de travail gouvernés dans la console d'entreprise plutôt que des actions de chat autonomes.

La limite d'image de Claude hébergé

Cinq outils d'image — didit_verify_id, didit_verify_age, didit_verify_face_match, didit_verify_passive_liveness et didit_lists_entry_upload_face — acceptent des entrées de chemin absolu que leurs gestionnaires lisent à partir du propre système de fichiers du serveur MCP.

Une image téléchargée dans Claude hébergé n'est donc pas normalement disponible pour ces outils : le connecteur n'expose aucun outil de mise en scène de fichiers. Voir une image dans le chat n'est pas la même chose que de fournir un front_image_path lisible. Les outils sont pratiques dans les déploiements locaux ou auto-hébergés où les fichiers peuvent être placés sur le système de fichiers du serveur.

Pour un demandeur réel utilisant Claude hébergé, utilisez didit_session_create, envoyez l'url renvoyée, puis récupérez le résultat avec didit_session_get_decision. Le demandeur capture les preuves configurées dans l'expérience hébergée de Didit ; Claude ne met pas en scène l'image.

La limite d'authentification à évaluer

Le point de terminaison hébergé est https://mcp.didit.me/mcp, utilisant HTTP Streamable sans état, en POST seulement. Claude se connecte via OAuth (Open Authorization) 2.1 avec PKCE (Proof Key for Code Exchange) et l'enregistrement dynamique de clients ; le serveur hébergé n'a pas de mode clé API.

La propriété de sécurité matérielle est l'identité résultante. Les appels s'exécutent en tant qu'utilisateur Didit connecté sous didit:verification et didit:management, tandis que le rôle backend de l'organisation détermine toujours quelles opérations réussissent. Un lecteur ne devient pas un administrateur parce que Claude a sélectionné un outil d'écriture.

Pour l'évaluation, confirmez que l'accès peut être révoqué sans faire pivoter une information d'identification d'application de production, que les actions restent attribuables à un utilisateur et que le contexte multi-organisation est explicite. La séquence exacte de découverte, de consentement et de configuration se trouve dans le guide d'installation de Claude et la documentation d'authentification.

La sécurité est plus que l'authentification

L'authentification répond à la question « qui appelle ? ». Un serveur MCP de qualité production doit également contrôler ce que le modèle voit et comment les actions risquées se déroulent.

Didit marque les outils avec des annotations en lecture seule, en écriture, destructrices, idempotentes et en monde ouvert. Un client peut utiliser ces signaux pour regrouper ou étiqueter les opérations, mais une annotation est une métadonnée descriptive. Elle n'oblige pas automatiquement le modèle ou le serveur à demander une confirmation.

La règle de confirmation est étroite. didit_session_delete supprime définitivement une session et ne nécessite que session_id. La suppression par lots limitée avec une liste d'identifiants explicite ne nécessite pas non plus de champ de confirmation. Le gestionnaire d'une suppression générique rejette delete_all: true à moins que confirm: true ne soit également fourni, mais le schéma d'entrée actuel de suppression par lots annoncé omet confirm. Considérez cela comme un filet de sécurité côté gestionnaire avec un manque de schéma, et non comme un flux d'approbation complet visible par le client. Les équipes devraient ajouter leur propre politique d'approbation humaine pour les écritures importantes au lieu de supposer qu'une annotation en impose une.

Les sorties connues contenant des informations d'identification sont traitées délibérément : les champs d'informations d'identification d'application et les métadonnées de secret de signature de webhook sont expurgés, tandis que les charges utiles d'erreur sont profondément nettoyées avant d'être renvoyées au client. Ce n'est pas une promesse que chaque champ de chaque réponse commerciale réussie est globalement supprimé, de sorte que les équipes devraient toujours minimiser les données personnelles qu'elles demandent à Claude de récupérer. L'opération de révélation d'informations d'identification n'existe que dans le catalogue local/stdio complet, nécessite sa propre confirmation et est exclue du catalogue OAuth hébergé de 115 outils. L'opération de recharge de crédit est également exclue de ce catalogue hébergé.

Ce modèle en couches est préférable à l'utilisation d'une invite système qui dit simplement à un agent « d'être prudent », mais ses limites doivent être énoncées précisément. Les rôles backend, la validation des entrées, la rédaction ciblée, la désinfection des erreurs et la vérification du gestionnaire de suppression générique sont des mesures d'application. Les annotations de risque et les instructions de chat informent le comportement, et le manque de schéma actuel de confirmation générique doit figurer sur la liste de contrôle d'un évaluateur.

Comment évaluer un serveur MCP pour le travail d'identité

Avant de connecter un service d'identité ou de fraude à Claude, vérifiez les points suivants :

• Transport : Existe-t-il un point de terminaison distant documenté utilisant un transport MCP actuel ?
• Authentification : L'accès représente-t-il un utilisateur via OAuth, ou dépend-il d'une information d'identification largement privilégiée copiée dans la configuration ?
• Autorisation : Les rôles d'organisation sont-ils appliqués par le backend à chaque appel ?
• Schémas : Les outils définissent-ils des entrées contraintes, des actions autorisées et des erreurs utiles ?
• Métadonnées de risque : Le client peut-il distinguer les lectures, les écritures, les opérations destructrices et les appels qui affectent les systèmes externes ?
• Gestion des données : Les secrets et les données personnelles inutiles sont-ils expurgés des résultats des outils et des erreurs ?
• Limites : Le fournisseur indique-t-il ce que le modèle ne peut pas faire et où un examen humain de la conformité reste requis ?
• Inspectabilité : Votre équipe peut-elle examiner la source et une référence d'outil maintenue ?

Didit publie son implémentation dans le référentiel GitHub public sous licence MIT et documente l'architecture dans l'aperçu MCP et le guide d'authentification. La base de code v5 est marquée comme privée pour la publication de packages et n'est pas distribuée via npm. Pour Claude, le chemin prévu est le point de terminaison hébergé et son flux d'autorisation basé sur le navigateur.

Quand le connecteur Claude est un bon choix

Le connecteur est le plus puissant lorsqu'un humain souhaite que Claude enquête, coordonne ou exécute des opérations limitées dans un espace de travail Didit existant : examiner les décisions récentes, créer un lien de vérification hébergé, exécuter des contrôles non liés à l'image, inspecter une file d'attente de cas, comparer les flux de travail ou résumer l'activité entre les applications. Il est également utile pour les développeurs qui explorent les schémas avant d'implémenter une intégration backend. Les vérifications d'images autonomes nécessitent l'accès aux fichiers côté serveur décrit ci-dessus.

Il ne remplace pas le code de production déterministe où votre application doit déclencher la même opération à chaque requête sans utilisateur conversationnel. Dans ce cas, utilisez les API REST (Representational State Transfer) et les kits de développement logiciel de Didit. MCP et REST servent des appelants différents : l'un délègue le travail d'une personne connectée à un client IA ; l'autre connecte la logique d'application directement au service.

Les aspects économiques sont les mêmes, quelle que soit l'interface qui initie une vérification. Le serveur MCP lui-même est gratuit. Un forfait KYC complet — vérification de document d'identité, vivacité passive, correspondance faciale et analyse d'adresse IP — est de 0,33 $. Chaque fonctionnalité comprend 500 vérifications gratuites par mois. Didit prend en charge plus de 2 000 entreprises en production dans plus de 220 pays et territoires, plus de 14 000 types de documents et plus de 48 langues.

Connecter Didit à Claude

Si le modèle d'autorisation et de sécurité correspond à votre cas d'utilisation, ajoutez le connecteur personnalisé Didit à Claude. Le connecteur pointe vers le point de terminaison HTTP Streamable hébergé et lance le flux de connexion Didit.

Pour les étapes exactes de Claude Desktop et Claude Code, utilisez le guide d'installation dédié. Pour le contexte du produit et d'autres exemples, visitez la page développeur Didit MCP.

Le verdict concis est le suivant : un serveur MCP de vérification d'identité vaut la peine d'être utilisé avec Claude lorsqu'il transforme les opérations d'identité et de fraude en actions typées et conscientes des permissions sans affaiblir les contrôles qui les entourent. Le nombre d'outils rend la connexion utile ; OAuth, l'application des rôles, la rédaction, les schémas précis et les vérifications de suppression générique étroitement appliquées rendent son modèle de risque inspectable.