Ceci est le sixième article d’une série en sept parties sur la sécurité des identités en tant que sécurité de l’IA.
Résumé :
Les agents d’IA récupèrent des données en utilisant les autorisations des personnes au nom desquelles ils s’authentifient (vérifiées), mais les envoient vers des espaces de travail partagés où les destinataires disposent d’autorisations mixtes (non vérifiées). Par exemple, l’agent d’un directeur financier dans un canal Slack peut divulguer la rémunération des cadres dirigeants à des analystes juniors. Quatre vulnérabilités critiques (CVSS 9.3-9.4) ont frappé Anthropic, Microsoft, ServiceNow et Salesforce en 2025. Même modèle : récupération autorisée, destinataires non autorisés. La correction des vulnérabilités requiert une autorisation granulaire qui calcule l’intersection des autorisations de tous les destinataires avant que les données ne quittent la couche de récupération, une étape qui se produit une fois le travail d’OAuth terminé.
Le problème
OAuth a été conçu pour un monde plus simple : un utilisateur, une application, un ensemble d’autorisations. Les agents d’IA brisent ce modèle. Ils opèrent dans des contextes partagés où plusieurs personnes voient leurs réponses. Le protocole ne l’avait jamais anticipé. Les plateformes reposant sur celui-ci non plus.
Résultat : votre agent d’IA hérite de l’accès d’un cadre dirigeant, mais diffuse les données à tout le monde. Selon McKinsey, 80 % des entreprises ont déjà rencontré des comportements à risque de la part d’agents d’IA, notamment une exposition inappropriée de données et un accès aux systèmes sans autorisation. Elles ont raison de s’inquiéter.
Comment cela se déroule-t-il en pratique ? Le livre blanc de l’OpenID Foundation sur l’IA agentique décrit ce scénario :
Un directeur financier déploie un agent d’IA dans un canal Slack. L’agent s’authentifie avec les identifiants du directeur financier et hérite de son accès aux données de rémunération, aux documents du conseil d’administration et aux systèmes RH. Un analyste junior demande : « Quel est notre budget de rémunération pour le troisième trimestre ? ». L’agent récupère les feuilles de calcul du budget, les plans de rémunération et les grilles de salaires des cadres dirigeants. Vérification des autorisations : le directeur financier peut-il accéder à ces fichiers ? Oui. L’agent répond au canal. L’analyste junior connaît maintenant le salaire du PDG, tout comme tous les autres membres de ce canal.
L’agent a fonctionné exactement comme prévu. C’est le modèle d’autorisation qui a échoué.
Le modèle : quatre plateformes, un point commun
Entre juin et octobre 2025, quatre vulnérabilités de gravité critique ont révélé une tendance. Ces vulnérabilités ne sont pas identiques, mais elles partagent un point commun : l’autorisation est vérifiée lors de la récupération, et non lors de la sortie.
Anthropic Slack MCP Server, juillet 2025
Johann Rehberger a découvert la première vulnérabilité MCP critique. Lorsque des agents publient sur Slack, la plateforme « déroule » les hyperliens pour générer des aperçus. Un attaquant injecte une invite, ce qui conduit l’agent, fonctionnant avec les autorisations d’administrateur OAuth, à lire des fichiers sensibles et à embarquer ces données dans une URL. Les bots d’aperçu de Slack récupèrent l’URL, ce qui permet une exfiltration sans clic. Anthropic a archivé le serveur plutôt que d’y apporter un correctif. Récupération : autorisations d’administrateur (vérifiées). Destination de sortie : serveur de l’attaquant (non vérifié).
Microsoft 365 Copilot (EchoLeak), juin 2025
Aim Security a découvert la première attaque sans clic contre un agent d’IA en production. Un attaquant envoie un e-mail avec des instructions cachées ; le destinataire ne l’ouvre jamais. Le moteur RAG de Copilot ingère la charge utile avec les fichiers SharePoint et OneDrive, puis encode les données sensibles dans une URL sortante contournant la politique de sécurité du contenu. Les chercheurs parlent de « violation du périmètre du LLM » : l’agent a aplati les entrées non fiables avec des données fiables sans isoler les zones de confiance. Microsoft a déployé un correctif, mais le modèle persiste. Récupération : autorisations M365 de la victime (vérifiées). Destination de sortie : URL de l’attaquant (non vérifiée).
Plateforme d’IA de ServiceNow (BodySnatcher), octobre 2025
Aaron Costello d’AppOmni a découvert que Virtual Agent et Now Assist faisaient confiance à un secret codé en dur et à une adresse e-mail pour la liaison de comptes. Un attaquant connaissant uniquement l’adresse e-mail d’une cible pouvait se faire passer pour n’importe quel utilisateur, y compris les administrateurs, contournant complètement le MFA. Une fois l’identité de l’utilisateur usurpée, les attaquants invoquent des agents d’IA disposant de tous les privilèges de la victime pour accéder aux enregistrements ITSM ou déclencher des workflows à privilèges. Aaron Costello a déclaré qu’il s’agissait de « la vulnérabilité basée sur l’IA la plus grave découverte à ce jour ». Récupération : autorisations de l’utilisateur dont l’identité a été usurpée (vérifiées). Identité du demandeur : attaquant (non vérifié).
Salesforce Agentforce (ForcedLeak), septembre 2025
Noma Security a découvert une injection d’invite via des formulaires Web-to-Lead permettant l’exfiltration de données CRM. Un attaquant soumet un formulaire avec des instructions cachées ; lorsqu’un collaborateur interroge ultérieurement l’IA au sujet de ce lead, l’agent exécute les deux requêtes. Pire encore, le domaine my-salesforce-cms.com est resté sur la liste blanche malgré son expiration. Les attaquants l’ont acheté pour 5 $ et ont établi un canal d’exfiltration de confiance. Récupération : autorisations CRM du collaborateur (vérifiées). Destination de sortie : domaine de l’attaquant (non vérifié).
Le point commun : chaque système vérifiait si l’utilisateur invoquant pouvait accéder aux données. Aucun ne vérifiait si tous les destinataires des réponses le pouvaient.
Ce qu’il n’a jamais été demandé à OAuth de faire
Pendant deux décennies, OAuth a fonctionné parce que les applications renvoyaient les données au même utilisateur ayant autorisé l’accès. Les agents d’IA brisent ce modèle. Les agents s’authentifient de différentes manières : avec des identifiants utilisateurs délégués, avec leurs propres identités de service, ou en tant qu’automatisations créées par un utilisateur et partagées avec d’autres. Le modèle varie, mais le problème est le même : ils interviennent dans des contextes partagés où plusieurs personnes voient leurs réponses.
Résultat : l’autorisation a lieu lors de la récupération, mais aucune vérification n’a lieu lors de la sortie. Les contextes multipublics nécessitent l’extension d’OAuth avec une autorisation tenant compte du public cible. Dans les spécifications OAuth, le terme « public cible » fait référence à l’API cible. Ici, nous faisons référence aux personnes qui voient les réponses de l’agent.
OAuth fournit la base. L’étendre pour une autorisation tenant compte du public cible est ce qui contribue à rendre les agents d’IA sûrs.
L’architecture qui résout ce problème
Pour corriger ce problème, il faut une autorisation tenant compte du public cible : la couche d’autorisation doit connaître le public cible avant la récupération et calculer l’intersection des autorisations en temps réel. L’agent ne répond qu’avec les données que chaque membre du public cible est autorisé à voir.
L’architecture nécessite trois composants fonctionnant ensemble :
Moteur d’autorisations granulaire. Modélise les autorisations comme des relations, et non comme des rôles statiques. Calcule l’intersection de ce à quoi tous les membres du public cible peuvent accéder en quelques millisecondes.
Couche de gestion des identifiants. Stocke les tokens OAuth pour les applications connectées. Émet des identifiants limités pour les agents en fonction de l’intersection des autorisations calculée.
Gouvernance des identités. Assure l’exactitude du graphique des autorisations grâce à un examen et à une correction continus. Sans autorisations exactes, le calcul de l’intersection produit de mauvaises réponses.
Flux d’intersection des autorisations
L’idée clé : les données sur le salaire du PDG ne sont jamais extraites en premier lieu. Le token émis à l’agent ne peut pas y accéder. Il ne s’agit pas d’un filtrage après récupération, mais d’une limitation avant récupération.
Pourquoi ne pas simplement utiliser la DLP ? La prévention des pertes de données (DLP) détecte les données sensibles après leur apparition dans la réponse. Une autorisation granulaire empêche toute récupération. La DLP est la ceinture de sécurité. La récupération limitée permet de ne pas foncer dans le mur.
Comment Okta et Auth0 rendent cela possible
Fine Grained Authorisation (FGA)
Un contrôle RBAC traditionnel attribue des rôles statiques. FGA modélise les autorisations en tant que relations : « Le VP ventes peut consulter les données budgétaires, car il est membre du canal financier ». Ce graphique des relations rend possible le calcul de l’intersection. Lorsque l’agent doit savoir à quelles données tous les membres du canal peuvent accéder, l’API batchCheck de la FGA répond en quelques millisecondes pour des milliards de relations.
Token Vault stocke des tokens d’actualisation OAuth pour n’importe quelle application SaaS et gère automatiquement le cycle de vie des tokens. La couche d’orchestration récupère les tokens dans le coffre-fort et émet des identifiants limités pour les agents en fonction de l’intersection des autorisations calculée.
Lorsque des agents couvrent plusieurs applications, l’autorisation doit également les couvrir toutes. Cross-App Access étend OAuth en transférant le consentement et l’application des politiques au fournisseur d’identité, offrant au service IT de l’entreprise un contrôle centralisé sur les connexions agent-application.
Une autorisation en temps réel n’est précise que dans la mesure où les données d’autorisation sous-jacentes le sont. Identity Governance aide à garantir que les autorisations sont examinées et corrigées en permanence. Lorsque les autorisations dérivent ou que des comptes orphelins s’accumulent, le calcul de l’intersection produit des réponses erronées. La gouvernance assure l’exactitude du graphique des autorisations.
L’exposition réglementaire
Articles 32 et 5(1)(f) du RGPD. L’article 32 exige des « mesures techniques et organisationnelles appropriées » incluant la protection contre « la divulgation non autorisée ou l’accès à des données à caractère personnel ». L’article 5(1)(f) impose un traitement « d’une manière qui assure une sécurité appropriée ». Lorsqu’un agent d’IA révèle des informations d’identification personnelle de collaborateurs à des utilisateurs internes non autorisés, les deux articles s’appliquent. Les amendes peuvent atteindre 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial.
Section 1798.150 de la loi CCPA. En Californie, le droit privé d’action permet aux consommateurs d’engager des poursuites judiciaires lorsque des informations personnelles « font l’objet d’un accès et d’une exfiltration, d’un vol ou d’une divulgation non autorisés en raison du non-respect par l’entreprise de l’obligation de mettre en œuvre et de maintenir des procédures de sécurité raisonnables ». Une surexposition interne via des agents d’IA pourrait satisfaire à ce critère. Dommages-intérêts légaux : 100 à 750 $ par consommateur et par incident.
Section 404 de la loi Sarbanes-Oxley. La section 404 exige que les organismes publics « établissent et maintiennent une structure de contrôle interne adéquate ». Lorsque des agents d’IA disposant des autorisations de cadres dirigeants peuvent révéler des informations importantes non publiques à des collaborateurs non autorisés, votre capacité à démontrer des contrôles adéquats est sérieusement compromise. Les auditeurs pourraient signaler cela comme une faiblesse significative.
Comme les recherches de McKinsey le confirment, 80 % des entreprises ont déjà rencontré des comportements à risque de la part d’agents d’IA, notamment une exposition inappropriée de données. Le calcul de l’intersection des autorisations par la FGA avant la récupération contribue à répondre directement à ces obligations de conformité.
La question pour votre prochain contrôle de sécurité
Demandez à votre équipe sécurité : « Pour chaque agent d’IA déployé dans un espace de travail partagé, pouvons-nous démontrer que les réponses de l’agent se limitent aux données que chaque membre de cet espace de travail est autorisé à voir ? »
Si la réponse est non, une violation réglementaire pourrait vous être reprochée.
Aujourd’hui, des technologies existent pour résoudre ce problème. Découvrez comment Okta et Auth0 sécurisent les agents d’IA sur okta.com/fr-fr/ai et auth0.com/fr/ai, téléchargez le livre blanc Sécurisation des agents d’IA ou contactez votre représentant Okta pour évaluer les lacunes d’intersection des autorisations dans vos déploiements d’IA.
Suivant : le septième article rassemble les six défis d’identité dans un framework unifié.
