MCP: Avant la Fonction, la Confiance

Photo by Cytonn Photography on Unsplash

---

Cher journal,

« Aujourd’hui, je m’imaginais avoir laissé un agent IA piloter le déploiement de mes services cloud pendant que je savourais mon café. Et, dans ce silence, j’ai senti un frisson : qui, dans cette chaîne invisible, assurait vraiment le contrôle ?

Je feuilletais dans un coin de mon esprit le papier “Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions” (arXiv:2503.23278v2), que j’avais relu la veille. Ce document dresse un état des lieux rigoureux : il décrit la topologie du protocole MCP, détaille les menaces de sécurité (usurpation, injection de code, collisions de noms de serveurs) et esquisse des pistes de recherche pour renforcer l’authentification, la découverte et la confiance.

Pourtant, en refermant ce PDF, j’ai réalisé que l’essentiel manquait : un registre universel, une autorisation fine et un moteur de réputation immuable. Laurie Voss l’affirme dans sa conférence : « Tous les protocoles d’agents—MCP inclus—manquent de ces trois briques ; greffer simplement ces modules suffirait » .

---

Déconstruction de la croyance « registre, autorisation, réputation »

1. Registre

   • Pourquoi le paper MCP insiste-t-il sur un “registre de serveurs centralisé” ? Parce qu’aujourd’hui, chaque découverte requiert de connaître à l’avance l’adresse d’un serveur MCP .

   • Vérité première : un système distribué n’est viable que s’il offre un *mécanisme de résolution d’identité robuste (DNS, DID, DLT).

2. Autorisation

   • Qu’est-ce que le papier appelle “authentication and authorization gaps” ?

   • Il décrit comment une fois authentifié, un agent peut conserver des privilèges « off-chain » et outrepasser des ACLs prévues .

   • Vérité première : chaque message peut modifier un environnement critique ; seules des politiques déclaratives, signées et versionnées, garantissent un contrôle granulaire.

3. Réputation

   • Le paper mentionne-t-il la réputation ? Oui, il évoque des “trust systems based on reputation” comme piste future, mais sans l’ancrer dès la conception .

   • Vérité première : la confiance naît d’un ledger immuable et de flux de feedback en temps réel, condition indispensable pour distinguer un agent fiable d’un acteur malveillant.

---

Pourquoi “greffer” ces modules à MCP ne suffit pas

Laurie propose un patchwork : un registre ici, OAuth là, un module réputation par-dessus. J’y vois trois écueils :

1. Cohérence sous partition réseau
   – Un registre fédéré, sans consensus léger (gossip/quorum), risque la fragmentation des vues.

2. Couplage implicite
   – Ajouter la réputation sans modifier le flux de messages, c’est ignorer que logs et réputation doivent être intrinsèquement liés.

3. Évolution et compatibilité
   – Chaque extension introduit son propre schéma, menaçant la rétrocompatibilité d’un MCP déjà complexe.

---

Esquisse d’un « Agent Trust Mesh »

Plutôt qu’un mille-feuille incompatible, voilà ma proposition, fondée sur les premiers principes :

{
  "sender":    "did:example:moi",
  "recipient": "did:example:service",
  "payload":   { … },
  "timestamp": "2025-06-20T10:15:00Z",
  "signature": "0xABCD1234…"
}

1. Registre distribué
   – Basé sur un consensus léger (gossip + quorum) ou une DLT, garantissant découverte et tolérance aux partitions.

2. Politique d’autorisation déclarative
   – ACL signées, versionnées, publiquement consultables, liées au DID émetteur.

3. Moteur de réputation temps réel
   – Ledger immuable associant chaque transaction à un feedback, pour un score de fiabilité continu.

4. Métaprotocole de gouvernance
   – Hooks et webhooks standardisés : orchestration sûre des mises à jour, renouvellement de jetons, et publication de nouvelles règles sans rupture ni fork.

---

Conclusion intime et appel à repenser la confiance

En reposant le papier MCP à mes côtés, j’ai compris que la vraie révolution ne viendra pas d’une extension opportuniste, mais d’une reconception des fondations. Avant d’ajouter toujours plus de fonctionnalités à MCP, posons d’abord les briques de la confiance : registre, autorisation et réputation, ancrés dès l’origine, non comme des surcouches, mais comme le socle même de toute interaction agent-agent.

« Avant de rendre mes agents plus “intelligents”, je dois être sûr qu’ils restent, envers et contre tout, dignes de ma confiance*. »*

Fin de l’entrée. Je replie mon carnet, rassuré de savoir que la véritable maturité des protocoles IA repose sur ces premiers principes intangibles.