Les applications d’IA transforment la confiance de Google Workspace en chaîne d’attaque moderne

La sécurité de Google Workspace a atteint un point de friction, malgré des années de mots de passe renforcés, d’authentification multifacteur et de contrôles anti-hameçonnage améliorés. La dernière actualité Google qui préoccupe les équipes de sécurité concerne des accès que les attaquants n’ont pas besoin de dérober directement. Ils peuvent en hériter via une application d’IA approuvée, une session de navigateur compromise ou un jeton OAuth abandonné.

Cette distinction modifie le problème défensif. Les programmes de sécurité se concentrent traditionnellement sur l’arrêt d’un attaquant à l’écran de connexion. Les attaques modernes commencent de plus en plus par un accès que Google considère déjà comme autorisé.

Les outils d’IA accentuent cette tension, car ils nécessitent de vastes connexions pour fournir des réponses utiles et exécuter des actions. Un assistant peut lire Gmail, rechercher dans Drive, consulter Calendar et transférer ses conclusions vers un autre service. Chaque connexion crée une relation de confiance qui peut survivre à un changement de mot de passe et rester active sans interaction évidente de l’utilisateur.

La leçon immédiate n’est pas que chaque outil d’IA est malveillant. C’est que l’autorisation est devenue une composante du périmètre de l’entreprise. Une récente analyse de Material Security, relayée par BleepingComputer, estime que de nombreuses organisations la traitent encore comme un simple bruit de fond administratif.

L’incident Vercel d’avril 2026 montre pourquoi cette approche ne suffit plus. Selon les informations publiées autour de la compromission, les attaquants ont d’abord compromis un fournisseur tiers d’IA. Ils ont ensuite utilisé sa connexion autorisée pour atteindre le compte Google Workspace d’un employé de Vercel.

L’attaque ne correspondait pas au scénario familier d’un individu contournant les défenses de connexion de Vercel. La confiance a franchi des frontières organisationnelles via une intégration qu’un utilisateur avait auparavant approuvée.

L’actualité Google déplace l’attention des mots de passe volés vers les accès hérités

Le changement important n’est pas une nouvelle vulnérabilité Google, mais une méthode plus efficace pour exploiter des accès légitimes.

OAuth est un cadre d’autorisation qui permet à une application d’accéder à des ressources sélectionnées dans un autre service. Il permet, par exemple, à un outil de planification de lire un calendrier sans recevoir le mot de passe Google de l’utilisateur.

Cette séparation offre de réels avantages en matière de sécurité. Les utilisateurs n’ont pas à partager leurs identifiants avec chaque service connecté. Les administrateurs peuvent également restreindre les applications, examiner les périmètres demandés et révoquer les autorisations.

Le même modèle crée une cible de valeur. Un jeton OAuth représente une permission qui a déjà franchi un processus d’approbation. Toute personne qui vole ou contrôle ce jeton peut agir par l’intermédiaire de l’application approuvée, dans la limite des périmètres qui lui ont été accordés.

Le rapport sur les risques OAuth de Material Security a examiné des environnements Google Workspace de production et constaté une vaste surface d’autorisation distribuée. Ses conclusions publiques citent une médiane de 1 807 connexions d’applications OAuth par entreprise.

Le rapport indique également que 47,2 % des autorisations observées n’avaient pas été utilisées depuis plus de 90 jours. Parmi ces autorisations dormantes, 1 526 conservaient encore un accès complet à Gmail.

Ces chiffres proviennent du jeu de données clients d’un fournisseur de sécurité, et non d’un recensement représentatif de tous les locataires Workspace. La taille de l’entreprise, le secteur et le niveau de maturité de sécurité existant peuvent tous influer sur les totaux. Les résultats révèlent néanmoins un problème structurel : d’anciennes autorisations restent fréquemment valides après la disparition de leur finalité métier.

L’adoption de l’IA accélère cette accumulation. Material a classé 356 applications publiques dans sa catégorie IA et automatisation. L’entreprise indique que 325 sont apparues pour la première fois dans les environnements analysés après le 1er janvier 2024.

