Ce que couvre cette check-list de sécurité des serveurs MCP, et ce qu’elle ne couvre pas

Un remboursement validé part en timeout alors que le système de paiement l’a déjà enregistré ; l’agent réessaie, et le client est remboursé deux fois. Cette check-list porte sur ces écritures et sur la passerelle MCP (gateway), le proxy ou le serveur d’actions qui les exécute pour l’agent.

Injection de prompt, empoisonnement d’outils, chaîne d’approvisionnement et durcissement des serveurs sont d’autres problèmes ; ces exigences limitent seulement ce qu’un agent manipulé ou dans l’erreur peut faire. Pour le durcissement et les attaques visant le protocole, commencez par les Security Best Practices du projet MCP et le guide de l’OWASP pour développer des serveurs MCP sécurisés.

Le guide des actions d’agents avec validation humaine via MCP explique comment concevoir cette couche. L’architecture de référence d’une plateforme IA d’entreprise construit les actions d’agents en dernier, une fois l’identité et le journal de décisions en place ; cette check-list vérifie qu’ils le sont.

Les six exigences en un coup d’œil

Exigence La question à poser Une bonne réponse
1. Validation exacte Qui valide, en voyant quoi ? Une personne, sur les paramètres définitifs, hors de portée de l’agent. Toute modification l’annule.
2. Classement des écritures Qui décide qu’un outil écrit ? Votre manifeste versionné, dans la passerelle. Outil inconnu, outil refusé.
3. Exécution unique Que fait un réessai ? Une validation, une clé d’idempotence, au plus une exécution.
4. Journal probant Que prouve le journal ? Des entrées en append-only, dans un stockage que personne ne peut réécrire.
5. Droits de l’utilisateur Quels droits porte l’appel ? Ceux de l’utilisateur, par token exchange. Aucun compte d’agent aux droits larges.
6. Comportement en panne Et si la validation tombe ? Les écritures s’arrêtent ; celles en attente ont un responsable.

1. Validation de l’action exacte, par une personne, hors de portée de l’agent

Valider, c’est voir l’appel exact et l’accepter : l’outil, l’enregistrement visé et chaque paramètre envoyé. Un résumé rédigé par le modèle (« mettre à jour les coordonnées bancaires du client ») n’en tient pas lieu.

La page Tools de la spécification MCP recommande (SHOULD) qu’un humain soit toujours dans la boucle, capable de refuser l’invocation d’un outil, et que les clients montrent les entrées avant l’appel. La présentation de la spécification ajoute que MCP ne peut pas imposer ses principes de sécurité au niveau du protocole. La validation relève donc de votre passerelle.

Trois détails comptent. La validation est liée aux paramètres (par exemple par une empreinte de l’outil, de la version du manifeste et des arguments), si bien que toute modification l’annule. La passerelle l’émet et la vérifie, dans un canal où l’agent ne peut pas écrire. Et le valideur voit le système visé et l’identité sous laquelle l’appel s’exécutera.

Pour les seuls systèmes d’IA à haut risque, l’article 14 du règlement européen sur l’IA (AI Act) demande que les personnes chargées du contrôle puissent ignorer ou remplacer une sortie, interrompre le système, et restent conscientes du biais d’automatisation. La plupart des agents d’entreprise n’entrent pas automatiquement dans cette catégorie ; un valideur qui clique sans lire n’assure pas pour autant ce contrôle.

À tester : validez une écriture, modifiez un paramètre, soumettez à nouveau. L’appel doit être refusé.

2. C’est la passerelle qui décide ce qui est une écriture, pas les étiquettes du serveur

Un serveur MCP peut décrire ses outils avec des annotations comme readOnlyHint et destructiveHint. Elles servent l’interface, pas le contrôle. La page Tools impose (MUST) aux clients de les considérer comme non fiables, sauf si elles viennent de serveurs de confiance, et la référence du schéma les qualifie d’indications pas forcément fidèles. Rien dans le protocole n’empêche un serveur de marquer une suppression en lecture seule.

Le classement appartient à la passerelle : un manifeste versionné par outil, relu chez vous, qui dit si l’outil écrit et quels contrôles s’appliquent. Je le ferais même pour vos propres serveurs : celui qui exécute une écriture ne devrait pas être celui qui la déclare inoffensive.

Refusez tout outil absent du manifeste. La liste des outils peut changer : un outil nouveau ou modifié reste bloqué jusqu’à son reclassement.

À tester : marquez un outil d’écriture en lecture seule. Il doit toujours exiger une validation.

3. Un réessai ou un double clic ne doit s’exécuter qu’une fois

