Tester les outils MCP avec de faux identifiants qui échouent sans danger

Tester des outils MCP en toute sécurité demande plus que de remplacer un jeton de production par une chaîne appelée TEST_TOKEN. Un outil peut analyser la fausse valeur, renvoyer un message de réussite bien formulé, puis échouer dès qu’un agent rencontre une vraie limite d’autorisation, un refus d’approbation, un fournisseur lent ou une écriture partiellement terminée.

L’environnement de test doit vous permettre de prouver deux choses à la fois : l’outil envoie la requête attendue et il ne peut pas provoquer de conséquence réelle en production si le test tourne mal. Les comptes jetables et les faux identifiants répondent à des besoins différents. Traitez-les comme deux contrôles distincts.

Les faux identifiants testent l’analyse, pas l’autorité

Un faux identifiant prouve seulement que l’outil traite correctement une valeur ayant le bon format. Il ne prouve pas que le fournisseur accepte l’identifiant, que celui-ci possède les autorisations prévues ou qu’une valeur révoquée échoue proprement.

Cette distinction est souvent brouillée, car de nombreuses équipes appellent « faux secret » tout secret qui n’est pas utilisé en production. Il existe pourtant trois cas très différents :

• Une chaîne synthétique existe uniquement dans un stub local. Elle ne peut s’authentifier nulle part.
• Un identifiant de test s’authentifie auprès d’un vrai fournisseur, mais uniquement dans un tenant ou un projet jetable.
• Un identifiant de production restreint peut s’authentifier en production, même si ses autorisations semblent limitées.

La première option convient aux tests unitaires et aux tests de contrat. La deuxième convient aux tests d’intégration. La troisième n’a pas sa place dans une suite de tests automatisés d’agents. Un identifiant capable de lire la fiche d’un client en production a déjà franchi la limite que vous cherchiez à protéger.

Faites en sorte que les valeurs fictives ressemblent au format réellement reçu par votre code. Si un client API refuse les jetons sans préfixe ou plus courts qu’une certaine longueur, utilisez une valeur synthétique qui passe cette validation locale. Ne copiez pas un vrai jeton en modifiant un seul caractère. Les équipes collent des fixtures dans des outils de suivi, des transcriptions de terminal et des conversations. Un secret presque réel vous expose à tous les risques de manipulation sans apporter le moindre bénéfice de test.

Une fixture utile indique l’autorité qu’elle ne possède pas. Par exemple, stub_token_no_network est plus explicite que token123. Une référence d’identifiant de test comme billing_test_writer indique qu’un gestionnaire de secrets, et non l’agent, résout la valeur réelle. Gardez cette référence stable et faites tourner l’identifiant de test sous-jacent lorsque c’est nécessaire.

Ne confondez pas la réussite d’un mock avec une autorisation. Quand un stub renvoie 200, il a accepté le contrat que vous avez programmé. C’est une information utile sur la construction de votre requête. Elle ne dit rien du modèle d’autorisations du fournisseur.

Séparez les entrées invalides, les refus et les pannes opérationnelles

Un agent doit recevoir des indications différentes pour un argument incorrect, une action refusée et une dépendance défaillante. Si votre outil MCP transforme les trois cas en request failed, l’agent réessaiera des actions qu’il devrait arrêter et abandonnera des actions qu’il pourrait corriger.

Utilisez un vocabulaire restreint pour les résultats et conservez-le dans le résultat de l’outil. J’utilise cinq catégories :

• Erreur de validation : l’agent a fourni un argument invalide ou incomplet. Il peut corriger l’appel.
• Échec d’authentification : l’identifiant est absent, expiré, mal formé ou révoqué. Réessayer le même appel ne servira à rien.
• Refus d’autorisation : l’identité a été authentifiée, mais elle ne possède pas l’autorisation nécessaire, ou un humain a refusé une approbation. L’agent ne doit pas chercher à contourner la limite.
• Conflit : la requête est valide, mais ne peut pas s’appliquer à l’état actuel de la ressource. L’agent devra peut-être commencer par récupérer l’état courant.
• Échec opérationnel : délai d’attente, problème de connexion, limite de débit ou panne du fournisseur. Une nouvelle tentative peut être pertinente si l’action peut être répétée sans danger.