Cela signifie que 91 % de la population observée d’applications d’IA est arrivée en l’espace de 16 mois. Plus de la moitié de ces applications détiendraient des périmètres sensibles ou restreints.

Un périmètre définit ce qu’une application peut consulter ou modifier. Des périmètres étendus peuvent permettre à une application de lire des e-mails, d’examiner le contenu de Drive, d’envoyer des messages ou de supprimer des informations.

Les organisations sont donc confrontées à un difficile problème de classification. Une demande d’accès à Drive peut soutenir un assistant de recherche utile. Cette même permission peut exposer des contrats, des documents stratégiques, des identifiants et des dossiers clients si l’application est compromise.

La menace ne nécessite pas qu’une application soit malveillante dès le départ. Un fournisseur légitime peut devenir le point d’entrée après la compromission d’un appareil d’employé, d’un compte développeur, d’une clé de signature ou d’un environnement cloud.

Cette possibilité transforme l’approbation habituelle d’une application en décision de chaîne d’approvisionnement. L’utilisateur voit un écran de consentement, mais l’organisation hérite des futures défaillances de sécurité du fournisseur.

Un outil d’IA compromis peut franchir deux frontières de sécurité

L’incident Vercel illustre comment un attaquant peut passer par un fournisseur d’IA au lieu d’attaquer directement la cible finale.

Vercel a révélé un incident de sécurité en avril 2026 impliquant un outil d’IA tiers compromis et le compte Google Workspace d’un employé. Les informations publiques ont identifié ce fournisseur comme Context.ai.

Selon les informations disponibles, un employé de Vercel avait connecté AI Office Suite de Context.ai en utilisant une identité professionnelle. La connexion avait reçu de larges autorisations Google Workspace.

Un acteur malveillant a ensuite pris le contrôle d’accès pertinents détenus par Context.ai. Cet accès aurait fourni une voie vers le compte Workspace de l’employé, puis vers les systèmes internes de Vercel.

La séquence a créé deux expositions liées à la chaîne d’approvisionnement. Context.ai dépendait de ses propres identités d’employés et de son infrastructure. Vercel dépendait à son tour de l’intégrité de l’application OAuth de Context.ai.

Des chercheurs indépendants ont attribué la compromission initiale de Context.ai à une infection par infostealer. Un infostealer est un logiciel malveillant conçu pour collecter des mots de passe, des cookies de navigateur, des jetons et d’autres éléments d’authentification.

Des rapports ont lié cette infection à un logiciel présenté comme un exploit Roblox. Toutefois, tous les détails de la compromission initiale n’ont pas été confirmés de manière indépendante par Vercel.

Ce que Vercel a confirmé importe davantage pour la planification en entreprise. L’autorisation existante d’une application tierce a aidé l’attaquant à atteindre le compte Workspace professionnel d’un employé.

L’attaquant aurait accédé à des variables d’environnement qui n’étaient pas désignées comme sensibles. Vercel a conseillé aux clients concernés d’auditer l’activité et de renouveler les identifiants exposés.

Un récit contemporain a rapporté que l’attaquant demandait un paiement pour les données volées. Vercel a fait appel à Mandiant, informé les forces de l’ordre et contacté un groupe limité de clients touchés.

Vercel a également indiqué que les variables d’environnement sensibles étaient chiffrées au repos et n’avaient pas été consultées. Ses projets open source, notamment Next.js et Turbopack, n’auraient pas été affectés.

L’incident ne devrait pas être réduit à l’affirmation qu’OAuth a lui-même échoué. OAuth a exécuté l’autorisation que les utilisateurs et les administrateurs avaient permise.

L’échec est apparu dans l’ensemble de la chaîne de confiance. Un fournisseur a été compromis, une application détenait un accès étendu, et cet accès atteignait une identité d’entreprise de grande valeur.

Les défenses traditionnelles de connexion ne couvraient qu’une partie de cette séquence. L’attaquant n’avait pas besoin de répéter la décision de consentement initiale dès lors qu’une autorisation exploitable existait.

Le changement d’un mot de passe peut également laisser intactes certaines autorisations d’application. La réponse devient alors plus complexe qu’une simple réinitialisation des identifiants et la fermeture des sessions actives de navigateur.