Une écriture validée peut s’exécuter deux fois. L’API en aval applique l’écriture mais la réponse se perd dans un timeout ; l’agent repropose ; le valideur double-clique. Un remboursement en devient deux.

Les requêtes idempotentes de Stripe sont un bon modèle public, pas une norme. Stripe enregistre le code de statut et le corps de la première requête portant une Idempotency-Key donnée, succès ou échec, les renvoie aux répétitions et renvoie une erreur si les paramètres diffèrent. Les anciennes clés sont purgées ; réutilisée après purge, une clé lance une nouvelle requête.

Dans une passerelle d’agents, la clé appartient à la validation, pas à la tentative : une validation, une clé, au plus une exécution. Conservez les clés au moins aussi longtemps qu’une validation reste en vigueur, sinon la purge rouvre la brèche. Une nouvelle proposition, elle, reçoit une nouvelle validation et une nouvelle clé : seule une précondition l’arrête, c’est-à-dire l’état que l’action suppose (« la facture est toujours impayée »), vérifié à l’exécution.

Une passerelle ne rend pas idempotente une API en aval. Si la cible n’accepte pas de clé, la passerelle doit relire son état avant de réessayer, et certains timeouts exigeront l’intervention d’une personne.

À tester : envoyez deux fois le même appel validé, puis une fois avec un paramètre modifié, puis faites reproposer l’action par l’agent. Résultat attendu : une exécution et deux refus.

4. Un journal d’audit capable de prouver ce qui s’est passé

Un journal ne prouve quelque chose que s’il permet de reconstituer la décision et que personne n’a pu le modifier depuis. Enregistrez chaque proposition, validation, refus et exécution : auteur, outil et version du manifeste, entrées telles qu’exécutées, contrôles effectués, valideur et ce qu’il a vu, identité utilisée, résultat.

Une table en append-only qu’un administrateur peut vider n’est qu’une convention : exportez le journal vers un stockage à écriture unique. Sur AWS, en mode conformité (compliance) de S3 Object Lock, aucun utilisateur, pas même l’utilisateur root, ne peut écraser ou supprimer une version d’objet verrouillée, changer son mode de conservation ou raccourcir sa durée. Le mode gouvernance cède devant quiconque détient s3:BypassGovernanceRetention. AWS dit qu’Object Lock peut aider à respecter des exigences WORM, pas qu’il rend un journal conforme.

Ce verrou se heurte à l’effacement. En mode conformité, la durée de conservation ne peut pas être raccourcie, et les paramètres d’une écriture sont souvent des données personnelles, comme les coordonnées bancaires plus haut. Quand la conception le permet, l’export verrouillé doit contenir des références et des empreintes, pas de données personnelles en clair. Réglez la conservation et l’effacement avec votre délégué à la protection des données (DPO) avant de verrouiller quoi que ce soit.

À tester : rejouez une écriture validée depuis le journal, puis demandez qui peut supprimer cet enregistrement.

5. L’appel porte les droits de l’utilisateur, pas ceux de l’agent

Le système de référence doit voir la personne pour qui l’agent agit, et appliquer ses droits. L’entrée de l’OWASP sur l’Excessive Agency range les permissions excessives parmi les causes profondes et recommande d’agir en aval dans le contexte de l’utilisateur concerné, l’autorisation étant appliquée par ce système, pas par le modèle.

L’autorisation est facultative (OPTIONAL) dans MCP : demandez d’abord s’il y en a une. Sur HTTP, un serveur ne doit accepter que les jetons émis pour lui (spécification Authorization) et ne doit pas transmettre le jeton reçu aux API qu’il appelle (considérations de sécurité). L’autre raccourci, un compte de service assez large pour tous, est pire : l’agent pourrait faire ce qu’aucun utilisateur ne peut faire.

Le mécanisme standard est l’OAuth 2.0 Token Exchange. La passerelle présente le jeton de l’utilisateur comme subject_token, éventuellement le sien comme actor_token, et reçoit un jeton pour le système cible. En délégation, le claim act désigne alors la passerelle comme partie agissante, si votre fournisseur d’identité l’émet : la cible applique les droits de l’utilisateur et journalise qui a agi pour lui.

À tester : faites demander un remboursement à l’agent par quelqu’un qui n’a pas ce droit. Le système cible doit refuser.

6. Que se passe-t-il quand la validation ou la passerelle tombe ?

La passerelle doit bloquer par défaut (fail closed). Si la validation, les contrôles de politique ou le stockage du journal sont indisponibles, les écritures s’arrêtent et l’agent sait pourquoi. Une passerelle qui écrit ce qu’elle ne peut pas journaliser a rendu le journal facultatif.

