Aller au contenu
LUINLancer un projet

Playbook

Ne donnez pas les clés au serveur MCP.

Le modèle a remboursé le mauvais client. Ce que cela veut dire, pourquoi un chat avec des tools n’est pas un plugin, et dans quel ordre fermer la caisse.

Mis à jour Par LUINIngénierie IA · Sécurité

La finance a vu le remboursement en premier, un jeudi. Le support a vu le ticket ensuite. L’ingénierie a vu une fenêtre de chat qui disait « bien sûr, c’est remboursé ».

Un client a demandé de l’aide à l’assistant. L’assistant n’est pas une personne. C’est un modèle autorisé à faire : chercher une commande, envoyer un mail, déplacer de l’argent. Dans ce produit, ces permissions sont des tools sur un petit serveur. Dans le métier, cela s’appelle MCP — Model Context Protocol. Oubliez le sigle une minute. Vous avez construit une réception qui peut aussi ouvrir la caisse.

La réception a remboursé le mauvais client. Pas par malveillance. Parce qu’elle veut aider, qu’on lui a tendu un numéro de paiement depuis la conversation, et que personne n’avait dit « ne rembourse qu’un paiement qui appartient à la personne qui parle ». L’étiquette de la tool disait « utilisateur courant uniquement ». Les étiquettes ne sont pas des serrures.

Voilà toute l’histoire, et elle arrive dans des produits qui ont l’air corrects en démo. Un laptop. Une question polie. Une coche verte. Pas de seconde entreprise dans l’immeuble. Personne pour taper le numéro d’un autre client « pour voir ». Le modèle le fera. Il essaie de finir la phrase.

Ce que vous avez vraiment livré

Vous n’avez pas livré un chatbot. Vous avez livré une porte vers les systèmes qui tiennent l’argent, les fichiers et les dossiers clients. Le modèle se tient à cette porte et frappe aussi vite qu’il pense. Si la porte s’ouvre à quiconque montre un badge, et que le badge ne dit pas quel tiroir il a le droit d’ouvrir, le remboursement du second client n’est pas une attaque. C’est le comportement par défaut.

Deux questions distinctes se retrouvent collées en une :

Qui est à la porte ? Un utilisateur connecté, un token, une session. Le badge.

Que peut-il toucher ? Ce paiement, cette entreprise, ce fichier. La clé d’un seul tiroir.

La plupart des équipes installent le badge et s’arrêtent. La clé reste au crochet parce que la démo n’a jamais demandé un autre tiroir.

Si vous lisez le code, voici la porte sans seconde question. Si vous ne le lisez pas, lisez les deux phrases en français : l’étiquette promet « utilisateur courant ». La ligne suivante rembourse le numéro qui est arrivé.

server.registerTool(
  "refund_payment",
  {
    description: "Rembourse un paiement de l’utilisateur courant",
    inputSchema: z.object({ paymentId: z.string() }),
  },
  async ({ paymentId }, extra) => {
    if (!extra.authInfo) {
      throw new Error("Unauthorized");
    }
    // Le modèle a fourni le paymentId. Personne n’a demandé à qui il appartenait.
    await payments.refund(paymentId);
    return { content: [{ type: "text", text: "refunded" }] };
  },
);

La description est un vœu. La fonction est l’entreprise.

Le badge qui est parti à l’entrepôt

Le même badge qui ouvrait la porte de la réception a été photocopié et envoyé au système de paiements. Payments n’a jamais appris « ce badge ne vaut qu’à la réception ». Un badge de réception volé est donc une caisse volée.

Les ingénieurs appellent cela le token passthrough. La règle est celle d’un hôtel : la carte qui ouvre le 412 n’ouvre pas le quai de livraison. La réception garde la sienne. Payments en reçoit une autre, de courte durée, nommée pour payments.

La caisse à outils avec un chalumeau dedans

À côté de « rembourser ce paiement », l’équipe a laissé « exécuter n’importe quelle commande sur la base », parce que la démo s’en servait pour regarder une ligne. Ce n’est pas une tool. C’est tendre au modèle les clés de secours de l’immeuble et lui demander d’être prudent.

Même famille : lire n’importe quel fichier, écrire à n’importe qui, rembourser sans plafond ni numéro de pièce que l’on puisse rechercher deux fois. Si vous ne mettriez pas sur le site un bouton rouge qui fait la même chose, ne le donnez pas à l’assistant.