HTTP définit les éléments familiers de cette séparation. La RFC 9110 décrit 401 Unauthorized comme un défi d’authentification, malgré son nom historiquement trompeur, et 403 Forbidden comme un refus de traiter la requête. Votre fournisseur peut utiliser ces codes de manière imparfaite. Testez donc aussi le corps de la réponse et les codes d’erreur documentés. Ne fondez pas le comportement de l’agent sur le seul code d’état.

Le résultat d’un outil du Model Context Protocol prend en charge un indicateur isError en plus du contenu. Utilisez-le lorsque l’appel de l’outil a échoué, mais placez la catégorie exploitable dans le texte ou dans le contenu structuré attendu par votre client. Une erreur JSON-RPC au niveau du transport et une erreur au niveau de l’outil sont également deux choses différentes. Réservez les erreurs JSON-RPC aux requêtes de protocole mal formées ou aux méthodes indisponibles. Renvoyez un résultat normal de tools/call avec isError: true lorsque l’outil a été exécuté mais que l’action en amont a échoué ou a été refusée.

Cette forme de réponse donne à l’agent une information concrète sur laquelle agir :

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "authorization_rejected: identity billing_test_writer cannot create invoices in tenant test-acme. Request a role change or stop."
      }
    ],
    "isError": true
  }
}

N’incluez pas le bearer token, l’en-tête d’autorisation, la requête complète envoyée au fournisseur ni l’erreur brute du fournisseur dans ce résultat. Les messages d’erreur font partie du contexte de l’agent, ce qui signifie qu’ils peuvent être conservés par des systèmes que vous ne contrôlez pas. L’erreur doit contenir assez de détails pour orienter le comportement, pas un dump destiné à l’analyse forensique.

Les comptes jetables ont besoin d’une limite stricte

Un compte jetable n’est sûr que lorsqu’il n’existe aucun chemin vers les ressources de production. Une adresse e-mail distincte et une étiquette test ne suffisent pas à créer cette séparation.

Commencez par l’unité d’isolation la plus forte proposée par le fournisseur. Il peut s’agir d’une organisation, d’un tenant, d’un projet cloud, d’une base de données ou d’une instance auto-hébergée distincte. Placez le compte de test dans cette unité et vérifiez qu’il ne peut pas basculer vers une unité de production via un identifiant, un rôle partagé ou une valeur de configuration par défaut.

Accordez ensuite au compte les autorisations nécessaires au test prévu, et rien de plus. Si un outil crée des factures pendant les tests, son identité de test doit pouvoir créer et lister les factures de test. Elle n’a pas besoin d’autorisations d’export, d’un accès administrateur ni d’un accès à une configuration de paiement partagée. Les autorisations de test très larges sont populaires parce qu’elles accélèrent la configuration. Elles masquent aussi les permissions réellement nécessaires à l’outil.

Utilisez un marqueur d’exécution explicite pour chaque ressource créée par la suite. Placez-le dans un champ de métadonnées pris en charge, une description, une étiquette ou un nom. Un marqueur rend le nettoyage plus sûr et permet de reconnaître les artefacts de test qui ont fui. Ne supprimez pas tout ce qui se trouve par hasard dans un tenant de test. Un autre développeur peut y reproduire un bug.

Une configuration minimale peut ressembler à ceci :

run_id: mcp-it-20250308-7f3c
account: [email protected]
allowed_tenant: test-acme
resource_prefix: mcp-it-20250308-7f3c-
cleanup_after_minutes: 90

Cette configuration évite une panne banale mais coûteuse : un exécuteur de tests pointe vers le mauvais tenant parce qu’une variable d’environnement issue du shell d’un développeur prend le dessus sur la configuration contrôlée. Votre code d’initialisation doit récupérer l’identité du tenant courant avant de créer quoi que ce soit et la comparer à allowed_tenant. Si les valeurs diffèrent, arrêtez-vous avant la première écriture.

