La démo était en staging. Les clés étaient en live.

La salle a applaudi. L’agent a listé des outils, ouvert une fiche, résumé un historique — le serveur MCP de démo répondait bien. Personne n’a remarqué que le jeton collé dans la config locale était encore celui de la production. Dans ce scénario illustratif, l’UI affiche staging ; le credential parle live. La démo réussit. L’accès réel a déjà commencé.

Le problème n’est pas le protocole MCP. C’est le mélange d’environnements côté secrets et serveurs : un agent ou une démo qu’on croit en recette, branché sur des credentials, une URL d’hôte ou un coffre encore live. Tant que staging et production partagent le même jeton, le même serveur MCP, ou le même fichier d’env « pour aller vite », l’isolation n’existe que dans le discours — pas dans l’architecture.

La décision raisonnable : un seul câble pour la démo

La décision d’architecture qui revient le plus souvent : réutiliser le compte technique live (ou le jeton le plus proche) pour que la démo « marche vraiment ». Pourquoi c’est raisonnable le jour J : le staging n’a pas de données parlantes, le métier veut voir une vraie fiche, et l’équipe évite de provisionner un second coffre avant d’avoir une preuve. On copie un .env, on pointe le client MCP vers le même host « temporairement », on laisse le secret dans le profil de l’agent local. Ces intentions deviennent coûteuses dès que ce câble unique reste après la réunion.

Ce récit se place à côté du cadrage de périmètre d’outils. Un article voisin traite la liste d’outils et le least-privilege ; ici le sujet est plus étroit : même avec une surface bornée, si le secret ou le serveur derrière est live, l’agent agit sur la production. MCP transporte l’appel. Il ne choisit pas le coffre. Côté périmètre MCP, on bornait les outils ; ici on isole les environnements.

Pourquoi ça tenait — jusqu’au premier appel réel

Tant que personne n’appelle un outil d’écriture, le mélange reste invisible. La démo lit. Les logs de staging restent calmes. On conclut à tort que « c’était bien la recette », parce que l’écran dit staging. Or l’environnement réel d’un connecteur MCP, ce n’est pas le label du chat : c’est l’hôte joint, le jeton présenté, et le compte applicatif derrière.

Trois confusions se superposent souvent. UI de démo vs cible réseau — un client « staging » peut pointer vers l’URL live. Fichier d’env vs vérité déployée — un secret live dans un profil d’agent local n’apparaît dans aucun coffre de recette. Un seul serveur MCP partagé vs deux environnements — le même process sert la démo et l’accès interne. Chacune produit le même symptôme : on croyait tester ; on a touché le live.

Où ça casse : le contrat d’isolement

Le contrat cassé n’est pas « l’IA est imprévisible ». C’est l’isolement staging / prod des secrets et des serveurs. Dès qu’un outil lit une fiche live, exporte ou écrit, la conséquence métier est concrète : donnée réelle exposée en démo, modification non voulue, journal de production pollué, ou secret live dans captures et logs de dialogue. Aucune erreur HTTP obligatoire — souvent un 200 poli sur le mauvais environnement.

Variantes fréquentes du même mécanisme :

• jeton live collé dans la config du client MCP « le temps de la démo » ;
• même URL de serveur MCP pour recette et production ;
• coffre partagé ou variable d’env copiée depuis la prod vers le laptop ;
• tunnel qui expose encore le backend live sous un nom de staging ;
• compte technique unique, sans paire staging / live.

Dans tous ces cas, MCP n’est ni le sujet ni le méchant. C’est un protocole d’appel d’outils. Le risque vient du modèle d’auth, des credentials et de l’architecture d’environnements derrière.

Cible : deux coffres, deux serveurs, un refus explicite

L’architecture cible est banale — et souvent reportée. Serveur MCP staging + secrets staging. Serveur MCP production + secrets production. Comptes techniques distincts. Staging qui refuse clairement une clé live. Journaux qui indiquent quel environnement a servi l’appel. La démo utilise fixtures ou données anonymisées ; le métier le sait.

