De nombreuses entreprises s’inquiètent à juste titre de l’utilisation d’outils d’IA non approuvés par leurs employés. La pratique du Shadow AI, où les utilisateurs transmettent des données sensibles à des chatbots tels que ChatGPT ou Claude, soulève des préoccupations légitimes. Cependant, ce n’est pas le problème principal à considérer.
Lorsqu’un employé connecte une application d’IA à des plateformes fondamentales comme Google Workspace, Microsoft 365 ou Salesforce, il établit un pont programmatique permanent entre l’environnement de l’entreprise et un tiers. Ce lien demeure même après l’abandon de l’application par l’employé. Si ce tiers est compromis, la connexion direct peut mener à une intrusion dans les systèmes de l’organisation.
Le récent incident lié à la violation de Vercel est un exemple significatif. Un employé de Vercel avait testé l’application d’IA Context.ai, lui donnant accès à son compte Google Workspace. Lors de la compromission de Context.ai, Vercel a subi les conséquences de cette intrusion.
La prolifération de l’IA renforce le phénomène du Shadow SaaS
Le Shadow IT n’est pas un phénomène nouveau, surtout dans un contexte où les entreprises reposent essentiellement sur des applications SaaS accessibles via des navigateurs. Les applications non gérées par les équipes de sécurité constituent un défi de longue date. Toutefois, l’émergence des applications d’IA amplifie cette problématique.
Il existe plusieurs catégories de Shadow IT à surveiller en lien avec les applications d’IA :
-
Applications de l’ombre : Inscriptions par des employés à des applications destinées à des fins professionnelles sans approbation. Cela inclut des inscriptions via des comptes d’entreprise ou personnels.
-
Tenants de l’ombre : Utilisation d’applications par des employés via des comptes personnels, créant ainsi des zones en dehors du contrôle de l’entreprise, même lorsque l’application est approuvée.
-
Extensions de l’ombre : De nombreuses applications d’IA sont accompagnées d’extensions souvent peu fiables, présentant des menaces supplémentaires. Elles ont la capacité d’observer l’activité de navigation au-delà de l’application elle-même.
-
Integrations non déclarées : Connexions OAuth biaisées, même si l’application en question est approuvée, ne sont pas toujours validées dans le cadre de l’intégration avec les applications principales de l’entreprise.
Dans le cas de Vercel, ce problème concerne précisément les intégrations non déclarées. Chaque type de Shadow IT représente un risque considérable pour la sécurité.
La violation de Vercel : un exemple classique des risques associés aux autorisations OAuth
L’incident de Vercel met en lumière les conséquences des intégrations d’IA non contrôlées. L’employé avait relié un produit d’IA de Context.ai à son compte Google Workspace, sans que Vercel ne soit officiellement client de l’application.
Cette situation résulte probablement d’une intégration impulsive, restée peu utilisée et qui a étendu imperceptiblement la surface d’attaque de l’organisation.
En adoptant l’application Context.ai, l’employé a mêlé les systèmes et personnels d’un tiers à ses propres dépendances de sécurité. Après la compromission de Context.ai, conséquence d’une infection par un logiciel malveillant, l’attaquant a pu exploiter les tokens OAuth pour accéder aux comptes clients en aval.
Le compte Google Workspace de l’employé de Vercel, bénéficiant de nombreuses autorisations, avait accès à des tableaux de bord internes, des dossiers d’employés, des clés API, des tokens NPM et de GitHub.
Les attaques visent les intégrations OAuth à grande échelle
La complexité de l’interconnexion OAuth transcende le seul problème des applications d’IA. Les attaquants exploitent cette vulnérabilité depuis un certain temps, et l’intensité des attaques ne cesse d’augmenter :
-
En 2025, les Scattered Lapsus$ Hunters ont mené des attaques de chaîne d’approvisionnement basées sur OAuth, touchant des clients de Salesforce et Google Workspace après la violation de plates-formes comme Salesloft. Plus de 1000 organisations, incluant des entreprises majeures, ont été affectées, entraînant le vol de 1,5 milliard de dossiers.
-
Les clients de Snowflake ont également été touchés suite à une intrusion dans l’entreprise de détection d’anomalies de données Anodot, où l’attaquant a tenté d’accéder aux données de Salesforce.
Les attaquants n’usent pas seulement des connexions OAuth existantes pour leurs attaques de chaîne d’approvisionnement, mais exploitent aussi le phishing ciblant OAuth afin de s’introduire dans les systèmes. La campagne de l’année dernière contre Salesforce a commencé par une technique de phishing à code d’appareil, trompant des victimes pour enregistrer une application contrôlée par des attaquants dans leur espace Salesforce, leur offrant ainsi un accès API complet.
Cette année, une augmentation de 37% des attaques par phishing à code d’appareil a été enregistrée, mettant en circulation plusieurs kits criminels.
Ce schéma révèle : les intégrations OAuth sont devenues une surface d’attaque majeure dans les environnements d’entreprise, et chaque nouvel outil d’IA connecté élargit davantage cette surface.
Les attaques basées sur le navigateur, allant du phishing AITM au vol de session, alimentent actuellement les plus importantes violations de données.
Une gestion des autorisations OAuth essentielle
Le cas de Vercel illustre la profondeur de ce problème. Contrôler les connexions OAuth au sein de l’environnement d’entreprise principal, comme M365 ou Google Workspace, est relativement simple. Chaque plateforme permet aux administrateurs d’auditer et de gérer ces connexions. L’incident de Vercel aurait pu être évité si les employés avaient été empêchés d’ajouter de nouvelles intégrations OAuth sans une approbation administrative.
En revanche, gérer cela à travers toutes les applications SaaS s’avère bien plus complexe. Une surveillance active et un inventaire précis sont cruciaux pour détecter et supprimer les autorisations OAuth non justifiées entravant la sécurité.
Avec la montée en puissance des applications d’IA, les méthodes d’automatisation, tout en étant extrêmement utiles, introduisent également davantage de vulnérabilités potentielles.
Pour garantir une sécurité optimale, les équipes doivent non seulement auditer régulièrement les intégrations OAuth existantes, mais également limiter les nouvelles autorisations sans validation.