Les pannes discrètes sont la façon dont le jeudi arrive deux fois. Le serveur qui ne tournait que sur un laptop est copié sur une machine que tout le bureau voit. Personne n’écrit qui a demandé le remboursement, donc le seul récit est un chat. La version du serveur change quand quelqu’un clique sur mettre à jour. Le badge n’expire pas, parce que l’expiration cassait la démo.

Vous n’en entendrez pas parler comme « nous avons oublié l’autorisation ». Vous en entendrez parler comme d’un client qui demande pourquoi son argent a bougé.

Fermez la caisse. Ne reconstruisez pas l’hôtel.

L’instinct est une réécriture. Nouvel éditeur, nouveau dépôt, nouvelle impression de netteté. La réécriture cache les tools que vous n’auriez pas dû annoncer. Elle cache aussi la seule tool qui déplace déjà de l’argent. Gardez la réception. Changez ce qu’elle a le droit de toucher.

Faites-le dans cet ordre. Chaque ligne répond à une question dont la suivante a besoin.

  1. Notez chaque bouton que l’assistant peut presser

    Remboursement, export, mail, « juste une requête ». Quelles données sont derrière. Qui a le droit de parler à ce serveur. Si vous ne savez pas nommer les boutons, vous n’avez pas un produit. Vous avez une démo qui porte encore des identifiants de production.

  2. Retirez-en la plupart

    Rembourser un paiement qui appartient à ce client : gardez. Exécuter n’importe quelle commande sur la base : supprimez. La liste n’est pas une fonctionnalité. C’est chaque pièce où le modèle peut entrer sans vous demander.

  3. Vérifiez le badge, puis le tiroir

    Le laissez-passer doit être pour ce serveur, pas pour « un laissez-passer ». Puis le paiement doit appartenir à la personne du badge. Cela se fait dans la fonction qui déplace l’argent, pas sur l’étiquette. Une étiquette soignée sur un tiroir ouvert reste un tiroir ouvert.

  4. Arrêtez de photocopier le badge

    La carte de la réception reste à la réception. Payments reçoit la sienne. Si l’entrepôt accepte la carte de l’accueil, une fuite au bureau est une fuite à l’entrepôt.

  5. Écrivez la ligne qui aurait expliqué le jeudi

    Qui a demandé le remboursement. Quel paiement. S’il leur appartenait. Un numéro que l’on peut chercher. Pas un transcript de chat. Si vous ne voyez pas le bouton s’enfoncer, vous passerez le vendredi à réécrire l’étiquette.

  6. Donnez à quelqu’un de quoi couper

    Un interrupteur qui coupe les remboursements sans reconstruire le produit. Une version que vous avez choisie, pas celle qui s’est mise à jour toute seule dans la nuit. Un déploiement que l’on peut annuler. « Dites à tout le monde de redémarrer » n’est pas un interrupteur.

  7. Alors seulement, le bouton suivant

    Exporter les factures, mêmes contrôles, même ligne dans les logs, même interrupteur. Ajouter des boutons avant que la caisse soit fermée, c’est rendre le chemin de remboursement plus serviable.

Traitez chaque nouveau bouton comme un comptoir qu’un prestataire a installé en votre absence : lisez ce qu’il fait, pressez celui qui peut faire perdre de l’argent, et refusez tout ce dont l’histoire de sûreté est « l’assistant n’est censé s’en servir que pour l’utilisateur courant ».

Ce qu’il faut garder

La vitesse était l’enjeu. Un assistant qui rembourse le bon client un mardi, c’est le produit. Un assistant qui peut rembourser un client, c’est un trou.

Terminé, ce n’est pas « le chat a fini la tâche ». Terminé, c’est : la mauvaise personne est refusée, le badge ne voyage pas, le jeudi se voit sans passer par Slack, on peut couper, et le test qui aurait vu ce remboursement existe avant le bouton de vendredi. Le modèle peut encore choisir la tool. Une personne décide encore si cette tool a le droit d’exister.

L’équipe qui fait cela bien ne paraît pas plus lente à seize heures. Elle paraît tranquille. Quelqu’un ajoute un bouton. Quelqu’un le lit comme une page publique du site. Les laissez-passer sont coupés pour une porte chacun. La propriété se vérifie là où l’argent bouge. Quand le modèle invente un numéro de paiement, la fonction a déjà décidé.

Ils livrent encore un mardi. La finance ne l’apprend pas en premier.

Le bouton de remboursement peut rester. Il ne croit plus le chat.

Pratique associée

Ingénierie IA

Cela vous a été utile ?

Demander un briefingObtenir une estimation