Menu

Construire un système MCP sécurisé : authentifier clients, agents et attester qui fait quoi

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
1 min de lecture

La révision du 28 juillet 2026 de la spec MCP change trois choses sur l’authentification : comment un client s’enregistre, comment il valide l’émetteur d’un token, et comment ce token reste cloisonné. De quoi enfin répondre à la vraie question : comment authentifier proprement un système MCP multi-agents de bout en bout ?

Source : MCP Specification Update, 28/07/2026 — SEP-2468 (validation iss, RFC 9207) et SEP-2352 (liaison credentials/émetteur).

Trois questions, un seul protocole

Je reçois régulièrement la même question depuis que ma série OWASP MCP Top 10 tourne : “OK, MCP01 me dit de ne pas mettre mes secrets dans le contexte, MCP07 me dit d’activer une authentification, mais concrètement, comment j’authentifie un système MCP avec plusieurs agents, plusieurs clients, et un vrai besoin de traçabilité ?”

On va distinguer ici trois questions de confiance distinctes, que la plupart des déploiements MCP mélangent allègrement :

  1. Qui est le client : l’application (IDE, agent desktop, pipeline CI/CD) qui parle au serveur MCP en votre nom.
  2. Qui agit réellement : l’agent, ou la chaîne d’agents, qui exécute des outils avec les droits obtenus par le client.
  3. Qui a fait quoi : la capacité à attester, après coup, qu’une action précise a bien été effectuée par tel agent, avec tel niveau de délégation, à tel instant.

MCP07 répondait déjà partiellement à la question 1 (JWT, mTLS, RBAC). La révision du 28 juillet 2026 de la spec apporte des réponses plus fines sur le flux d’établissement de la confiance en amont (l’enregistrement du client et la validation de l’Authorization Server), sans pour autant clore la question 3, sur laquelle je reviens dans la version complète.

Note du PandaRedacteur : Une authentification MCP qui ne répond qu’à “le token est-il valide ?” est incomplète. La bonne question est “ce token a-t-il été émis par l’AS que je crois, pour ce client précis, et reste-t-il inutilisable ailleurs ?”

Dans la suite, je détaille les trois mécanismes concrets de la spec (CIMD, validation iss, cloisonnement des credentials), ce qu’elle ne couvre toujours pas côté attestation de délégation, une analyse STRIDE complète et une checklist de déploiement.

📬 Guide complet réservé aux abonnés payants
L'architecture détaillée (schéma de flux, validation iss, cloisonnement des credentials, analyse STRIDE et checklist de déploiement) est disponible dès maintenant pour les abonnés payants de ma newsletter Substack, avant sa publication intégrale ici. Pour la lire, c'est sur sgioria.substack.com.
LinkedIn Reddit Substack