Jetable ne signifie ni anonyme ni sans responsable. Désignez un propriétaire, notez comment l’identifiant est émis et rendez son expiration volontaire. Une identité de test oubliée reste une identité disposant d’un accès.

Construisez des contrats autour des requêtes observables

Un bon test de contrat vérifie la requête envoyée par l’outil, le résultat renvoyé et les informations qu’il refuse d’exposer. Il ne se contente pas de vérifier qu’une fonction a été appelée.

Placez un stub HTTP local devant votre client et demandez-lui d’inspecter la méthode, le chemin, les en-têtes, les paramètres de requête et le corps. Le stub doit refuser les champs inattendus. Les mocks permissifs apprennent à un outil à envoyer des arguments accidentels jusqu’à ce qu’un vrai fournisseur les refuse.

Pour un outil create_invoice, un test ciblé peut envoyer cet appel :

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "create_invoice",
    "arguments": {
      "tenant": "test-acme",
      "customer_id": "cus_mcp_it_7f3c",
      "amount_cents": 500,
      "currency": "USD"
    }
  }
}

Le stub doit attendre POST /v1/invoices, confirmer que l’en-tête d’autorisation contient sa valeur de test synthétique et vérifier que la requête comprend le marqueur d’exécution. Il peut renvoyer un identifiant fixe comme inv_mcp_it_001. Le résultat MCP doit exposer l’identifiant et l’état de la facture, mais ne jamais renvoyer l’en-tête d’autorisation.

Écrivez au moins une assertion de contrat négative pour chaque champ sensible d’une requête. Envoyez un champ authorization, base_url, account_id ou tenant fourni par l’appelant si votre schéma pourrait en accepter un. Vérifiez que l’outil refuse ou ignore les valeurs susceptibles de rediriger une action vers un autre compte. De nombreuses fuites d’identifiants commencent par une échappatoire apparemment inoffensive destinée à accepter un point de terminaison personnalisé.

Testez la sérialisation de la requête au niveau des octets importants. Un fournisseur peut distinguer les champs omis de null, les chaînes vides des valeurs absentes et les nombres des chaînes numériques. Les agents produisent des formes d’arguments inattendues, surtout lorsque la description de l’outil ne précise pas les unités. Votre schéma doit indiquer amount_cents, et non amount, si le fournisseur attend des unités mineures.

Les tests de contrat sont aussi l’endroit où vous imposez une hygiène des journaux. Capturez l’événement de journal structuré et vérifiez qu’il contient une référence d’identifiant ou un marqueur masqué, jamais le secret synthétique lui-même. Un faux secret devient un vrai problème de divulgation dès que les ingénieurs prennent l’habitude de l’afficher partout.

Testez les autorisations avec une matrice, pas seulement le cas favorable

Une seule identité de test autorisée ne permet pas de savoir si un outil gère correctement les permissions. Il vous faut plusieurs identités aux droits volontairement différents et un ensemble de cas qui nomment le résultat attendu.

Gardez une matrice assez petite pour rester maintenable. Pour un outil d’écriture, ces cas valent généralement la peine d’être conservés :

Cette matrice détecte un défaut fréquent : l’outil vérifie qu’un jeton existe, mais jamais à quel tenant il correspond réellement. Le cas favorable réussit parce que le rédacteur dispose d’un accès large. L’échec apparaît lorsqu’un agent reçoit un identifiant de tenant dans une tâche et que le client l’accepte sans le lier à l’identifiant sélectionné.

Exécutez chaque cas de la matrice auprès du véritable fournisseur jetable lorsque c’est possible. Le comportement du fournisseur concernant les rôles hérités, les autorisations par défaut et la révocation différée diffère souvent de la documentation. Isolez les cas. Si un test élargit un rôle qu’un autre test s’attend à voir absent, les exécutions parallèles créent des erreurs qui ressemblent à des bugs d’autorisation.

