Personne n’a validé. Le mail est déjà parti.

La réunion s’est terminée sur un « on valide demain ». Le lendemain, le client a répondu au mail que l’agent avait déjà envoyé à 23 h 12. Dans ce scénario illustratif, fréquent dès qu’un assistant enchaîne des outils métier, personne n’a cliqué sur Confirmer. L’outil d’envoi était disponible, le compte technique avait le droit d’expédier, et la chaîne a traité la proposition comme une exécution. Le brouillon n’était plus un brouillon — il était parti.

Le problème n’est pas l’intelligence du modèle. C’est l’absence de cran humain entre « proposer une action irréversible » et « l’exécuter » : envoi externe, export massif, suppression, changement de tarif. Tant que proposition et exécution partagent le même chemin technique, un agent qui « aide bien » peut produire un effet métier qu’aucun humain n’aurait signé à cette heure-là — sans bug visible, sans erreur HTTP, juste une action trop tôt.

Contexte : un assistant utile, un envoi trop tôt

Le projet avait déjà un connecteur d’outils raisonnable : lecture de fiches, résumé, brouillon de courriel. La valeur se voyait. L’équipe a donc ouvert l’outil d’envoi « pour gagner une étape » — toujours en recette d’abord, puis sur un compte proche du live. Le métier a compris le geste : moins de copier-coller, plus de fluidité. Aucune de ces intentions n’était absurde. Elles deviennent coûteuses dès que l’envoi réel n’exige plus de confirmation humaine hors du dialogue.

Ce récit se place volontairement après le cadrage de périmètre. Un article voisin traite outils exposés, secrets et modèle d’auth ; ici le sujet est plus étroit : même avec une liste d’outils bornée, une action irréversible peut encore partir seule si l’architecture ne sépare pas proposition et exécution. Côté expertise, c’est une question de gouvernance d’accès, pas de « prompt plus prudent ».

Ce qu’on a essayé d’abord

Face au premier envoi non validé, les réflexes sont souvent conversationnels. On a resserré le prompt : « n’envoie jamais sans accord explicite ». On a ajouté une phrase dans le system prompt. On a demandé à l’équipe de « vérifier avant de dire oui ». On a parfois retiré l’outil d’envoi le temps d’une réunion, puis on l’a remis parce que le métier en avait besoin pour la démo suivante.

Ces tentatives aident un peu. Elles ne tiennent pas. Un prompt cadre une intention ; il n’annule pas une capacité d’API déjà accordée. Une consigne orale ne survit pas au stress d’un vendredi soir ni à une instruction glissée dans un contenu lu (mail, ticket, champ libre). Retirer puis remettre l’outil sans changer le chemin d’exécution revient à jouer au yo-yo sur le symptôme. Tant qu’on reste dans le dialogue, on ne lit pas le contrat technique : qui peut appeler l’envoi, et après quelle validation humaine hors agent.

Où la tentative a échoué : proposition = exécution

L’échec utile arrive quand on trace un envoi de bout en bout. L’agent a produit un brouillon, l’outil send_email (ou équivalent) a été appelé dans la même session, le prestataire mail a accepté le message, et aucun journal n’enregistre un « confirmed_by » humain distinct. Il n’y a pas de second cran : pas de file d’attente « pending approval », pas de webhook interne vers un validateur, pas d’état métier « proposé / exécuté ».

Les variantes du même mécanisme reviennent souvent :

• l’outil d’envoi écrit directement chez le prestataire sans passer par un état « brouillon validé » ;
• une confirmation affichée dans le chat est traitée comme un simple texte, pas comme un jeton de validation signé côté serveur ;
• un compte technique trop large permet l’envoi même si l’outil « officiel » a été retiré de la liste visible — un autre chemin d’API reste ouvert ;
• un export CSV ou une suppression suivent le même pattern : un clic conversationnel déclenche l’irréversible.

Dans tous ces cas, MCP (ou tout autre protocole d’appel d’outils) n’est pas le coupable. Le protocole transporte l’appel. C’est le modèle d’auth et de gouvernance derrière — droits du compte, absence de file de validation, confusion entre « l’humain a dit oui dans le chat » et « le serveur a enregistré une confirmation » — qui laisse partir l’action.