Les équipes doivent identifier les jetons existants, les périmètres qu’ils détiennent et les applications connectées qui peuvent encore agir. Elles doivent ensuite révoquer les accès sans interrompre les flux de travail métier nécessaires.

C’est le renversement central de la chaîne d’attaque moderne. L’application conçue pour réduire le partage de mots de passe peut devenir une voie durable de contournement des défenses centrées sur les mots de passe.

Les agents d’IA rendent les enregistrements OAuth habituels moins informatifs

Les agents d’IA peuvent sembler ordinaires dans les journaux d’autorisation tout en se comportant de manière bien moins prévisible que les intégrations conventionnelles.

Une application traditionnelle exécute généralement un ensemble restreint de fonctions. Un service de signature de documents peut récupérer un fichier, collecter des signatures et renvoyer la copie finalisée.

Son comportement peut évoluer, mais les administrateurs peuvent encore comparer les permissions demandées à une finalité relativement stable. Un accès Gmail ou Calendar excessif devrait paraître suspect pour ce type de service.

Un agent d’IA ne suit pas le même modèle comportemental. Sa prochaine action peut dépendre d’une invite utilisateur, du contenu récupéré, des outils disponibles, de la sortie du modèle et d’instructions fournies par un système externe.

Au niveau de l’autorisation, ces différences peuvent disparaître. Une autorisation Drive en lecture seule accordée à un assistant d’IA peut ressembler à celle accordée à un utilitaire documentaire fixe.

L’analyse des agents de Material soutient que les signaux de sécurité se déplacent des autorisations vers le comportement post-autorisation. L’identité du fournisseur et le périmètre restent utiles, mais ils ne peuvent pas décrire entièrement ce qu’un agent généraliste fera.

Le Model Context Protocol, couramment appelé MCP, peut accroître cette incertitude. MCP est une norme permettant de connecter des systèmes d’IA à des outils et à des sources de données externes.

Un agent connecté à MCP peut rechercher dans Workspace, transmettre un contenu sélectionné à un autre outil, le résumer et déclencher une action de suivi. Le flux de travail peut traverser plusieurs services au cours d’une seule demande utilisateur.

Cela soulève plusieurs questions de sécurité auxquelles un écran de consentement ne peut pas répondre. Les administrateurs doivent savoir à quelles informations l’agent a réellement accédé, où il a envoyé ces informations et si son activité correspondait à l’intention de l’utilisateur.

L’injection de prompt ajoute une couche supplémentaire. L’injection de prompt se produit lorsqu’un contenu non fiable manipule les instructions ou l’utilisation d’outils d’un système d’IA.

Un agent pourrait rencontrer des directives hostiles dans un e-mail, un document partagé, une entrée de calendrier ou une page web. S’il traite ce contenu comme une instruction, ses permissions légitimes peuvent devenir le mécanisme d’une activité nuisible.

Ce risque diffère des logiciels malveillants classiques. Aucun exécutable ne doit nécessairement être installé sur l’appareil de l’utilisateur, et le fournisseur d’IA peut rester non compromis.

Le système peut plutôt détourner des outils valides tout en traitant un contenu adversarial. Les contrôles de sécurité doivent distinguer une automatisation autorisée d’une automatisation autorisée qui se comporte dangereusement.

Cela ne signifie pas que chaque agent connecté doit faire l’objet d’une surveillance sans restriction des prompts ou des contenus privés. Une surveillance excessive crée ses propres risques de confidentialité, de conformité et de gouvernance.

Cela signifie que les organisations ont besoin de preuves au niveau de l’activité. Parmi les signaux utiles figurent un volume de téléchargement inhabituel, de nouveaux comportements de transfert, une énumération rapide des boîtes aux lettres, des combinaisons de services inattendues et des accès en dehors du schéma habituel d’un utilisateur.

L’IA augmente également le nombre de connexions nécessitant un examen. Les employés peuvent adopter directement des assistants, souvent avant que les équipes achats ou sécurité ne les évaluent.

Un nom de marque reconnaissable ne garantit pas que l’application figurant sur un écran de consentement appartient à cette marque. Le rapport de Material décrit une application nommée « gamma.com.ai » qui ressemblait au service légitime de présentations Gamma.

Material indique que l’éditeur n’était pas lié à Gamma et cherchait à obtenir un accès dans plusieurs environnements clients. Le rapport présente ce cas comme une usurpation OAuth, où la familiarité visuelle encourage l’approbation.

L’écran d’autorisation affichait toujours un domaine et les permissions demandées. La décision humaine a échoué parce qu’un nom familier a réduit la vigilance.

Cette voie d’attaque ne nécessite aucune fausse page de mot de passe. Elle convainc l’utilisateur d’accorder une autorisation légitime à la mauvaise partie.

La MFA protège la connexion, pas chaque décision qui la suit

L’authentification multifacteur reste essentielle, mais elle ne peut pas valider chaque jeton, application et action du navigateur qui suit une connexion réussie.

La MFA bloque de nombreuses attaques fondées sur les mots de passe, car un mot de passe volé ne suffit pas à lui seul. Les méthodes résistantes au phishing, notamment les passkeys et les clés de sécurité matérielles, offrent une protection plus robuste contre le relais d’identifiants en temps réel.

Google a étendu la prise en charge des passkeys et les contrôles administratifs dans Workspace. Ces mesures réduisent l’exposition aux prises de contrôle de compte classiques.

Pourtant, le consentement OAuth intervient souvent après l’authentification. Un utilisateur se connecte correctement, termine la MFA, puis approuve une application.

Le jeton qui en résulte enregistre une décision autorisée. Sa réutilisation peut ne pas déclencher à nouveau le même défi d’authentification.

Le vol de session de navigateur crée une lacune connexe. Un cookie de session est une donnée qui permet à un service de reconnaître un navigateur déjà authentifié.

Un attaquant qui vole un cookie valide peut hériter de cet état authentifié. Google documente les procédures de réponse aux cookies de session pour enquêter sur les sessions suspectes et forcer les déconnexions.

Les jetons d’application et les sessions de navigateur ne sont pas identiques. Ils démontrent tous deux pourquoi l’événement de connexion ne peut pas définir à lui seul l’ensemble de la frontière de sécurité.

Les attaquants utilisent également le phishing de type adversary-in-the-middle, connu sous le nom d’AiTM, pour relayer les identifiants et les seconds facteurs via une session contrefaite en direct. Cette technique peut capturer la session authentifiée créée après une MFA réussie.

L’authentification résistante au phishing augmente la difficulté, car les identifiants sont liés cryptographiquement au site légitime. Les organisations doivent néanmoins partir du principe que les malwares, les applications compromises et les jetons volés peuvent créer d’autres voies d’accès.

Microsoft a documenté des abus de redirection OAuth impliquant des URL de fournisseurs d’identité de confiance. Ces campagnes manipulent des paramètres de protocole ou des applications connectées afin de diriger les victimes vers des destinations contrôlées par les attaquants.

Le schéma plus large dépasse Google. Microsoft 365, Salesforce, les plateformes de développement cloud et les services de données reposent tous sur des jetons et des intégrations tierces.

Plusieurs campagnes majeures ont ciblé ces relations. Les incidents impliquant Salesloft Drift ont montré comment des jetons d’intégration volés pouvaient fournir un accès indirect aux environnements clients.

Cette comparaison est importante, car elle écarte une explication limitée à Google. Les logiciels d’entreprise fonctionnent de plus en plus comme un graphe de confiance déléguée.

Les défenseurs doivent préserver la MFA tout en élargissant leur modèle. L’authentification répond à la question de savoir si une identité a satisfait à une exigence de connexion. L’autorisation répond à ce que cette identité ou son application connectée peut faire ensuite.

Les équipes de sécurité doivent aussi prendre en compte la persistance. Révoquer une session de navigateur ne révoque pas nécessairement une autorisation d’application. La suspension d’un utilisateur peut laisser subsister des accès connectés nécessitant une enquête distincte.