Ne fabriquez pas uniquement des réponses interdites dans un stub en considérant la suite comme terminée. Un stub confirme que votre convertisseur d’erreurs reconnaît un 403. La véritable identité de test confirme que l’émission de l’identifiant, la configuration du fournisseur et le routage de l’outil produisent un refus authentique.

Il existe une exception utile : tester des réponses du fournisseur qu’il est impossible de déclencher de manière fiable, comme un JSON mal formé ou un type de contenu invalide. Un stub prend en charge ces cas. L’objectif n’est pas la pureté. Il s’agit de savoir quelles preuves chaque test fournit.

Les écritures ont besoin d’un plan de nettoyage avant le code de test

Pour chaque outil qui modifie l’état, décidez comment le test supprimera ou neutralisera cet état avant d’écrire le test de réussite. Si vous ne pouvez pas décrire le nettoyage, choisissez une autre cible ou une autre opération.

Privilégiez les opérations qui créent des enregistrements dans un projet de test à courte durée de vie. Évitez les appels de test qui envoient un e-mail, débitent une carte, font tourner un secret partagé, déclenchent un déploiement ou contactent un tiers réel. Le sandbox d’un fournisseur peut malgré tout envoyer des webhooks à un point de terminaison configuré il y a plusieurs années. Vérifiez les effets environnants, pas seulement l’étiquette de l’API.

Utilisez un marqueur d’exécution unique et nettoyez dans un bloc finally ou son équivalent. Le nettoyage doit tolérer une ressource qui n’a jamais été créée, une ressource créée deux fois après une nouvelle tentative et un compte partiellement configuré. Un nettoyage idempotent fait gagner du temps lorsqu’un test échoue au milieu du provisionnement.

Voici un échec qui mérite d’être testé. L’outil envoie une requête de création. Le fournisseur crée l’enregistrement, mais la connexion est interrompue avant le renvoi de la réponse. L’agent voit un échec opérationnel et réessaie. Sans valeur d’idempotence, la nouvelle tentative crée un doublon. Sans marqueur d’exécution, le nettoyage ne peut pas retrouver les deux enregistrements en toute sécurité.

Donnez à la requête de création une valeur d’idempotence dérivée de l’identifiant d’exécution et de l’action logique, et non de la tentative de transport. La première tentative et la nouvelle tentative doivent utiliser la même valeur. Testez ensuite le cas de réponse interrompue avec un stub qui enregistre la première requête, ferme la connexion et renvoie une réussite lorsqu’il reçoit à nouveau la même valeur d’idempotence. Vérifiez que le fournisseur ne contient qu’un seul enregistrement.

Si le fournisseur ne prend pas en charge l’idempotence, faites effectuer par l’outil une recherche fondée sur une référence externe unique avant de réessayer une écriture. Cette approche peut subir une course en cas d’exécution concurrente. Documentez donc le risque restant. Ne relancez pas silencieusement un transfert d’argent ou une écriture irréversible parce qu’un client HTTP générique considère POST comme réessayable.

Les délais d’attente et les limites de débit révèlent les mauvais comportements des agents

Un outil qui gère correctement les réussites et les 403 peut tout de même causer des dégâts lorsque sa dépendance ralentit. Les agents ont tendance à réessayer parce qu’ils cherchent à terminer la tâche. Votre outil doit leur fournir une réponse limitée et fidèle.

Testez un délai d’attente de connexion avant que la moindre requête n’atteigne le serveur, un délai d’attente de réponse après réception de la requête par le serveur et une réponse 429 du fournisseur. Ces cas sont différents. Le premier signifie généralement qu’aucun effet secondaire ne s’est produit. Le deuxième peut signifier que le serveur a terminé l’écriture. Un 429 peut contenir une instruction de nouvelle tentative, mais utilisez-la uniquement si le fournisseur documente ce champ et si votre outil en préserve le sens.

Définissez des délais de test courts pour que la suite reste utilisable, mais ne remplacez pas les délais de production par des valeurs de test dans le code. Injectez une horloge ou une configuration de transport. Un délai de deux secondes inscrit en dur est une commodité de test qui deviendra une panne lorsque quelqu’un le déploiera.