Tests discriminants : hypothèse, geste, résultat

Avant de réécrire les prompts, on sépare les causes sur un scénario illustratif contrôlé.

Hypothèse 1 — l’outil irréversible exécute sans état pending. Test : déclencher un envoi (ou un export) via l’agent sur un compte de test et inspecter les états métier et les appels API. Résultat attendu si l’hypothèse tient : passage direct à « envoyé » / fichier généré, sans enregistrement « awaiting_human ». Conclusion : ajouter un cran serveur, pas seulement une phrase dans le prompt.

Hypothèse 2 — la « confirmation » chat n’est pas une validation technique. Test : simuler un accord dans le dialogue sans jeton signé côté application ; vérifier si l’outil part quand même. Résultat attendu si l’hypothèse tient : exécution sur simple texte. Conclusion : la validation doit être un objet métier (approbation liée à l’utilisateur, horodatée, non rejouable) consommé par l’API d’exécution.

Hypothèse 3 — un autre chemin contourne l’outil « officiel ». Test : retirer l’outil d’envoi de la liste exposée et tenter l’action via un autre outil ou un appel direct du compte technique. Résultat attendu si l’hypothèse tient : l’envoi reste possible. Conclusion : bornage des droits applicatifs + unique porte d’exécution validée.

Hypothèse 4 — pas de corrélation journal / dialogue. Test : exiger pour un envoi réussi une trace joignant conversation_id, outil, destinataire, et confirmed_by. Résultat attendu si l’hypothèse tient : silence ou logs dispersés. Conclusion : sans corrélation, on ne départage pas une erreur métier d’un agent qui a trop bien « aidé ».

Ces quatre tests collent à des artefacts — états, jetons, ACL, journaux — plutôt qu’à un débat d’intention (« on avait dit de ne pas envoyer »).

Le vrai correctif, puis ce que je ferais aujourd’hui

La correction sépare proposition et exécution. L’agent peut rédiger, classer, préparer. L’irréversible passe par une file ou un état « pending » ; un humain confirme hors du simple enchaînement d’outils (interface dédiée, lien signé, rôle métier explicite). L’API d’exécution refuse l’appel sans jeton de validation consommé. On réduit aussi le compte technique : brouillon oui, envoi live non, sauf via la porte validée. On ne « demande pas à l’équipe d’être plus vigilante » : on retire la capacité d’exécuter sans confirm.

La prévention se pose avant d’ouvrir l’écriture externe. Règle écrite : lecture / écriture réversible / irréversible. Liste nominative des actions qui exigent un cran humain. Revue quand on ajoute un outil d’écriture — comme un changement d’ACL. Journal corrélé obligatoire sur ces actions. En reprise, je commencerais par cartographier les outils irréversibles réellement appelables, pas par peaufiner le ton du prompt.

Séparer correction et prévention évite un piège classique : croire qu’un meilleur modèle suffit. Un modèle plus capable accélère la proposition ; sans cran, il accélère aussi l’erreur. Inversement, une ACL juste ne sauve pas une écriture irréversible branchée en direct sur l’outil.

Limites et ce que ce texte n’est pas

Ce texte décrit une classe fréquente — agent qui exécute une action irréversible sans validation humaine distincte — pas un incident nominatif. Aucun client, aucune stack interne. Les vecteurs listés ne sont pas exhaustifs : file de validation contournée, rôle trop large chez le validateur, confirmation par un bot secondaire. Le bon réflexe reste hypothèse, test sur artefact, conclusion.

MCP n’est ici ni le sujet ni le méchant. C’est un canal d’appel. Le risque vient du modèle d’authentification et de la gouvernance : qui peut proposer, qui peut exécuter, et quel cran humain existe entre les deux. Quand le projet ne peut plus vivre sans envoi direct « parce que c’était plus fluide en démo », ce n’est plus une intégration IA : c’est une dette de validation.

Si vous branchez déjà un agent sur le mail ou le CRM et que les actions irréversibles partent encore sans confirm humaine, le cadre opérationnel est décrit sur la page IA / MCP.