Les plans de réponse aux incidents devraient énumérer explicitement ces actions. Sinon, une équipe peut réinitialiser des mots de passe, fermer des sessions et conclure à tort que l’accès a pris fin.

Cette réponse élargie est exigeante sur le plan opérationnel. Les grandes organisations peuvent compter des milliers d’autorisations, de comptes de service, de permissions déléguées et de flux d’automatisation.

Tout révoquer n’est pas une politique crédible à long terme. Cela interromprait la productivité et encouragerait les employés à trouver des alternatives moins visibles.

L’objectif défendable est une confiance sélective. Les équipes doivent identifier les applications, vérifier les éditeurs, limiter les portées, surveiller les comportements et supprimer les accès lorsque leur raison d’être expire.

Le compromis oppose une IA utile à une confiance non mesurée

Bloquer chaque intégration réduirait un risque en détruisant les flux de travail connectés qui rendent l’IA d’entreprise utile.

Les assistants IA ont besoin de contexte pour dépasser les réponses génériques. Un assistant qui rédige une mise à jour client peut avoir besoin des e-mails, des notes de réunion, de l’historique du compte et des documents de projet.

Le restreindre à une fenêtre de chat vide réduit l’exposition. Cela supprime aussi une grande partie de la valeur que les employés attendent de l’IA d’entreprise.

Les organisations font donc face à un compromis, et non à une décision de sécurité binaire. Elles doivent autoriser des accès utiles sans laisser les autorisations s’accumuler indéfiniment.

La première étape est la visibilité. Les administrateurs ont besoin d’un inventaire à l’échelle du domaine des applications, autorisations, utilisateurs, portées, éditeurs et activités récentes.

L’inventaire doit distinguer les applications publiques tierces des outils internes. Il doit également identifier les autorisations liées à d’anciens employés, sous-traitants, comptes de test et projets inactifs.

Examiner uniquement les noms ne suffit pas. Les équipes doivent vérifier l’identité de l’éditeur, les domaines de l’application, les emplacements de redirection, les portées demandées et si l’outil a terminé la vérification pertinente de la plateforme.

La vérification n’est pas une garantie permanente. Un fournisseur légitime peut tout de même être compromis, acquis ou modifié après son approbation.

Le contrôle des portées apporte une autre couche de protection. Les applications ne doivent recevoir que les permissions minimales nécessaires à un flux de travail défini.

Un service de transcription ne devrait pas recevoir un accès complet à Gmail sans nécessité claire. Un assistant qui recherche uniquement dans certains dossiers Drive ne devrait pas obtenir automatiquement l’accès à tous les fichiers.

Le temps compte également. Un accès accordé pour une évaluation doit expirer après celle-ci. Les organisations doivent éviter de transformer des expérimentations temporaires en identifiants permanents.

Les administrateurs Google peuvent restreindre l’accès des applications tierces et classer les services comme fiables, limités ou bloqués. Ces contrôles sont plus efficaces lorsqu’ils s’appuient sur un processus d’approbation capable de suivre le rythme des employés.

Un système d’examen qui prend des semaines poussera l’adoption dans l’ombre. Un système qui approuve des noms reconnaissables sans examiner les permissions produira une prolifération des autorisations.

La surveillance comportementale traite ce que l’approbation ne peut pas prédire. Les équipes doivent détecter lorsqu’une application lit soudainement beaucoup plus de données, accède à des utilisateurs inhabituels ou commence à effectuer de nouvelles actions.

C’est particulièrement important pour les agents IA. Leurs capacités généralistes font des descriptions statiques des indicateurs moins fiables du comportement attendu.

Les recherches de Cloud Security Alliance présentent les chaînes OAuth des SaaS IA comme une surface d’attaque systémique pour l’entreprise. Son analyse de la chaîne de confiance relie l’incident Context.ai à d’autres compromissions de jetons en aval.

Le rapport soutient que les entreprises devraient traiter la gestion du cycle de vie OAuth comme une fonction de sécurité de premier ordre. Cela inclut l’émission, l’inventaire, la surveillance, la rotation, la révocation et la réponse aux incidents.

