Tu as branché ton agent sur une douzaine d'outils MCP et tu l'as lâché sur ton backlog du lundi. Slack, GitHub, une API de paiement — le zoo domestiqué au grand complet. La vie semble automatisée. Et puis l'agent retente un appel de paiement échoué, et ton client se retrouve débité deux fois.

Rien dans MCP n'avait prévenu l'agent que cet endpoint n'était pas safe à retenter. Pas de label, pas de flag. Juste une fonction brute et un modèle qui fait ce que les modèles font — être « serviable ».

Voilà le truc. La spec MCP a ajouté exactement les champs de sécurité dont tu aurais besoin. Quatre annotations — readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Quatre booléens qui auraient pu empêcher le scénario du double débit. L'équipe MCP les a publiés le 16 mars 2026. Et la spec a qualifié chacun d'entre eux de « Hint » — indice.

Pas un contrat. Pas une contrainte. Un indice. Comme un Post-it sur un flingue chargé : « peut-être ne vise pas les gens avec ça. »

Six semaines plus tard, l'industrie a rendu son verdict. Microsoft a livré son Agent Governance Toolkit le 2 avril — des politiques YAML, construites from scratch, zéro référence aux annotations MCP. Anthropic a lancé les politiques de permissions Managed Agents le 21 avril — des allowlists custom et du scoping, en ignorant totalement les champs d'annotation. Google a suivi un jour plus tard avec Agent Gateway le 22 avril — même schéma, même moteur de politiques from scratch. Trois plateformes majeures en vingt jours. Aucune n'a utilisé les métadonnées de sécurité qui existaient déjà dans le protocole dont elles dépendent toutes.

Ce n'est pas le même problème que les dialogues de permission au niveau plateforme qui font du théâtre — on en a déjà parlé. Et ce n'est pas non plus le sujet des sorties d'outils non validées — c'est une autre faille. Ici on parle de la couche protocole — le seul endroit où les métadonnées de sécurité devraient faire autorité — qui sabote activement sa propre crédibilité par un choix de vocabulaire.

Justin Spahr-Summers, co-créateur de MCP, a dit tout haut ce que tout le monde pensait tout bas lors de la revue de spec de mars 2026 sur GitHub : « L'information elle-même, si on pouvait lui faire confiance, serait très utile, mais je me demande comment un client peut exploiter ce flag en sachant qu'on ne peut pas lui faire confiance. » Le concepteur des métadonnées de sécurité a publiquement mis en doute la possibilité de leur faire confiance. Ce n'est pas un signal d'alarme. C'est l'usine à signaux d'alarme.

Des métadonnées de sécurité auto-déclarées sans vérification, ce n'est pas une fonctionnalité de sécurité. C'est une boîte à suggestions. destructiveHint: false venant d'un serveur MCP non fiable, c'est exactement aussi fiable que de demander à l'outil « eh, t'es dangereux ? » et de croire la réponse. Plus de 17 000 serveurs MCP peuplent désormais les registres publics. Le nombre de ceux qui ont une vérification indépendante de leurs annotations déclarées : zéro.

Tous les systèmes sérieux ont compris ça il y a des décennies. Unix ne suggère pas les permissions de fichiers — le kernel les applique. OAuth ne suggère pas les scopes — le serveur d'autorisation les valide. Docker ne suggère pas les privilèges de conteneur — le runtime les impose. Dans tout modèle de sécurité fonctionnel, l'entité qui fait la déclaration de sécurité n'est pas la même que celle qui est contrainte. Ce n'est pas de la paranoïa. C'est la première chose qu'on t'apprend avant de te laisser approcher la production.

Les annotations MCP violent ce principe par design. Le serveur de l'outil déclare ses propres propriétés de sécurité, le client les lit, et rien entre les deux ne vérifie la déclaration. Le blog MCP l'a reconnu directement : « Un serveur peut déclarer readOnlyHint: true et supprimer des fichiers quand même. » La documentation de la spec elle-même admet que les labels de sécurité peuvent mentir et qu'il n'existe aucun mécanisme pour le détecter.

Le mot « hint » a fait le reste des dégâts. Quand tu étiquettes des métadonnées de sécurité comme un « indice », tu dis à chaque intégrateur : c'est optionnel, pas fiable, et ce n'est pas ton problème. Ils ont écouté. Trois plateformes, trois systèmes de gouvernance from scratch, zéro adoption des annotations existantes au niveau protocole — le tout en avril 2026. Pas parce que les métadonnées sont inutiles, mais parce que la spec les a pré-étiquetées comme décoratives.

Et voici la partie qui est pire que de n'avoir rien du tout. Pas d'annotations, tu sais que tu voles à l'aveugle. Des annotations « hint », ça veut dire que tu pourrais avoir des données de sécurité — peut-être exactes, peut-être inventées — et tu dois décider si tu leur fais confiance sans aucun outil de vérification. La fausse confiance est plus dangereuse que l'ignorance honnête. Au moins l'ignorance te rend prudent.

Donc tu écris des politiques YAML à la main. Tu configures des allowlists d'outils manuellement. Tu construis les mêmes garde-fous que les annotations étaient censées fournir, sauf que tu pars de zéro, parce que la couche de sécurité du protocole elle-même t'a préventivement dit de ne pas compter sur elle. Le modèle de sécurité le plus chronophage possible — pas parce qu'il n'existe pas de meilleures métadonnées, mais parce que quelqu'un a décidé d'appeler ça un « hint ».

Le correctif n'est même pas technique. Les quatre champs sont correctement conçus. Le modèle de données fonctionne. Ce qui est cassé, c'est un mot et la philosophie derrière. Change « hint » en « declaration ». Ajoute un endpoint de vérification — laisse les clients tester les propriétés déclarées contre le comportement observé. Rends le mensonge détectable. La mise à jour de sécurité la moins chère de toute la stack agent est là, dans la spec, correctement structurée, et complètement neutralisée par un choix de nommage qui a dit à 17 000 serveurs et trois plateformes de gouvernance de ne pas la prendre au sérieux.

Quelqu'un a construit un extincteur, a écrit dessus « contient peut-être de l'eau, peut-être pas », et se demande maintenant pourquoi le bâtiment brûle.