MCP dispose désormais d'un mécanisme spécifié permettant à un agent de s'authentifier sans humain dans la boucle. SEP-1046 ajoute le grant OAuth client_credentials au Model Context Protocol sous forme d'extension officielle, avec private_key_jwt (assertions client JWT selon RFC 7523) comme méthode d'authentification client recommandée, et les client secrets classiques autorisés pour compatibilité. Accepté en octobre 2025, il a atterri ces derniers mois dans les SDK TypeScript, Python, et maintenant Ruby. Si vous exploitez des agents en entreprise, c'est la pièce du puzzle que vous attendiez, que vous connaissiez son numéro de SEP ou non.

Une confession avant le fond : ce billet a failli ne jamais être écrit. L'écosystème de l'IA agentique évolue assez vite pour que rédiger à son sujet devienne un problème de planning à part entière ; SEP-1046 dormait dans mes brouillons pendant que trois autres sujets partaient en production, et je n'ai trouvé le temps que maintenant, parce que la synthèse de Brad Webb sur les patterns d'autorisation MCP en entreprise a atterri dans ma file de lecture et rendu le tableau assez complet pour mériter votre temps. Lisez aussi son article. Celui-ci est ma version plus courte et plus tranchée de ce qui compte vraiment pour les équipes en entreprise.

Comment une issue GitHub devient une couche de sécurité

Le 24 juillet 2025, Darin McAdams a ouvert l'issue #1046 sur le dépôt de la spécification MCP. Le pedigree compte ici : McAdams a passé près de 26 ans chez Amazon, la dernière période comme Senior Principal Software Engineer, et a rédigé cette proposition dans ses dernières semaines là-bas, avant de rejoindre Defakto Security, entreprise de sécurité des identités, comme Architect. La proposition est courte et chirurgicale : la spécification d'autorisation MCP d'origine mentionnait le flux client credentials, des révisions ultérieures l'ont retiré, et la spécification a fini muette sur le scénario d'entreprise le plus courant, un workload qui doit appeler un serveur MCP quand aucun utilisateur final n'est présent pour valider un écran de consentement interactif.

La proposition a été acceptée sous le nom SEP-1046 et finalisée le 30 octobre 2025, livrée comme extension MCP io.modelcontextprotocol/oauth-client-credentials plutôt que comme modification du cœur de la spécification. Puis les implémentations ont suivi : PrivateKeyJwtProvider dans le SDK TypeScript, PrivateKeyJWTOAuthProvider dans le SDK Python, et plus récemment un commit de Koichi ITO (koic, connu pour RuboCop) ajoutant le support de private_key_jwt au SDK Ruby officiel, scénario de conformité inclus. Cette progression, proposition, puis SEP accepté, puis implémentations indépendantes passant une suite de conformité partagée, c'est à cela que ressemble un protocole qui mûrit. Il y a deux ans, « MCP auth » voulait dire un bearer token dans une variable d'environnement et une prière.

Pourquoi client credentials compte : les agents n'ont pas de navigateur

Le flux OAuth authorization code, sur lequel la spécification MCP de base s'appuie, suppose un humain. Quelqu'un voit un écran de consentement, s'authentifie auprès du fournisseur d'identité et délègue une part de son autorité au client. Ce modèle convient à Claude Desktop connecté à votre CRM. Il ne convient pas aux workloads que les entreprises déploient réellement : un agent de réconciliation nocturne, un pipeline CI qui interroge un serveur MCP interne, un agent superviseur qui distribue le travail à des agents spécialisés à 3 heures du matin. Personne n'est réveillé pour cliquer sur « Autoriser ».

Client credentials, c'est le pattern du compte de service de tous les playbooks IAM d'entreprise, appliqué à MCP. Le workload possède sa propre identité, enregistrée à l'avance dans votre plateforme d'identité, et s'authentifie en son nom propre. Pas de session utilisateur empruntée, pas de navigateur headless qui se fait passer pour une personne, pas de personal access token longue durée scotché dans un gestionnaire de secrets. L'agent est un principal à part entière, avec ses propres droits, sa propre piste d'audit et son propre cycle de vie. Si votre équipe sécurité bloque les déploiements MCP parce que « les agents s'authentifient en tant que Dave », voilà la réponse à lui donner.

private_key_jwt : le bon défaut, et son coût

