MCP a publié une spécification stable pour l'« Enterprise-Managed Authorization » ; les autres projets de spécification pour l'identité machine-to-machine — incluant un projet OAuth client-credentials et deux propositions ouvertes — restent inachevés. Pour quiconque tente d'exécuter des agents autonomes avec le Model Context Protocol, cela signifie que le protocole actuel peut vérifier un utilisateur humain, mais n'offre aucun moyen prêt à l'emploi de prouver qu'un processus non supervisé est bien celui qu'il prétend être.
Pourquoi la feuille de route est importante
La feuille de route du Model Context Protocol (MCP) place l'identité et la sécurité des agents parmi ses priorités absolues. Quatre éléments étaient prévus pour une publication : un flux de navigation centré sur l'humain, un flux OAuth client-credentials pour les services, une liaison de jeton (token binding) basée sur DPoP, et un mécanisme de fédération d'identité de charge de travail (workload-identity federation). Seul le premier — Enterprise-Managed Authorization — a atteint un statut stable.
Ce que fait réellement la spécification stable
L'Enterprise-Managed Authorization permet aux administrateurs informatiques d'accorder l'accès au serveur depuis une console unique, au lieu de demander à chaque employé d'approuver chaque connexion. Le flux utilise une redirection de navigateur et une connexion utilisateur, de sorte qu'une personne sur un ordinateur portable peut s'authentifier, puis le serveur fait confiance à la session de cet utilisateur.
La limitation est évidente : le processus nécessite un humain devant un clavier. Un agent qui s'exécute pendant la nuit, traite des données ou répond à des alertes n'a personne pour cliquer sur un bouton de connexion. Par conséquent, tout déploiement dépendant d'agents non supervisés ne peut pas utiliser la seule spécification que MCP garantit actuellement.
Les options en projet et leurs inconvénients
Deux extensions en projet visent à donner aux agents leur propre identité :
- SEP-1932 (DPoP) – lie les jetons à une paire de clés publique-privée, rendant les jetons volés inutilisables.
- SEP-1933 (Workload Identity Federation) – permet aux agents d'hériter d'identités déjà provisionnées sur les plateformes cloud.
Les deux existent sous forme de pull requests ouvertes ; aucune n'a été fusionnée dans la spécification officielle. En attendant, la seule autre option documentée est un flux OAuth client-credentials qui nécessite des secrets pré-enregistrés. Stocker ces secrets là où un agent peut les lire crée une surface d'attaque classique : si le secret est compromis, n'importe quel attaquant peut usurper l'identité de l'agent.
Étapes pratiques pour la production aujourd'hui
Comme le protocole ne fournit pas encore d'identité d'agent native, les équipes peuvent tout de même sécuriser les agents en déplaçant la gestion de l'identité en dehors de MCP :
- Émettre des identités vérifiables au niveau de la charge de travail. Des systèmes comme SPIRE génèrent des certificats à courte durée de vie liés à la racine de confiance de l'hôte, éliminant ainsi les secrets statiques.
- Terminer les identifiants au niveau d'une passerelle. Un service front-end détient la clé API ou le jeton et transmet les requêtes au nom de l'agent, gardant ainsi le secret hors de l'environnement d'exécution.
- Autoriser sur la base de l'identité vérifiée, et non du contenu du jeton. Séparez l'authentification (qui appelle) de l'autorisation (ce qu'ils peuvent faire) afin que les politiques puissent être appliquées même si la méthode d'authentification change.
Ce qu'il faut surveiller ensuite
Les deux pull requests ouvertes — la liaison DPoP et la fédération d'identité de charge de travail — sont les seuls chemins vers un véritable standard d'identité machine-to-machine au sein de MCP. Si la communauté les fusionne, les agents pourront prouver la possession d'une clé privée ou hériter d'identités délivrées par le cloud sans exposer de secrets. D'ici là, tout déploiement en production devra s'appuyer sur des frameworks d'identité externes ou accepter le risque lié aux identifiants statiques.
La conclusion est claire : MCP peut actuellement authentifier la personne derrière une requête, mais il n'authentifie pas encore le logiciel qui effectue la requête. Les équipes qui ont besoin d'agents autonomes sécurisés ne devraient pas attendre la publication de la spécification ; elles doivent construire l'identité au niveau de la charge de travail dès aujourd'hui et surveiller les propositions en attente concernant DPoP et la fédération.