Sécurité MCP: OAuth, passerelles, sans jetons partagés

La plupart des équipes connectent leur premier serveur MCP en un après-midi. Quelqu’un crée un jeton d’accès personnel, le colle dans le fichier de configuration de Claude Desktop, de Cursor ou de VS Code, et l’agent peut soudain lire des tickets, interroger une base de données ou ouvrir des pull requests. Cet article examine ce qui ne va pas dans cette configuration, ce que la spécification du Model Context Protocol dit de l’autorisation, et un modèle qui permet aux agents d’accéder aux systèmes de l’entreprise sans que personne ne copie un jeton dans un fichier JSON.

Toutes les références à la spécification renvoient à la révision 2026-07-28, que modelcontextprotocol.io indique comme version actuelle au moment de la rédaction (29 septembre 2026).

À quoi ressemble la configuration habituelle

Un serveur MCP local est un processus que le client démarre sur votre ordinateur portable. Le client lui transmet des identifiants via des variables d’environnement. Le README du serveur MCP de GitHub, par exemple, montre une configuration locale de ce type:

{
  "mcp": {
    "servers": {
      "github": {
        "command": "docker",
        "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
                 "ghcr.io/github/github-mcp-server"],
        "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}" }
      }
    }
  }
}

Le serveur lui-même n’est pas en cause. Le README de GitHub recommande des scopes minimaux et un stockage soigneux, et son serveur distant prend en charge OAuth à la place. Les problèmes commencent quand le même schéma se répète sur dix outils et vingt personnes:

Des jetons à longue durée de vie se trouvent dans des fichiers de configuration en clair et des profils de shell sur chaque ordinateur portable qui les utilise. En renouveler un signifie retrouver chaque copie.
Les jetons sont créés avec des scopes larges, parce que personne ne sait à l’avance quels outils l’agent va appeler.
Les équipes partagent le jeton d’un compte de service pour les systèmes où des comptes individuels sont contraignants, si bien que le système en aval voit une seule identité pour tout le monde.
Le serveur local tourne avec les mêmes droits système que l’utilisateur, souvent avec un accès réseau aux systèmes internes.
Aucun registre central n’indique quelle personne, avec quel agent, a appelé quel outil avec quels arguments. Le journal d’audit du SaaS montre le propriétaire du jeton, s’il montre quelque chose.

En mai 2025, Invariant Labs a décrit une attaque dans laquelle une issue malveillante dans un dépôt GitHub public demandait à un agent de récupérer des données dans les dépôts privés de l’utilisateur et de les publier. Les chercheurs ont précisé que le code du serveur MCP de GitHub n’était pas en faute et ont parlé d’un problème d’architecture au niveau du système d’agents: l’agent pouvait atteindre des dépôts privés dont une tâche dans le dépôt public n’avait pas besoin. Leurs mesures d’atténuation: des permissions plus restreintes et la limitation d’un agent à un seul dépôt par session. Ils ont aussi noté que beaucoup d’utilisateurs cliquent sur « Always Allow » lors des confirmations d’outils, ce qui supprime cette protection.

L’outillage local autour de MCP a aussi eu ses propres failles. CVE-2025-6514 dans le paquet npm mcp-remote permettait une injection de commandes système lorsque l’outil se connectait à un serveur MCP non fiable, via une URL d’endpoint d’autorisation forgée. L’avis de GitHub la classe comme critique (CVSS 9,6) et indique les versions 0.0.5 à 0.1.15 comme affectées, avec un correctif dans la 0.1.16. Sur un ordinateur portable qui contient aussi un dossier de jetons d’API, une exécution de code signifie que ces jetons sont exposés eux aussi.

Ce que la spécification MCP dit de l’autorisation

Le chapitre sur l’autorisation est optionnel pour les implémentations, et il s’applique aux transports HTTP. Pour stdio, la spécification indique que les serveurs devraient prendre leurs identifiants dans l’environnement, ce qui est exactement le schéma local décrit plus haut. Sur HTTP avec l’autorisation activée, les règles sont strictes.

Rôles et découverte

Un serveur MCP protégé agit comme un serveur de ressources OAuth 2.1. Le client MCP est un client OAuth 2.1 qui agit pour le compte d’un propriétaire de ressource, en général la personne devant le clavier. Un serveur d’autorisation distinct émet les jetons, et ce peut être votre fournisseur d’identité existant. Les serveurs MCP doivent publier des OAuth 2.0 Protected Resource Metadata (RFC 9728), et les clients doivent utiliser ce document pour trouver le serveur d’autorisation. En pratique, une requête non authentifiée reçoit une réponse 401 avec un en-tête WWW-Authenticate qui pointe vers /.well-known/oauth-protected-resource, et le client poursuit à partir de là. Les clients doivent utiliser PKCE avec S256 lorsqu’ils le peuvent, selon la page des considérations de sécurité.