SEP-1046 restreint délibérément l'authentification client à deux options. Les client secrets via HTTP Basic sont autorisés, parce que tous les fournisseurs d'identité de la planète les supportent aujourd'hui. Mais la méthode recommandée est private_key_jwt : le client signe une assertion JWT de courte durée avec une clé privée et la présente à la place d'un secret. Les détails de conception dans les implémentations des SDK méritent lecture, parce qu'ils encodent un vrai jugement de sécurité :

  • L'assertion porte iss et sub positionnés sur le client ID, aud positionné sur l'identifiant d'issuer du serveur d'autorisation, un exp de 300 secondes et un jti unique. Une assertion volée expire en cinq minutes et ne peut pas être rejouée.
  • La clé privée ne quitte jamais le client et n'est jamais écrite dans le stockage de tokens. Aucun secret partagé ne dort dans la base du serveur d'autorisation en attendant d'être exfiltré.
  • Le client_id est entièrement omis du corps de la requête ; l'identité voyage dans l'assertion signée. La requête de token porte aussi le paramètre resource de la RFC 8707, si bien que le token retourné est lié à un serveur MCP précis plutôt qu'utilisable contre tout ce qui accepte l'issuer.

Le coût, c'est la gestion des clés. Les clés asymétriques exigent génération, distribution, rotation et révocation, et SEP-1046 ne spécifie volontairement pas encore comment un serveur découvre le JWKS du client pour valider les assertions ; cela attend les travaux WIMSE sur les JWT headless et la maturation du draft Client ID Metadata à l'IETF. En pratique, la plupart des équipes démarreront avec des client secrets et migreront vers les assertions JWT quand l'outillage de leur plateforme d'identité aura rattrapé. C'est très bien ainsi. Choisir aujourd'hui l'option compatible avec un chemin de migration spécifié n'a rien à voir avec ne pas avoir de chemin du tout.

Une omission délibérée a fait débat dans le fil de l'issue : mTLS. Plusieurs commentateurs voulaient les certificats client de la RFC 8705 dans le périmètre, et la réponse explique pourquoi ils n'y sont pas : dans les déploiements réels, TLS se termine au CDN ou au load balancer, plusieurs sauts avant la couche applicative où MCP s'exécute réellement, si bien que le serveur ne voit jamais le certificat client sans acrobaties d'infrastructure. Les entreprises disposant d'une PKI interne fonctionnelle peuvent toujours faire du mTLS entre leurs propres services ; la spécification refuse simplement d'imposer cette hypothèse à tout le monde.

Les patterns qui survivent au contact d'une entreprise

L'article de Webb cadre la décision mieux que n'importe quel tableau comparatif de protocoles : partez de l'origine de l'autorité de l'agent, pas d'un menu de flux OAuth. Tout le reste découle de cette question. Trois patterns couvrent presque tous les cas d'entreprise :

  • Autorité utilisateur déléguée pour les outils interactifs : les droits de l'humain se transmettent à l'agent via le flux authorization code. Le piège ici est le token pass-through, transmettre tel quel le token du fournisseur d'identité amont au serveur MCP. Cela fonctionne en démo, et en production cela couple votre plateforme d'agents à un format de token et à un modèle de confiance étrangers. Échangez le token contre un token de courte durée émis pour le serveur MCP visé, avec validation d'audience imposée. L'exigence d'indicateur de ressource RFC 8707 de la spécification existe précisément pour faire échouer le blanchiment de tokens génériques.
  • Identité machine pour les workloads sans supervision : client credentials selon SEP-1046, préférez private_key_jwt, un client enregistré par workload d'agent, pas un client « agents » partagé pour toute la plateforme. Le rayon d'impact suit la granularité de l'enregistrement.
  • Double identité pour le milieu intéressant : un agent agissant au nom d'un utilisateur mais tournant sans supervision. Le token doit représenter à la fois l'acteur (l'agent) et le sujet (l'utilisateur), ce que le token exchange permet et que la plupart des serveurs d'autorisation savent désormais exprimer. C'est le pattern qui garde la question « quel humain est responsable de cette action » traçable en audit, et c'est la question que votre équipe conformité posera réellement.