Vos assertions doivent couvrir le comportement visible par l’agent autant que celui du client HTTP. Pour une limite de débit, renvoyez un échec opérationnel qui nomme le fournisseur et indique si une nouvelle tentative après un délai est autorisée. Pour un délai d’attente de réponse après une écriture, indiquez que le résultat est inconnu et demandez à l’appelant de rechercher l’opération avec sa valeur d’idempotence ou sa référence externe. Appeler ce cas un simple échec invite à créer des doublons.

Ne testez pas les nouvelles tentatives en vérifiant uniquement un compteur. Notez si la nouvelle tentative a réutilisé la valeur d’idempotence, si elle a attendu lorsque c’était nécessaire et si elle s’est arrêtée après la limite configurée. Une boucle de nouvelles tentatives qui finit par s’arrêter peut tout de même créer une rafale saturant un petit tenant de test et masquant le véritable défaut.

Un refus d’approbation doit laisser la cible intacte

Si un humain peut approuver les actions d’un agent, testez le chemin du refus sur un point de terminaison où un effet secondaire serait évident. Un écran indiquant « refusé » ne prouve pas que la couche d’exécution s’est arrêtée.

Configurez une cible jetable avec un compteur, un enregistrement marqueur ou une liste d’événements de test en ajout uniquement. Démarrez le processus de l’agent, envoyez l’appel d’outil et refusez la session ou l’appel. Interrogez ensuite directement la cible avec une identité d’observation de test distincte. Le nombre attendu ne doit pas avoir changé.

Ce test détecte un bug d’ordre des opérations : l’outil commence la requête vers le service en amont, puis demande une approbation pendant qu’il attend la réponse. Ce flux peut sembler correct lors d’une démonstration si le fournisseur est lent. Il contredit pourtant l’objectif de l’approbation. La décision d’autorisation doit intervenir avant que le répartiteur d’actions ouvre la connexion réseau ou démarre un assistant SSH.

Testez séparément un nouveau processus d’agent et un deuxième appel dans le même processus. Il s’agit de garanties de sécurité distinctes pour les systèmes qui accordent l’autorisation par exécution. Testez aussi un processus dont l’identité de signature diffère de celle attendue. L’invite d’approbation doit afficher assez d’informations sur l’origine pour permettre à la personne qui approuve de distinguer l’agent prévu d’un processus local arbitraire.

Pour un flux de travail Mac local, Sallyport conserve les identifiants API et SSH dans son coffre chiffré et peut exiger une approbation à chaque nouvelle exécution d’agent ou à chaque utilisation d’un identifiant sélectionné. Testez ces contrôles sur des points de terminaison jetables, plutôt que de les considérer comme une raison d’ignorer les tests d’autorisations en amont.

Les tests SSH ont besoin d’une cible que l’on peut jeter

SSH ajoute des modes d’échec que les exemples HTTP masquent : vérification de l’hôte, protection contre l’injection dans les commandes, héritage de l’environnement, comportement du shell distant et fichiers laissés après une connexion interrompue. Ne dirigez jamais les tests SSH automatisés d’un agent vers le poste de travail d’un développeur ou un hôte d’administration partagé.

Créez une machine de test contrôlée ou une machine virtuelle à courte durée de vie avec un compte dédié. Donnez à ce compte un répertoire personnel sans données utiles, un ensemble de commandes restreint lorsque c’est possible et aucun identifiant permettant d’atteindre d’autres systèmes. Utilisez une clé SSH de test dédiée et détruisez-la lorsque l’environnement expire.

Exercez les arguments de commande qui font échouer les constructions naïves de shell. Testez les espaces, les guillemets, les caractères de nouvelle ligne, les chemins commençant par un tiret et les données ressemblant à une syntaxe shell. L’outil doit transmettre les arguments à la commande distante sans concaténer les valeurs fournies par l’utilisateur dans une chaîne shell. Si l’interface distante requise n’accepte que du texte shell, limitez la grammaire autorisée et refusez tout ce qui en sort.

