Connecteurs OAuth des assistants IA, portée et consentements

Brancher un assistant d’intelligence artificielle (IA) public sur la messagerie, le stockage ou l’agenda revient à délivrer un jeton d’accès à un tiers qui lit tout ce que l’utilisateur peut lire. Le mécanisme sous-jacent est OAuth (Open Authorization), et sa granularité réelle est bien plus grossière que ce que l’écran de consentement laisse croire. La position défendue ici : consentement réservé aux administrateurs, lecture seule par défaut, écriture refusée sauf besoin nommé.

→ Lire l’explication complète de la marmotte

Ce qu’un scope OAuth délégué donne vraiment

Un connecteur fonctionne en permission déléguée : l’application de l’assistant agit au nom de l’utilisateur, avec ses droits, dans la limite des scopes (périmètres d’autorisation) accordés. Deux conséquences que l’écran de consentement ne montre jamais.

D’abord, le scope se définit par type de ressource, pas par contenu. Sur Microsoft Graph, Files.Read.All en délégué couvre tous les fichiers accessibles à l’utilisateur, y compris chaque site SharePoint et chaque dossier partagé avec lui. Côté Google, gmail.readonly ouvre toute la boîte, sans filtre possible par libellé ou par expéditeur. Demander « l’accès au dossier Projets » n’existe pas dans la plupart des API (Application Programming Interface) de bureautique : on accorde la maison entière.

Ensuite, le scope offline_access (ou son équivalent chez Google, l’accès hors ligne) délivre un jeton de rafraîchissement. L’assistant conserve alors un accès durable, sans session ouverte, stocké chez le fournisseur. Le compte de l’assistant devient un pivot : quiconque s’en empare hérite de la lecture de la messagerie. D’où l’intérêt d’aligner l’authentification de ce compte sur celle de la messagerie elle-même (le sujet de la fédération d’identité est traité à part, dans la rubrique Identités).

Enfin, un connecteur en écriture (Mail.Send, Calendars.ReadWrite) transforme un contenu malveillant lu dans un courriel en action exécutée au nom de l’utilisateur. L’injection de consignes par un document tiers est un sujet à part entière ; il suffit ici de retenir que la lecture seule réduit une injection réussie à une fuite, là où l’écriture en fait une usurpation.

Surface d’attaque des connecteurs et contre-mesures

Consentement illicite (consent phishing) : une application tierce se présente comme « connecteur IA » et obtient les scopes par un seul clic de l’utilisateur. Aucun mot de passe n’est volé, donc aucune alerte d’authentification ne se déclenche. Contre-mesure : désactiver le consentement utilisateur (réglage « User consent settings » dans Microsoft Entra ID, contrôle des accès aux applications dans la console Google Workspace) et passer par un flux de demande d’approbation administrateur.
Dérive des scopes : une nouvelle version du connecteur demande un scope supplémentaire, et l’utilisateur reconsent sans lire. Contre-mesure : consentement donné une fois pour toute l’organisation, par un administrateur, sur une liste de scopes figée ; toute extension repasse par une revue.
Jetons orphelins : l’utilisateur débranche le connecteur dans l’interface de l’assistant, mais la délégation reste inscrite dans l’annuaire. Seule la suppression de l’octroi côté fournisseur d’identité fait foi.
Révocation incomplète : supprimer l’octroi invalide les futurs rafraîchissements, pas les jetons d’accès déjà émis, qui restent valides jusqu’à leur expiration naturelle. En cas de compromission, on révoque aussi les sessions de l’utilisateur.

Vingt ans d’annuaires apprennent que l’application la plus privilégiée d’un tenant est rarement celle qu’on a achetée ; c’est souvent celle qu’un stagiaire a autorisée un vendredi pour « tester un truc ».

Inventorier et révoquer les octrois sur Microsoft Entra ID

Les délégations accordées à un connecteur sont des objets oauth2PermissionGrant interrogeables par Graph. Le champ consentType distingue AllPrincipals (consentement administrateur pour tout le tenant) de Principal (consentement d’un seul utilisateur, donc hors gouvernance). Prérequis : Azure CLI (Command Line Interface) connecté avec un compte disposant au minimum de Directory.Read.All.

# Nom affiché de l'application du connecteur, tel qu'il apparaît dans Entra ID
APP_NAME="Nom exact du connecteur"