Sur l'enregistrement lui-même : SEP-991 a fait des OAuth Client ID Metadata Documents le pattern préféré pour des clients et serveurs sans relation préexistante, une URL HTTPS comme identifiant client. Élégant pour l'écosystème ouvert ; pour une entreprise fermée, le pré-enregistrement via votre plateforme d'identité interne reste le meilleur défaut, parce qu'il vous donne la propriété, l'allow-listing et le contrôle du cycle de vie, et qu'il retire de votre modèle de menace toute une classe de risques SSRF liés à la récupération de métadonnées.

SEP-1046 est une voie, pas toute la route

Passez une heure dans le label auth du dépôt de spec et le cadrage mono-SEP s'effondre : il existe un groupe de travail auth permanent avec un rythme de réunions, et une file de propositions qui dessine la suite de l'autorisation MCP en entreprise. SEP-1488 ajoute securitySchemes aux métadonnées d'outils pour les serveurs à auth mixte, un serveur exposant des outils publics à côté d'outils protégés par OAuth. SEP-1489 standardise l'erreur qu'un outil renvoie pour déclencher un flux OAuth en pleine session, autrement dit l'autorisation step-up en termes d'agents. SEP-2742 veut que les serveurs distants déclarent leurs méthodes d'authentification en amont, pour qu'un client sache où il met les pieds avant de se connecter. La signature de messages HTTP revient avec la PR #2752 après la mise en sommeil de SEP-1415. Et le durcissement continue d'atterrir entre les grands SEP : validation d'issuer RFC 9207 obligatoire contre les attaques par mix-up (#1721), Rich Authorization Requests selon RFC 9396 (#1670), transfert de refresh tokens pour l'accès hors ligne (#1735), et un chantier ouvert pour alléger la spec d'autorisation en déléguant aux RFC OAuth sur lesquelles elle repose (#3054). Si la sécurité des agents en entreprise est votre responsabilité, cette file d'issues est votre feuille de route. Lisez-la comme votre propre backlog.

Quoi faire de tout cela lundi

Concrètement, pour une équipe plateforme ou sécurité qui déploie MCP dans une organisation :

  • Inventoriez chaque intégration MCP et classez-la : interactive, sans supervision, ou agissant au nom d'un utilisateur. Le flux découle de la classe, jamais l'inverse.
  • Donnez à chaque agent sans supervision son propre client enregistré dans votre fournisseur d'identité. Démarrez avec des client secrets si votre outillage l'exige, mais mettez private_key_jwt à la roadmap dès maintenant et vérifiez si votre SDK le supporte déjà. TypeScript, Python et Ruby le font.
  • Imposez la validation d'audience sur chaque serveur MCP que vous opérez. Un token émis pour un serveur doit échouer sur un autre. C'est le contrôle le moins cher de toute la pile, et le plus souvent sauté.
  • Bannissez le token pass-through en revue de code, comme vous bannissez le SQL construit par concaténation. C'est l'injection SQL de l'identité des agents : pratique, partout, et faux.
  • Gardez les permissions des agents en lecture seule par défaut et verrouillez chaque chemin mutateur, la même posture que j'ai défendue côté infrastructure dans le billet Agents on Call sur la gateway. L'authentification vous dit qui est l'agent ; elle ne dit rien de ce qu'il devrait avoir le droit de faire.

Le point plus large : chaque mois, un nouvel élément de « les entreprises ne peuvent pas adopter les agents à cause de X » se résout discrètement dans une issue GitHub quelque part. L'auth était le plus gros X. Il y a un an, la réponse honnête à « comment nos agents sans supervision s'authentifient-ils auprès des serveurs MCP » était un haussement d'épaules. Aujourd'hui, c'est un numéro de SEP, deux méthodes d'authentification client et des tests de conformité dans trois SDK. Nous apprenons tous ce que nous pouvons construire, et comment, un peu plus chaque semaine. Les équipes qui suivent ces jointures à mesure qu'elles se ferment livreront avec un an d'avance sur celles qui attendent un manuel terminé, parce qu'il n'y en aura pas.

À lire ensuite

L'identité n'est que la moitié de la sécurité des agents. IAM for LLM Apps: Least Privilege When the Caller Is a Model couvre la moitié autorisation sur AWS. Sur le site frère, Agent Toolkit for AWS: The Docs Have a New Reader examine ce qui se passe quand l'agent qui consomme votre infrastructure est aussi celui qui lit le manuel, et ercanermis.com tient la carte complète de ce que j'écris et où.

Références