Liaison d’audience et interdiction de la transmission de jeton

Les clients doivent envoyer le paramètre resource de la RFC 8707 (Resource Indicators) dans la requête d’autorisation comme dans la requête de jeton, avec pour valeur l’URI canonique du serveur MCP. C’est la liaison d’audience (audience binding). Les serveurs doivent vérifier que chaque jeton a été émis pour eux comme audience et rejeter tout le reste. La spécification exclut aussi un raccourci courant: un serveur MCP qui appelle une API en amont a besoin de son propre jeton, distinct, pour cette API, et il ne doit pas transmettre le jeton qu’il a reçu du client.

Le document des bonnes pratiques de sécurité qualifie la transmission de jeton (token passthrough) de « explicitly forbidden » (explicitement interdite) et explique pourquoi. La transmission contourne la limitation de débit ou la validation que le serveur MCP devait appliquer. Elle brouille aussi la piste d’audit: le serveur MCP ne peut pas distinguer les clients, et l’API en aval enregistre une autre identité que celle du serveur qui a réellement envoyé la requête. Et un jeton accepté à plusieurs endroits permet à un attaquant qui compromet un service de passer aux autres.

Le problème du « confused deputy »

Le même document décrit une attaque de type confused deputy (député confus) sur les serveurs proxy MCP. La configuration vulnérable est un proxy qui utilise un seul client ID OAuth statique auprès d’une API tierce, laisse les clients MCP s’enregistrer eux-mêmes de manière dynamique et s’appuie sur le cookie de consentement du tiers. Un attaquant enregistre un client avec sa propre redirect URI, envoie un lien à l’utilisateur, le tiers saute son écran de consentement à cause du cookie, et le code d’autorisation aboutit chez l’attaquant. La correction exigée est un consentement par client au niveau du proxy: tenir un registre des client IDs approuvés par utilisateur, afficher une page de consentement qui nomme le client, les scopes et la redirect URI, et valider exactement les redirect URIs et le paramètre state.

Enregistrement des clients et scopes

Les clients ont besoin d’un client ID avant de commencer. La page sur l’enregistrement des clients cite trois mécanismes: le pré-enregistrement, les Client ID Metadata Documents (le client utilise comme ID une URL HTTPS qui pointe vers ses propres métadonnées) et l’enregistrement dynamique de client (Dynamic Client Registration) selon la RFC 7591. Dans la révision 2026-07-28, le Dynamic Client Registration est marqué comme déprécié et conservé pour la rétrocompatibilité, et les nouvelles implémentations sont orientées vers les Client ID Metadata Documents.

Pour les scopes, la spécification demande aux serveurs d’annoncer les scopes nécessaires à une requête dans le challenge WWW-Authenticate, et aux clients de ne demander que ce dont ils ont besoin. Quand un appel en demande davantage, le serveur répond 403 avec insufficient_scope et le client passe par une autorisation renforcée (step-up). La page des bonnes pratiques cite les scopes génériques (wildcard) et la publication d’emblée de tous les scopes possibles comme des erreurs courantes.

Un humain dans la boucle

Le chapitre sur les outils indique qu’il devrait toujours y avoir un humain capable de refuser des appels d’outils, et que les clients devraient demander une confirmation pour les opérations sensibles et journaliser l’utilisation des outils à des fins d’audit. Les outils peuvent porter des annotations comme readOnlyHint et destructiveHint, mais le schéma les décrit comme des indications sur lesquelles les clients ne devraient pas s’appuyer lorsqu’elles viennent de serveurs non fiables. La décision de bloquer ou de confirmer un outil destructeur doit donc être prise à un endroit que vous contrôlez.

Pour les organisations dotées d’un fournisseur d’identité central, le projet MCP a aussi publié en juin 2026 une extension Enterprise-Managed Authorization. Elle permet à l’IdP de l’entreprise de décider quels serveurs MCP un utilisateur peut atteindre, au moyen d’un Identity Assertion JWT Authorization Grant que le client échange contre un jeton pour le serveur MCP.

Un modèle pratique: un accès par personne via une passerelle