Les équipes de sécurité doivent néanmoins considérer les statistiques des fournisseurs avec prudence. Material vend des produits de sécurité Workspace, et ses recherches étayent le problème auquel répond sa plateforme.

Son jeu de données offre néanmoins des questions vérifiables pour toute organisation. Les administrateurs peuvent mesurer leur propre nombre d’autorisations, leur part inactive, leurs portées sensibles, la croissance des applications IA et leurs lacunes de révocation.

La réponse la plus solide repose sur des preuves recueillies dans le propre tenant de l’entreprise. Un audit local peut confirmer si le schéma signalé s’applique et où se situent les connexions les plus risquées.

Ce que les équipes de sécurité devraient surveiller ensuite

Trois signaux montreront si la défense de Workspace s’adapte à l’autorisation à l’ère de l’IA ou si elle se contente d’ajouter un tableau de bord de plus.

Le premier signal est une meilleure visibilité après attribution des autorisations, de la part de Google et des fournisseurs de sécurité. Les administrateurs ont besoin de plus qu’un enregistrement indiquant qu’une application a reçu une portée particulière.

Ils ont besoin de réponses exploitables sur l’activité ultérieure de l’application. Cela inclut les ressources auxquelles elle a accédé, l’évolution de son comportement et le déplacement éventuel de données entre services connectés.

Google propose déjà des capacités d’enquête et de contrôle des accès, mais la couverture dépend de l’édition, de la configuration et de la télémétrie disponible. Le test essentiel est de savoir si les équipes peuvent retracer les actions d’un agent IA sans réunir des éléments de preuve depuis plusieurs consoles sans lien entre elles.

Si l’enquête au niveau de l’activité devient plus claire, le modèle de sécurité décrit ici bénéficiera d’un soutien pratique. Si les journaux restent centrés sur le consentement initial, les défenseurs continueront d’évaluer des agents dynamiques à partir de métadonnées statiques.

Le deuxième signal concerne la manière dont les fournisseurs d’IA réduisent et gèrent les permissions. Les produits matures devraient expliquer pourquoi chaque portée est nécessaire et proposer des flux de travail utiles avec des empreintes d’autorisation plus réduites.

Ils devraient prendre en charge des sources de données sélectives, des accès de courte durée lorsque cela est possible, une révocation rapide et des enregistrements transparents de l’activité des outils. Ils devraient également séparer l’automatisation destinée aux utilisateurs des actions administratives à haut risque.

Des portées larges par défaut affaibliraient les affirmations selon lesquelles le marché tire les leçons des incidents récents. Des contrôles plus granulaires montreraient que les fournisseurs reconnaissent l’autorisation comme un enjeu de conception produit.

Le troisième signal est de savoir si les organisations mesurent l’exposition OAuth dans le cadre de leurs travaux de sécurité courants. Un examen annuel ne peut pas suivre le rythme auquel les employés adoptent les outils IA.

Les équipes doivent suivre les autorisations inactives, les nouveaux éditeurs, les portées sensibles, les utilisateurs sortants et les changements soudains dans le comportement des applications. Ces mesures doivent figurer dans les examens récurrents de l’identité et de la sécurité cloud.

Les exercices de réponse aux incidents devraient également tester la compromission d’un jeton tiers. Les intervenants doivent savoir comment identifier les utilisateurs affectés, révoquer les autorisations, fermer les sessions, faire tourner les secrets en aval et préserver les preuves.

Les dernières actualités de Google n’établissent pas que Workspace est devenu intrinsèquement dangereux. Elles montrent que les hypothèses de sécurité construites autour de la protection de la connexion ne couvrent plus l’ensemble du chemin vers les données d’entreprise.

Les mots de passe et la MFA restent nécessaires. Ils ne constituent simplement pas le contrôle final une fois que les employés autorisent des applications à agir sur les e-mails, les fichiers, les calendriers et les systèmes connectés.

La question plus difficile est de savoir si les organisations peuvent voir et gouverner cette activité déléguée sans bloquer le travail utile. Les responsables de la sécurité devraient commencer par une mesure directe : combien d’applications connectées peuvent accéder aux données de l’entreprise à l’heure actuelle, et qui est toujours responsable de chaque décision ?