# 1. Retrouver l'objet servicePrincipal de l'application
SP_ID=$(az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/servicePrincipals?\$filter=displayName eq '$APP_NAME'&\$select=id" \
  --query "value[0].id" -o tsv)

# 2. Lister les octrois délégués : qui a consenti (principalId), à quoi (scope), comment (consentType)
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/oauth2PermissionGrants?\$filter=clientId eq '$SP_ID'" \
  --query "value[].{id:id, type:consentType, user:principalId, scopes:scope}" -o table

# 3. Supprimer un octroi précis (id issu de l'étape 2) : les jetons de rafraîchissement
#    ne pourront plus être échangés ; les jetons d'accès en cours expirent d'eux-mêmes
GRANT_ID=$(az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/oauth2PermissionGrants?\$filter=clientId eq '$SP_ID' and consentType eq 'Principal'" \
  --query "value[0].id" -o tsv)
az rest --method DELETE --url "https://graph.microsoft.com/v1.0/oauth2PermissionGrants/$GRANT_ID"

Un octroi Principal qui porte Mail.ReadWrite ou Files.Read.All sur une application inconnue mérite une ouverture d’incident, pas un ticket de ménage. L’équivalent Google Workspace passe par la liste des applications ayant accès aux données dans la console d’administration, application par application.

Gouvernance des consentements : le compromis à trancher

Le compromis est net. Un assistant branché sur toute la messagerie répond mieux (il retrouve le fil, la pièce jointe, la réunion) ; ce gain se paie par une copie permanente du droit de lecture de l’utilisateur, détenue par un tiers, sous forme de jeton réutilisable. Le discours commercial sur « l’assistant qui connaît tout le contexte » ne mentionne jamais que ce contexte inclut la boîte du service paie.

La règle à retenir :

Consentement administrateur uniquement, sur une liste blanche de connecteurs d’éditeurs vérifiés.
Lecture seule par défaut ; tout scope d’écriture justifié par un cas d’usage écrit et limité à un groupe.
Exclusion des comptes à privilèges et des boîtes sensibles (direction, ressources humaines, juridique) par affectation restreinte de l’application.
Revue trimestrielle des octrois avec le script ci-dessus, et alerte sur tout nouveau consentement dans les journaux d’audit.

Ce que ce dispositif ne garantit pas : il borne ce que le connecteur peut lire, il ne dit rien de ce que le fournisseur fait des contenus une fois lus (conservation, sous-traitance), qui relève du contrat. Il ne protège pas non plus contre un contenu légitimement lu puis restitué à la mauvaise personne dans une réponse. La supervision de ce que l’assistant produit relève de l’observabilité des modèles de langage en production, et la vue d’ensemble de la rubrique se trouve sur la page IA.

🐝 Ce qui arrive si on s’en passe

Sans inventaire des octrois, le départ d’un collaborateur ne coupe pas l’accès de l’assistant à ses données : désactiver le compte bloque les nouvelles connexions, mais la délégation reste inscrite dans l’annuaire et réapparaît intacte si le compte est réactivé ou transféré. Sans restriction du consentement, les journaux d’authentification ne montrent rien d’anormal lors d’un consentement illicite, puisqu’aucun mot de passe n’est saisi hors du fournisseur d’identité ; l’attaquant lit la messagerie avec un jeton légitime, par des appels d’API qui ressemblent à ceux du connecteur autorisé. Lors d’une réponse à incident, l’absence de liste des scopes accordés empêche de délimiter ce qui a pu être lu, donc de qualifier la violation de données dans les délais.

🦫 Explication de la marmotte 🍫

Quand on relie un assistant d’intelligence artificielle à sa messagerie, un écran demande l’accord de l’utilisateur. En cliquant sur « accepter », l’utilisateur ne donne pas son mot de passe : le service de connexion de l’entreprise remet à l’assistant une sorte de laissez-passer numérique, appelé jeton. Ce jeton dit ce que l’assistant a le droit de faire : lire les messages, lire les fichiers, parfois envoyer des courriels. Le problème, c’est que ces droits sont très larges. « Lire les fichiers » veut dire tous les fichiers que l’utilisateur peut voir, pas un seul dossier. Et l’assistant reçoit souvent un second jeton qui lui permet de renouveler le premier tout seul, pendant des mois. Si un pirate imite un assistant, il obtient le même laissez-passer avec un seul clic d’un employé, sans voler de mot de passe, donc sans déclencher d’alarme. Pour éviter cela, l’entreprise interdit aux employés d’accepter eux-mêmes, et seul un administrateur autorise une courte liste d’assistants connus, de préférence en lecture seule. Elle vérifie aussi régulièrement la liste des autorisations existantes et supprime celles qui ne servent plus. Attention : supprimer une autorisation empêche les renouvellements, mais un laissez-passer déjà délivré reste valable jusqu’à sa date de fin.

Pages voisines

La citent

Connecteurs OAuth des assistants IA, portée et consentements

Elle cite

Connecteurs OAuth des assistants IA, portée et consentements

Connecteurs OAuth des assistants IA, portée et consentements

Ce qu’un scope OAuth délégué donne vraiment

Surface d’attaque des connecteurs et contre-mesures

Inventorier et révoquer les octrois sur Microsoft Entra ID

Gouvernance des consentements : le compromis à trancher

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines