Les notes développeur Google Workspace du 12 octobre 2026 ajoutent une règle pour les clients OAuth 2.0 qui appellent les serveurs Model Context Protocol (MCP) de Google. Pour Gmail MCP, le client doit être déclaré avec l’option « Use this client for an AI-powered agent » dans Google Auth Platform > Clients. À partir du 11 novembre 2026, les serveurs MCP rejetteront les requêtes provenant de clients non marqués.
Le titre de l’actualité peut facilement induire en erreur : Google n’annonce pas le blocage de toutes les applications Gmail API. Une application classique qui utilise uniquement les API REST Google Workspace et n’agit pas comme agent IA n’est pas touchée par ce changement. La frontière annoncée est l’appel au serveur MCP avec un client OAuth identifié comme agentique. Cette précision évite de modifier en urgence les clients OAuth de sauvegarde, de CRM ou d’automatisation qui n’utilisent pas MCP.
L’enjeu dépasse la case à cocher : donner à un agent IA l’accès à une boîte mail lui donne potentiellement accès à des conversations, pièces jointes et identités de tiers. OAuth matérialise ce pouvoir. Le choix de la boîte, des scopes, des tokens et des actions autorisées doit être traité comme une décision de sécurité.
1. Ce que change exactement la note du 12 octobre
Google précise deux jalons. Dès le 11 novembre 2026, les serveurs MCP Google Workspace refuseront les requêtes d’une application dont le client OAuth n’a pas été marqué « agentique ». Les clients qui ne sont pas marqués au 12 novembre resteront non agentiques et ne pourront pas appeler ces serveurs ; pour continuer à utiliser MCP après cette date, Google demande de créer un nouveau client OAuth marqué et de mettre l’application à jour. Ne comptez donc pas sur une modification tardive d’un ancien client comme seul plan de continuité.
La note couvre plusieurs serveurs Google Workspace MCP, dont Gmail, Drive, Docs, Sheets, Slides et Calendar. Elle ne transforme pas toutes les intégrations Workspace en agents. Google conseille explicitement de séparer le client OAuth de l’agent de celui des fonctions non agentiques lorsqu’une application utilise aujourd’hui le même client pour les deux. Seul le client destiné à MCP doit être marqué ; l’autre reste dédié aux appels ordinaires.
| Intégration | Effet de la règle annoncée | Action pertinente |
|---|---|---|
| Agent qui appelle le serveur Gmail MCP | Client OAuth marqué obligatoire | Vérifier ou créer un client agentique avant l’échéance |
| Application qui utilise seulement Gmail REST API | Pas concernée par cette nouvelle obligation MCP | Conserver ses contrôles OAuth existants |
| Produit combinant agent MCP et fonctions REST classiques | Client partagé déconseillé par Google | Séparer les deux clients et leurs responsabilités |
| Service account avec délégation de domaine pour une API | Mécanisme distinct de l’annonce MCP | Auditer séparément portée et autorisations de délégation |
Le serveur Gmail MCP officiel est, à cette date, en Developer Preview. L’annonce du 12 octobre ne vaut pas disponibilité générale. Avant une utilisation métier, vérifiez l’éligibilité au programme, le support, les engagements et les contrôles de sécurité réellement proposés à votre organisation.
2. Comment Gmail MCP donne des capacités à un agent
MCP fournit une interface standardisée entre une application IA et des outils d’un service. Dans ce cas, l’hôte de l’agent se connecte au serveur distant de Google, gmailmcp.googleapis.com, tandis que OAuth 2.0 autorise l’accès au compte de l’utilisateur. Un client OAuth identifie l’application ; le consentement et les scopes déterminent les droits accordés. L’agent ne reçoit pas automatiquement « tout Gmail » du simple fait d’être marqué comme agentique.
La référence des outils Gmail MCP publie notamment recherche de fils, lecture de messages et de fils, liste des libellés et brouillons, création de brouillon, ajout et retrait de libellés. Aucun outil d’envoi direct ni de suppression n’apparaît dans cette liste publiée. Cela ne signifie pas qu’un agent est sans risque : lire un message confidentiel ou modifier ses libellés peut déjà avoir un impact ; la liste des outils peut aussi évoluer pendant la préversion. Réévaluez-la avant chaque déploiement.
Il faut distinguer outils MCP exposés et scopes OAuth accordés. La procédure Google de configuration cite gmail.readonly et gmail.compose pour son exemple. Or gmail.compose est décrit par Google comme permettant de gérer les brouillons et d’envoyer des emails au niveau de l’API Gmail, même si le jeu d’outils MCP publié ne comporte actuellement pas d’action d’envoi. L’étendue d’un scope est une borne d’autorisation, pas la description exacte des outils visibles aujourd’hui. Une revue de sécurité doit examiner les deux.
3. Pourquoi l’accès à une boîte est un choix de sécurité majeur
Une boîte contient plus que des messages écrits par son propriétaire : demandes de clients, données personnelles, devis, pièces jointes, codes de réinitialisation et fils de discussion avec des personnes qui n’ont jamais consenti à interagir avec l’agent. Même un agent seulement lecteur peut résumer ou transférer du contexte vers un autre système selon la façon dont l’application est conçue. Définissez quelles données sont envoyées au modèle, où elles sont traitées et combien de temps elles sont conservées.
Un email entrant constitue aussi une entrée non fiable. Il peut contenir des instructions formulées pour détourner l’agent : « ignore les règles précédentes », « ouvre ce lien » ou « copie les derniers messages ». Google avertit explicitement du risque d’injection indirecte de prompt dans sa configuration de sécurité MCP. Le texte d’un message doit être traité comme une donnée à analyser, jamais comme une nouvelle consigne d’administration.
La case « agent IA » identifie le type de client pour la politique MCP de Google. Ce scénario d’accès externe diffère des fonctions intégrées Gmail AI Inbox et AI Overviews dans la recherche Gmail. Elle ne constitue pas, à elle seule, une sandbox, une approbation humaine ou une garantie contre l’exfiltration. La protection vient de plusieurs décisions complémentaires : périmètre de la boîte, scopes, contrôle des outils, filtrage des contenus, validation des actions et possibilité de révoquer rapidement l’accès.
4. OAuth, consentement et scopes : où commence le moindre privilège ?
Le flux OAuth combine plusieurs objets qu’il faut documenter séparément : client ID pour identifier l’application, client secret pour l’application confidentielle, consentement de l’utilisateur, access token de durée limitée et éventuellement refresh token pour prolonger l’accès. Le secret client n’est pas un droit permanent sur toutes les boîtes ; le token représente une autorisation concrète liée à des scopes et à un compte. Confondre ces rôles conduit à laisser des secrets dans un dépôt ou à accorder trop de droits.
La liste officielle des scopes Gmail montre la différence entre gmail.metadata (métadonnées, sans corps), gmail.readonly (lecture), gmail.compose (brouillons et envoi), gmail.send (envoi) et gmail.modify (lecture et modification étendues). Le scope https://mail.google.com/ est encore plus large, notamment pour la suppression permanente ; Google recommande de ne l’utiliser que si cette capacité est réellement nécessaire. Plusieurs scopes Gmail sont classés restreints et peuvent déclencher des exigences de vérification ou d’évaluation selon le mode de distribution de l’application.
Moindre privilège signifie demander le scope requis par la fonction réellement utilisée, sur un nombre limité de comptes, pendant la durée nécessaire. Un agent qui classe des demandes doit-il lire l’historique entier, ou seulement les fils soumis par l’utilisateur ? Un assistant de réponse peut-il se limiter à créer un brouillon à valider ? Un agent qui n’a besoin que de métadonnées ne devrait pas recevoir la lecture du corps par commodité. Vérifiez toutefois les scopes que le serveur MCP exige pour les outils choisis : réduire les droits ne doit pas être promis sans test de compatibilité.
Google recommande la séparation des clients OAuth si le même produit possède une fonction IA MCP et une fonction REST classique. Créez des clients distincts aussi pour développement, test et production lorsque les environnements ont des utilisateurs et données différents. Utilisez des projets et écrans de consentement adaptés, des URI de redirection explicites et des propriétaires identifiés. Cette séparation rend l’audit, la rotation et la révocation plus lisibles ; elle limite aussi l’effet d’une erreur de configuration.
5. Secrets, tokens et accès durable
Un secret client doit rester dans un gestionnaire de secrets ou un stockage sûr côté serveur. Ne le placez ni dans le code, ni dans les journaux, ni dans une configuration d’agent partagée sans contrôle d’accès. Lors d’une rotation, déployez la nouvelle valeur, validez le flux, puis retirez l’ancienne selon les possibilités du client et du fournisseur. La documentation Google sur les bonnes pratiques OAuth demande également de protéger les access tokens et refresh tokens au repos et en transit.
Un refresh token mérite une attention particulière : il peut permettre à l’application d’obtenir de nouveaux access tokens sans intervention immédiate de l’utilisateur. Google précise que, pour obtenir l’accès hors ligne dans le parcours Gmail MCP documenté, la demande d’autorisation doit comprendre access_type=offline ; le seul scope OIDC offline_access ne suffit pas. Une nouvelle autorisation peut demander prompt=consent. Ce mécanisme doit être activé seulement si l’agent a réellement besoin d’un accès entre deux sessions utilisateur.
Définissez un inventaire des tokens par client, utilisateur, environnement et usage. En cas de départ d’un utilisateur, de compromission ou de fin de pilote, révoquez l’autorisation et supprimez les tokens stockés. Préparez aussi le comportement lorsque le refresh token expire ou est révoqué : échec contrôlé, alerte au propriétaire et nouvelle demande de consentement, pas une boucle silencieuse de tentatives.
Ne confondez pas réinitialiser un secret client et révoquer les autorisations utilisateur. Ces gestes agissent sur des couches différentes. Testez votre procédure d’incident de bout en bout : quel administrateur bloque le client, qui retire les tokens, comment vérifier qu’une session existante ne continue plus et comment rétablir l’accès légitime ?
6. Comptes de service et délégation de domaine
Une application peut utiliser un service account pour certaines API Google Workspace. Par défaut, ce compte technique n’obtient pas magiquement la boîte d’un utilisateur. Avec une délégation à l’échelle du domaine, en revanche, un administrateur peut autoriser l’application à agir au nom d’utilisateurs de l’organisation sans consentement individuel. Google décrit ce mécanisme dans sa documentation des identifiants Workspace. Il est puissant et doit être justifié, borné par scopes et audité.
La note du 12 octobre concerne les clients OAuth qui appellent les serveurs MCP Workspace ; elle n’annonce pas une nouvelle obligation MCP pour toute délégation de domaine ou pour les API REST classiques. Ne migrez pas un flux REST vers un service account « pour contourner » le marquage agentique. L’accès de domaine peut élargir les risques au lieu de les réduire. Documentez quels utilisateurs peuvent être représentés, quelles opérations sont possibles et quels administrateurs peuvent modifier la délégation.
Évitez aussi d’utiliser le compte Gmail personnel d’un administrateur ou une boîte de direction comme compte de test. Choisissez des comptes pilotes avec données contrôlées, puis mesurez les droits réellement nécessaires avant d’ouvrir la production. Une boîte partagée de fait, obtenue en donnant à l’agent le compte d’une personne, pose un problème de responsabilité et de continuité.
7. Audit, journalisation et révocation
Google indique que les échecs de connexion au serveur MCP peuvent être examinés dans les événements de journal OAuth de l’outil d’investigation de sécurité. Les administrateurs Workspace peuvent aussi contrôler l’accès des applications aux données via Sécurité > Accès et contrôle des données > Contrôles des API ; la documentation d’administration décrit notamment les applications approuvées ou restreintes et les scopes Gmail à haut risque. La disponibilité de certains outils avancés dépend de l’édition Workspace.
Dans l’application, journalisez sans contenu sensible superflu : identité de l’utilisateur, client OAuth, outil MCP appelé, horodatage, résultat, identifiant de corrélation et validation humaine éventuelle. Ne consignez pas le corps complet des emails ou les tokens dans des logs de diagnostic. Gardez assez d’informations pour répondre à « quel agent a lu ce fil ? » ou « qui a créé ce brouillon ? », selon les capacités de journalisation disponibles dans votre architecture.
Définissez des alertes pour nouveaux consentements, scopes élargis, appels inattendus, volume inhabituel de lectures et échecs répétés. Examinez périodiquement les clients inactifs et révoquez ceux qui ne servent plus. La révocation doit faire partie du processus normal de fin de projet, pas seulement du plan de crise.
8. Checklist avant le 11 novembre
- Recenser les clients OAuth qui appellent réellement Gmail MCP ou un autre serveur Workspace MCP ; séparer ce périmètre des intégrations REST classiques.
- Vérifier l’option « Use this client for an AI-powered agent » sur les clients MCP concernés. Si elle ne peut être activée, créer un nouveau client marqué et prévoir la migration avant la date limite.
- Séparer les clients utilisés à la fois par l’agent et les fonctions non agentiques ; garder le client REST existant pour ces dernières.
- Revoir les utilisateurs, les scopes, les outils MCP et les chemins de données vers le modèle. Réduire l’accès et prévoir une validation humaine pour les actions sensibles.
- Protéger secrets et tokens ; tester rotation, expiration, révocation et nouvel écran de consentement.
- Isoler développement, test et production, avec comptes pilotes et journaux identifiables.
- Tester après configuration : connexion MCP, recherche, lecture et création de brouillon selon le besoin, puis vérifier les journaux OAuth et applicatifs.
- Documenter le responsable du client, le support utilisateur, la revue périodique des autorisations et la procédure d’arrêt d’urgence.
Conclusion
L’obligation annoncée par Google est ciblée : elle identifie les clients OAuth qui utilisent les serveurs MCP, dont Gmail MCP, à partir de novembre 2026. Les applications classiques qui appellent uniquement les API REST ne sont pas concernées par cette nouvelle règle. Pour un client mixte, Google recommande deux identités OAuth distinctes.
Le vrai travail de sécurité commence ensuite. Donner accès à une boîte à un agent revient à décider quelles conversations il peut lire, quelles actions il peut préparer et pendant combien de temps il garde ce pouvoir. Inventaire, scopes minimaux, tokens protégés, audit et révocation doivent précéder toute généralisation. Pour situer cette décision parmi les autres contrôles de messagerie, voir nos articles sur l’authentification email et sur l’audit de messagerie Dharmail.
Sources
- Google Workspace Developer Release Notes, 12 octobre 2026, section Gmail API.
- Google, « Configure the Gmail MCP server » et référence des outils MCP.
- Google, « Choose Gmail API scopes ».
- Google, « Configure security for Google Workspace MCP servers ».
- Google, bonnes pratiques OAuth et contrôle administrateur des applications.