28 400 euros : c’est le total des remboursements qu’un des cinq marchands audités a laissé transiter par un agent IA en un mois, sans qu’aucun plafond technique ne vienne encadrer ces opérations. L’audit portait sur cinq boutiques WooCommerce ayant connecté un serveur MCP à leur compte Stripe pour automatiser le service après-vente : gestion des remboursements, des litiges et des changements d’abonnement.
L’idée de départ, chez ces marchands, était séduisante : un agent qui lit un ticket de support, comprend la demande de remboursement, vérifie la commande correspondante et déclenche l’opération Stripe sans attendre qu’un humain se libère. Sur le papier, cela réduit le délai de traitement de plusieurs jours à quelques minutes. Dans les faits, l’audit a révélé que trois boutiques sur cinq n’imposaient aucune limite de montant à ces outils.
Ce que l’audit a trouvé
Le point commun aux trois boutiques à risque : l’outil MCP exposé au serveur, du type refund_order, acceptait n’importe quel montant transmis par l’agent, sans validation autre que l’existence de la commande. Un incident réel a été identifié chez l’un des marchands : une confusion de contexte entre deux commandes similaires a conduit l’agent à rembourser 4 200 euros au lieu des 42 euros demandés par le client, une erreur de virgule dans le raisonnement du modèle qui n’a été bloquée par rien côté serveur.
Pourquoi la limite doit être côté outil, pas côté prompt
Les deux boutiques restées prudentes avaient toutes les deux fait le même choix : ne jamais faire confiance aux instructions du prompt système pour encadrer un montant. Demander à l’agent de « ne jamais rembourser plus de 100 euros sans validation » dans son prompt est une invite, pas une garantie — un prompt peut être contourné, mal interprété, ou simplement ignoré par un modèle qui privilégie une autre partie de son contexte. La limite doit vivre dans le code de l’outil MCP lui-même, avant tout appel à l’API Stripe.
Le correctif appliqué
Sur les trois boutiques concernées, la fonction exposée par le serveur MCP a été modifiée pour rejeter systématiquement tout remboursement dépassant un plafond défini par configuration, avec passage en validation humaine au-delà :
- Plafond automatique fixé à 150 euros par opération, ajustable par boutique
- Au-delà du plafond, l’outil renvoie une erreur explicite invitant à une validation manuelle
- Journalisation systématique de chaque tentative de remboursement, acceptée ou refusée
Le résultat, un mois après correction
Aucune régression n’a été observée sur les remboursements légitimes, la majorité des demandes de service après-vente restant sous le seuil des 150 euros. Les cas dépassant le plafond, environ 8 % des demandes selon les journaux consultés, remontent désormais vers une file d’attente humaine plutôt que d’être exécutés automatiquement.
Ce que cela dit des intégrations MCP en général
Cet audit a un mérite : il rend visible un biais fréquent dans la conception des serveurs MCP connectés à des services de paiement. On pense les outils comme des capacités techniques (« cet outil peut rembourser ») sans toujours poser la question du montant maximal acceptable, parce que cette question ne se posait pas de la même façon avec une interface humaine où un opérateur applique naturellement du bon sens. Un agent n’a pas ce bon sens par défaut ; il faut le lui imposer techniquement.
Un outil MCP qui touche à de l’argent doit être conçu comme un distributeur automatique, pas comme un guichetier : des limites dures, pas des consignes orales.
Notre verdict
Sur les cinq boutiques auditées, aucune n’avait de mauvaise intention ni de négligence grossière : le plafond avait simplement été oublié au moment de coder l’outil, un point qui échappe facilement quand on se concentre sur le bon fonctionnement fonctionnel plutôt que sur les cas limites. La leçon à retenir pour tout serveur MCP connecté à Stripe : traiter le plafonnement des montants comme un prérequis de sécurité au même titre que l’authentification, jamais comme une option à ajouter plus tard.