Les valideurs aussi s’absentent. Une validation doit expirer, car celle du matin porte sur l’état du matin, et les écritures en attente ont besoin d’une file avec un responsable nommé. Un délai dépassé ne vaut jamais validation.

Tout cela a un coût. La passerelle est un service de plus à exploiter, avec un responsable, et sa panne arrête les écritures de tous les agents. Valider chaque écriture limite aussi le débit : relâchez la règle outil par outil, là seulement où le manifeste classe le risque comme faible (une note interne sur un ticket, par exemple), par une modification relue du manifeste. Je ne la relâcherais pas agent par agent : un « agent de confiance » ne se teste pas.

À tester : arrêtez le service de validation et demandez à l’agent d’écrire. Rien ne doit s’exécuter.

Quelles passerelles le font ?

Je ne compare pas de produits : les fonctionnalités évoluent trop vite. Demandez au fournisseur de montrer une écriture validée, puis réessayée, puis rejouée depuis le journal. Si l’une des trois tient sur une diapositive plutôt que dans une démo, vous n’avez pas le contrôle.

Compromis et limites

Valider chaque écriture est lent par conception, et convient mal à l’automatisation à fort volume et à faible risque.

Une passerelle qui réussit tous ces tests peut encore relayer une instruction empoisonnée. Le valideur est alors le dernier contrôle humain, et les droits de l’utilisateur bornent encore les dégâts.

Le token exchange suppose un fournisseur d’identité qui le prend en charge et des cibles qui acceptent le jeton obtenu ; un système ancien, accessible via un seul compte de service partagé, ne peut pas appliquer les droits de l’utilisateur, et la passerelle doit le faire à sa place, ce qui est plus faible. Un agent planifié, sans utilisateur derrière lui, a besoin de sa propre identité, étroite : c’est là que reviennent les agents dotés de privilèges propres.

Questions fréquentes

Les appels d’outils MCP doivent-ils être validés par un humain ?

La spécification MCP recommande (SHOULD) qu’un humain soit toujours dans la boucle, capable de refuser l’invocation d’un outil. C’est une recommandation que le protocole ne peut pas imposer. Pour les outils qui écrivent, j’exigerais la validation des paramètres exacts, appliquée par la passerelle et non par l’agent.

Peut-on se fier aux annotations d’outils MCP comme readOnlyHint ?

Pas comme contrôle. La spécification impose aux clients de considérer les annotations comme non fiables sauf si elles viennent d’un serveur de confiance, et les qualifie d’indications pas forcément fidèles. Tenez votre propre classement versionné de chaque outil dans la passerelle, et refusez ceux qu’il ne connaît pas.

Comment empêcher un agent de faire plus que ce que l’utilisateur a le droit de faire ?

Faites porter à chaque appel en aval les droits de l’utilisateur : échangez son jeton contre un jeton émis pour le système cible (OAuth 2.0 Token Exchange), ne retransmettez jamais celui reçu par la passerelle, et ne donnez à l’agent aucun compte de service aux droits larges. La cible refuse alors ce que l’utilisateur ne pourrait pas faire.

Que doit journaliser une passerelle MCP ?

Chaque proposition, validation, refus et exécution : l’auteur, l’outil et la version du manifeste, les entrées, les contrôles effectués, le valideur et ce qu’il a vu, l’identité utilisée et le résultat. Gardez le journal en append-only, et exportez des références et des empreintes plutôt que des données personnelles en clair, une fois la conservation et l’effacement arrêtés avec votre DPO.

Quelles passerelles MCP permettent une validation humaine avant les écritures ?

Je ne classe pas les produits : le marché change plus vite que n’importe quelle liste. Demandez à chaque fournisseur de montrer une écriture validée, réessayée et rejouée depuis le journal, puis un paramètre modifié après validation, puis le service de validation arrêté. Considérez comme absent ce qu’il ne sait pas démontrer.

En pratique

Sur la plateforme d’ENSO, j’ai spécifié des actions d’agents via un serveur d’actions MCP unique avec des manifestes d’outils versionnés, une validation humaine de chaque écriture, des contrôles d’idempotence et de préconditions, et un journal de décisions en append-only qui rend chaque décision de l’IA rejouable, avec un export WORM vers S3 Object Lock. L’IA hérite des droits de l’utilisateur via OAuth2 Token Exchange (Keycloak, OIDC) et des identités de workload IRSA. L’architecture complète est dans l’étude de cas ENSO, et le service sur la page gouvernance des agents IA.

Sources