La spécification vous donne les briques. Assemblées pour une entreprise qui a quelques systèmes internes et quelques outils SaaS, elles forment un modèle qui ressemble à ceci.

Chaque agent s’authentifie en tant que la personne qui l’utilise. Le client MCP exécute le flux OAuth auprès de votre fournisseur d’identité, et le jeton obtenu est lié à l’URI de la passerelle (gateway) par le paramètre resource. Aucun jeton de compte de service partagé ne se trouve sur les ordinateurs portables.
Les identifiants en amont restent côté serveur. La passerelle détient les clés d’API ou les jetons de rafraîchissement OAuth pour GitHub, Jira, l’ERP ou la base de données, ou obtient un jeton par utilisateur via un flux comme OAuth 2.0 Token Exchange (RFC 8693). Le jeton du client n’est jamais transmis.
Les scopes sont définis par outil. Lire des tickets et supprimer un projet sont des permissions différentes, et la passerelle ne liste que les outils que les scopes de l’appelant autorisent. La spécification permet explicitement que le résultat de tools/list varie selon l’autorisation de la requête.
Les outils qui écrivent ou suppriment sont désactivés par défaut. Une nouvelle connexion reçoit des outils en lecture seule, et l’accès en écriture est accordé par groupe ou via une autorisation renforcée quand quelqu’un en a besoin.
Les appels à haut risque exigent une décision humaine. Les paiements, les suppressions, les modifications de permissions et les exports en masse restent en attente jusqu’à ce que l’utilisateur, ou un approbateur désigné, confirme. Ce contrôle a lieu à la passerelle, il ne dépend donc ni des réglages du client ni des annotations propres à un outil.
Un seul journal enregistre chaque appel d’outil: la personne, l’agent ou le client ID, l’outil, les arguments (masqués si nécessaire), la décision de la politique et le résultat. Quand quelque chose tourne mal, c’est ce registre qui montre quelle personne et quel agent ont fait l’appel, ce que le journal d’audit du SaaS ne permet généralement pas.

Ce modèle rejoint les recommandations externes. Le OWASP Top 10 for Agentic Applications for 2026, publié en décembre 2025, compte parmi ses catégories Tool Misuse (ASI02) et Identity and Privilege Abuse (ASI03). Les recommandations de la spécification MCP elle-même sur la minimisation des scopes décrivent le même modèle progressif, fondé sur le principe du moindre privilège: un petit ensemble de scopes au départ, avec une élévation lors de la première tentative d’opération privilégiée.

Les serveurs stdio locaux restent pertinents pour les outils qui ne touchent que la machine du développeur. Pour ceux-là, la spécification demande aux clients d’afficher la commande exacte avant de démarrer un nouveau serveur et de l’isoler dans un sandbox. Tout ce qui atteint un système partagé de l’entreprise doit passer par l’autorisation HTTP.

Checklist

Inventoriez chaque serveur MCP utilisé, local et distant, et l’identifiant que chacun détient.
Retirez les jetons d’accès personnels et les clés de comptes de service partagés des fichiers de configuration des clients. Quand un fournisseur propose un serveur MCP distant avec OAuth, utilisez-le.
Pour vos propres serveurs MCP HTTP, publiez les Protected Resource Metadata, validez l’audience du jeton et rejetez les jetons émis pour d’autres ressources.
Ne transmettez jamais le jeton du client en amont. Utilisez un identifiant distinct ou un échange de jeton (token exchange) par API en amont.
Si vous exploitez un proxy OAuth devant une API tierce, mettez en place un consentement par client et des contrôles exacts des redirect URIs.
Définissez les scopes par outil, évitez les scopes génériques et faites démarrer les nouveaux utilisateurs avec des outils en lecture seule.
Exigez une approbation explicite pour les appels destructeurs ou à haut risque, appliquée côté serveur.
Journalisez chaque appel d’outil avec la personne, le client, l’outil, la décision et le résultat, et conservez ces journaux là où votre équipe de sécurité regarde déjà.
Tenez l’outillage des clients MCP à jour, et traitez une connexion à un serveur MCP inconnu comme l’exécution de code inconnu.

Ce que nous construisons

L’endpoint MCP de Flowplane suit ce modèle: les agents se connectent en tant que la personne qui les utilise, les secrets en amont restent à la passerelle, et chaque appel d’outil est journalisé avec une personne et une décision de politique. Il est en phase pilote, et vous pouvez l’essayer gratuitement.

Sécurité MCP: donner aux agents IA l’accès aux systèmes de l’entreprise sans partager de jetons