Un test sûr peut demander à la cible de créer un fichier portant le marqueur d’exécution, puis de lire exactement ce fichier. Un test de refus peut demander un chemin situé hors du répertoire autorisé du compte de test et attendre que la cible le refuse. Un test opérationnel peut interrompre la connexion SSH après le démarrage de la commande, puis vérifier si le processus distant a continué.

Collectez le code de sortie, ainsi qu’une sortie standard et une sortie d’erreur standard limitées. Ne renvoyez pas une sortie de commande illimitée à un agent. Les sorties volumineuses consomment du contexte et les commandes contiennent souvent des valeurs de configuration qui n’étaient pas destinées à quitter l’hôte.

Les preuves d’audit doivent relier l’appel de l’agent à l’effet secondaire

Lorsqu’un test d’agent échoue, vous devez savoir si l’outil a effectué l’appel, si le fournisseur l’a reçu et si le nettoyage l’a supprimé. Un amas de texte dans la console ne répond pas à ces questions de manière fiable.

Donnez à chaque exécution de test un identifiant et faites-le circuler dans la requête MCP, le journal de l’outil, les métadonnées du fournisseur et le journal de nettoyage. Ne placez pas d’identifiants dans cette valeur. Une preuve utile comprend le nom de l’outil, la catégorie d’action, la référence d’identifiant, le tenant cible, l’identifiant de corrélation de la requête, la catégorie de résultat et l’identifiant de ressource renvoyé.

Conservez les enregistrements de session de l’agent séparément des enregistrements d’action. Une session indique quel processus a effectué une exécution et quand vous l’avez révoquée. Un enregistrement d’action indique quel appel externe a eu lieu. Les relier par un identifiant de corrélation rend un test de refus vérifiable : vous pouvez montrer que l’agent a tenté une action, que l’autorisation l’a refusée et qu’aucun enregistrement d’action externe correspondant n’existe.

Les preuves de falsification comptent lorsque vous utilisez les résultats de test pour examiner une nouvelle limite d’outil. Sallyport construit ses journaux de sessions et d’activité à partir d’un journal d’audit chiffré et chaîné par hachage, et sp audit verify peut vérifier cette chaîne hors ligne sans clé de coffre. Cela ne remplace pas les journaux du fournisseur, mais donne aux tests locaux un moyen de détecter une modification de l’historique des actions.

Ne traitez pas les sorties d’audit comme un réservoir de secrets. Enregistrez des références d’identifiants et des attributs masqués, puis vérifiez ces règles dans les tests. La piste d’audit doit vous aider à reconstituer une action sans devenir l’endroit le plus facile pour voler l’accès qui l’a rendue possible.

Un candidat à la publication gagne lentement l’accès à la production

Un outil doit progresser à travers des limites de plus en plus réalistes : stubs synthétiques locaux, véritable fournisseur jetable, identités refusées et expirées, injection de pannes et test d’approbation humaine si le flux de travail en utilise une. Passer directement à la production parce que le sandbox est différent est la meilleure façon de découvrir le comportement de sécurité sous pression.

Conservez une courte suite de publication exécutée à chaque modification et une suite plus approfondie qui provisionne moins souvent des ressources jetables. La courte suite doit couvrir le schéma de l’outil, la construction des requêtes, le masquage et les échecs représentatifs. La suite approfondie doit couvrir les autorisations réelles, le nettoyage du cycle de vie, la révocation et l’isolation de la cible.

Avant d’autoriser une nouvelle action en production, examinez les preuves d’un appel volontairement refusé et d’un délai d’attente volontairement ambigu lors d’une écriture. Ces cas montrent si l’outil respecte une limite et s’il dit la vérité à l’agent lorsque le fournisseur a peut-être agi. Les parcours de réussite sont faciles à préparer. Ce sont les parcours de refus et d’incertitude qui rendent l’accès à la production maîtrisé ou imprudent.