Le compromis : la démo est un peu moins « wow » le premier jour. En échange, un essai raté ne touche pas le CRM live. Si le métier exige des données réelles, ce n’est plus du staging : c’est un accès production cadré (least-privilege, durée courte, journal, révocation) — nommé comme tel.

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

Avant de « refaire la démo plus proprement », on sépare les causes sur un scénario illustratif contrôlé.

Hypothèse A — le client MCP pointe vers l’hôte live. Test : lire la config effective (URL, profil, variables résolues) et la comparer à l’URL de staging attendue. Résultat attendu si l’hypothèse tient : host live ou nom trompeur. Conclusion : corriger la cible réseau avant les prompts.

Hypothèse B — le secret présenté est live. Test : inspecter le jeton injecté (coffre local, env du process) ; vérifier qu’il n’appartient pas au compte production. Résultat attendu si l’hypothèse tient : credential live en contexte dit staging. Conclusion : rotation du secret live ; provisionner un secret staging.

Hypothèse C — le staging accepte encore les secrets live. Test : présenter une clé live à l’endpoint de staging et exiger un refus explicite. Résultat attendu si l’hypothèse tient : 200 ou accès métier. Conclusion : isoler la validation des secrets par environnement.

Hypothèse D — un seul serveur MCP sert démo et prod. Test : cartographier quels clients joignent le même process / la même URL. Résultat attendu si l’hypothèse tient : surface partagée. Conclusion : scinder serveurs ou configs et comptes.

Hypothèse E — journal sans environnement. Test : déclencher un appel outil et exiger une trace (env, host, tool, succès/refus) joignable au dialogue. Résultat attendu si l’hypothèse tient : silence ou logs sans label d’environnement. Conclusion : sans corrélation, on ne départage pas démo et accès live.

Ces cinq tests collent à des artefacts — URL, vault path, refus, topologie, journal — plutôt qu’à un débat d’intention.

client MCP       → URL serveur (staging ≠ live ?)
secret injecté   → vault path / compte technique
endpoint staging → doit refuser clé live
topologie        → 1 serveur partagé ou 2 isolés ?
journal          → env + tool + correlation_id

Correction maintenant, prévention ensuite

La correction traite ce qui est déjà mélangé. On coupe immédiatement tout credential live dans les configs de démo — rotation, pas simple suppression du fichier. On sépare les URL de serveurs MCP. On vérifie dans les journaux de production les appels pendant les fenêtres de démo, et on traite les effets métier. On ne se contente pas de renommer le projet « staging » dans le chat.

La prévention se pose avant la prochaine démo. Deux coffres, deux comptes techniques, règle écrite : aucun secret live hors du chemin production. Checklist go-demo : URL, vault path, refus staging vs clé live, label d’environnement dans les logs. Revue quand on ajoute un serveur MCP — comme un changement d’ACL réseau. Si une démo doit toucher des données réelles, on la nomme accès production cadré, avec durée et révocation.

Séparer les deux évite un piège classique : croire qu’un meilleur prompt (« tu es en staging ») suffit. Un prompt cadre une intention ; il n’annule pas un jeton live déjà présenté. Inversement, deux URL distinctes ne sauvent pas si le même secret est collé des deux côtés.

Limites et ce que ce texte n’est pas

Ce texte décrit une classe fréquente — démo ou agent « staging » branché sur credentials ou serveur live — pas un incident nominatif. Aucun client, aucune stack interne. Les vecteurs listés ne sont pas exhaustifs. Le bon réflexe reste hypothèse, test sur artefact, conclusion.

MCP n’est ici ni le sujet ni le coupable. C’est un protocole d’appel. Le risque vient du modèle d’authentification, des credentials et de l’isolement des environnements. Quand le projet ne peut plus vivre sans « le jeton live pour que la démo soit crédible », ce n’est plus une intégration IA : c’est une dette d’architecture d’accès.

Si vous branchez déjà un agent sur le CRM ou le mail et que staging / prod partagent encore secrets ou serveur, le cadre opérationnel — isolation, auth, gouvernance — est décrit sur la page IA / MCP.