Sécurité et limites

Comment le serveur MCP de Certivant classe les données personnelles, enveloppe le texte contrôlé par le demandeur dans une enveloppe non fiable, limite les rappels à 24 heures, et partage votre limite de 120 requêtes par minute et par locataire — ainsi que la lacune d'audit que vous ne devez pas masquer.

Le serveur MCP fournit des données de conformité à un modèle dont le contexte contient aussi du texte rédigé par un demandeur. Tout ce qui suit découle de la prise en compte sérieuse de ce fait.

Niveaux de données personnelles

Les réponses par défaut ont une forme de verdict : un statut, une décision, un score, les contrôles réussis. Elles ne reproduisent pas le dossier du demandeur.

Supprimées entièrement — valeurs sans utilité analytique pour un verdict : texte OCR brut (parsedData, texte extrait), données MRZ et codes-barres, empreintes faciales, et tout bloc image. list_verification_documents exclut structurellement le bloc OCR : il ne peut donc être obtenu à aucun réglage.
Masquées — valeurs dont l'agent doit savoir qu'elles existent sans les voir : date et lieu de naissance, numéros de document, de passeport ou de permis, et adresses courriel des destinataires dans les listes d'envois.
Sur demande explicite — include_pii: true sur get_verification_result et list_form_deliveries élargit la réponse. Cela exige la portée côté API REST, et l'accès est enregistré. Utilisez-le lorsque la personne qui pose la question a explicitement demandé les informations d'identité et y a droit, et non par défaut.

Le caviardage est structurel, et non fondé sur des expressions régulières appliquées au texte : le graphe d'objets est parcouru et les clés sont traitées selon leur nom, car les charges utiles de l'API REST sont les nôtres et leurs noms de champs sont stables.

L'enveloppe non fiable

Les noms des demandeurs, les notes en texte libre et surtout le texte OCR extrait d'un document envoyé sont contrôlés par un attaquant potentiel. Ils arrivent enveloppés dans une enveloppe étiquetée, avec un identifiant aléatoire propre à chaque appel : une charge utile ne peut donc pas forger le délimiteur de fermeture et s'échapper vers le canal des instructions. Les instructions propres au serveur indiquent clairement au modèle que le texte placé dans une enveloppe UNTRUSTED constitue des données dont il doit rendre compte, et non des instructions à suivre.

En complément de l'enveloppe, les charges utiles sont analysées par motifs, et tout texte qui ressemble à une instruction est signalé à l'agent sous forme d'avertissement explicite : tentatives de contourner les instructions précédentes, de diriger une décision de vérification, formulation impérative visant le modèle, ou réattribution de rôle. Le détecteur signale, il ne nettoie pas : un faux positif coûte une ligne d'avertissement, un faux négatif coûte l'approbation erronée d'un demandeur.

Si vous examinez un dossier et qu'un avertissement signale qu'un document contient un texte ressemblant à une instruction, c'est en soi un constat qui mérite d'être lu. Un passeport légitime ne demande pas à être approuvé.

L'envoi a des effets réels

Trois outils envoient de vrais courriels à des clients : send_form_to_customer, send_verification_reminder et renew_verification. Les trois sont annotés readOnlyHint: false et idempotentHint: false, afin qu'un hôte puisse demander confirmation avant de les déclencher. Les envois par lot sont limités à 50 lignes par appel.

Le délai entre deux rappels

send_verification_reminder est limité côté serveur. Un second rappel envoyé dans le délai minimal — 24 heures par défaut, configurable pour chaque déploiement — est refusé.

Un refus renvoie HTTP 429, et cela signifie qu'aucun envoi n'a eu lieu. Il s'agit d'une décision de politique, et non d'une contre-pression : ne réessayez pas, n'attendez pas puis ne retentez pas, et ne basculez pas vers send_form_to_customer (ce qui créerait un second demandeur et une seconde demande pour la même personne). La réponse indique à quel moment le prochain rappel sera autorisé. Attendez jusque-là.

Le compteur de délai couvre à la fois l'événement d'audit et la ligne d'envoi ; alterner entre le tableau de bord et l'API ne peut donc pas le réinitialiser.

Limites de débit

Le serveur MCP n'introduit aucun nouveau quota : il hérite de celui de l'API REST. Les points de terminaison KYC v1 qu'il appelle sont limités à 120 requêtes par minute, par locataire, partagées entre toutes les clés et tous les clients que votre organisation utilise.

C'est pourquoi le catalogue d'outils est conçu autour de la file plutôt que d'un enregistrement : un seul appel à get_todays_queue répond à ce que quarante appels à get_verification_status permettraient, et une boucle sur find_verification épuisera la fenêtre avant d'avoir terminé. Les invites fournies le précisent explicitement.

Pourquoi seulement 26 outils

Le catalogue est volontairement limité à environ cette taille. La précision de la sélection des outils se dégrade mesurablement lorsqu'un modèle doit choisir parmi trop d'options similaires ; une nouvelle capacité remplace ou regroupe donc les outils existants au lieu de s'y ajouter : un groupe qui grandit se replie derrière un seul outil orienté tâche, avec un argument de mode, plutôt que de livrer des outils frères. list_expiring_documents en est l'exemple type : documents et renewals sont deux questions, un seul outil. Les outils de vérification Live ID suivent la même règle : la liste et le détail forment un seul outil, et la reprogrammation, l'annulation et la nouvelle invitation forment un seul outil manage_live_verification avec un action.

Annotations fidèles

Chaque outil déclare ce qu'il fait réellement, afin que votre hôte encadre correctement au lieu de se fier à la prose :

Annotation	S'applique à
`readOnlyHint: true`	Les outils de file, de recherche, de dossiers bloqués, des modifications, du statut, du résultat, de l'explication, de la fiche d'entreprise, des indicateurs, des expirations, des métadonnées de documents, du lien de document et `list_live_verifications`.
`readOnlyHint: false`	Les trois outils d'envoi de courriels, ainsi que `start_verification`, `start_verifications_batch`, `submit_business_details`, `check_company_registry` (il effectue un appel externe facturable et peut marquer une fiche comme vérifiée), `resubmit_verification`, `schedule_live_verification` et `manage_live_verification` (les deux peuvent envoyer un courriel ou un SMS au demandeur).
`destructiveHint: true`	`resubmit_verification` (il supprime les contrôles et le score de risque de la demande, de sorte que le rejet ne peut plus être expliqué ensuite) et `manage_live_verification` (son action `cancel` est irréversible).

Lacunes connues

Les actions des agents figurent bien dans le journal d'audit KYC infalsifiable : chaque appel d'outil est écrit dans kyc_audit_log via POST /api/v1/kyc/audit avec la clé propre à l'appelant, dans le même journal chaîné par hachage que les actions humaines. La lacune ci-dessous est du type de celles que l'on découvrirait autrement en production.

Le raisonnement structuré des décisions manque pour la plupart des vérifications anciennes. explain_verification_decision renvoie reasoningAvailable: false lorsqu'aucun verdictMeta n'a été enregistré, ce qui couvre la majorité des demandes historiques. L'outil est honnête à ce sujet ; votre workflow doit l'être aussi.

Et une limitation reprise de la référence des outils : check_company_registry échoue actuellement face au registre en production avec un 401, parce que la clé OpenCorporates n'est pas transmise ; sa différence de correspondance des administrateurs n'est donc pas démontrée de bout en bout. Voir KYB.

Sécurité et limites

On this page