Il s'agit du deuxième blog d'une série en sept parties sur la sécurité de l'identité en tant que sécurité de l'IA.
TL;DR : Une brèche silencieuse s'est propagée dans le monde du SaaS en août 2025 : sans demande de ransomware, sans défiguration spectaculaire. Seulement des identifiants volés, tranquillement oubliés et dangereusement actifs. La cible était Salesloft Drift, une plateforme d'automatisation du marketing qui connecte l'agent de chat Drift IA avec une instance Salesforce ou Google Workspace, entre autres. Les attaquants n'ont pas eu besoin de force brute ; ils ont utilisé des tokens OAuth (clés numériques émises des mois plus tôt) pour infiltrer plus de 700 organisations. Les conséquences ont été massives : les contacts professionnels, les données Salesforce et les clés API internes ont été aspirés. Ce fut l'une des plus importantes brèches SaaS à SaaS à ce jour et a mis en évidence un problème plus profond dans la gestion des identités. Les agents d'IA ne se déconnectent pas, mais leurs identifiants persistent souvent pendant des mois, oubliés et non révoqués. Ces tokens dormants deviennent des bombes à retardement.
La solution commence par une reconceptualisation de l'identité et de l'accès. Les identifiants doivent être de courte durée, automatiquement renouvelés et révoqués dès qu'ils ne sont plus nécessaires. L'autorisation durable doit être assortie d'une expiration intégrée, pas seulement d'une commodité.
L'incident qui prouve le problème
En août 2025, l'une des brèches SaaS les plus importantes de mémoire récente s'est produite. Salesloft Drift a été violé sans code d'exploitation, vulnérabilités zero-day ou malware. Les attaquants n'en avaient pas besoin. Ils avaient seulement besoin de temps et de jetons. Les attaquants ont d'abord accédé au compte GitHub de Salesloft entre mars et juin 2025. Ensuite, ils ont implanté des workflows malveillants et ont accédé à l'environnement AWS de Drift. Une fois à l'intérieur, ils ont volé des tokens OAuth pour les intégrations de technologies des clients de Drift. Plus de 700 organisations ont été exposées.
Mais la véritable vulnérabilité n'était pas le vol, mais sa longévité. Ces tokens, dont beaucoup avaient été émis des mois auparavant, étaient toujours actifs. Ils n'avaient pas expiré ni été révoqués. Ainsi, lorsque des acteurs malveillants ont commencé à les utiliser en août pour accéder aux données de services connectés tels que Salesforce, Cloudflare, Palo Alto Networks et Zscaler, l'activité est apparue légitime. Les tokens étaient valides. Les services leur faisaient confiance. L'automatisation semblait normale.
Il n'était pas nécessaire de forcer l'entrée, car les portes n'avaient jamais été verrouillées.
Cet épisode est un cas d'école de « dérive d'autorisation », un risque de sécurité croissant où les identifiants des machines survivent aux workflows et aux intentions commerciales pour lesquels elles ont été créées. Et ce n'est pas surprenant, étant donné que 51 % des organisations n'ont toujours pas de processus formel pour révoquer ces secrets à longue durée de vie. Avec des identités non humaines qui sont désormais 144 fois plus nombreuses que les humains, cette négligence est un gouffre majeur dans le système.
Résoudre le problème nécessite de repenser la façon dont nous autorisons les communications machine to machine. Les identifiants statiques doivent être remplacés par des tokens à courte durée de vie qui sont renouvelés uniquement lorsque le contexte le permet. Les contrôles d'accès doivent se demander non seulement « ce token est-il valide ? », mais aussi « devrait-il encore être utilisé ? » Et dans les systèmes distribués en évolution rapide, l'autorisation doit s'adapter en permanence pour rester synchronisée avec l'intention. pour rester aligné sur l'intention.
La brèche Salesloft Drift n'a pas exploité une faiblesse dans le code. Elle a exploité une faiblesse dans les hypothèses, à savoir que l'accès, une fois accordé, serait géré de manière responsable. À moins que la gouvernance des identifiants n'évolue, les attaquants n'auront pas besoin de nouvelles tactiques. Ils n'auront qu'à attendre.
Le problème du cycle de vie de l'autorisation
Les agents d'IA ne sont pas des utilisateurs au sens traditionnel du terme. Ils ne se connectent pas, n'effectuent pas une tâche et ne se déconnectent pas. Ils fonctionnent en continu pendant des jours, voire des semaines, en exécutant de longs workflows tels que la réconciliation des données, l'onboarding ou la Formation de modèles. Et pourtant, la plupart des systèmes d'identité fonctionnent encore selon des hypothèses humaines : des sessions avec un début et une fin, des identifiants émis une fois et oubliés.
Ce modèle ne fonctionne plus lorsqu'il est appliqué aux systèmes autonomes. Au-delà de la gestion des connexions utilisateur, l'IAM évolue vers la gestion de la confiance en temps réel entre les personnes, les services et les agents qui agissent en notre nom, à travers les systèmes, sans surveillance directe. The OpenID Foundation appelle cela « exécution asynchrone avec autorité déléguée durable » : des agents fonctionnant indépendamment sous des identités régies et révocables.
En termes pratiques, cela signifie repenser les fondamentaux :
Des identités déléguées qui sont spécialement conçues pour les agents, séparées des identifiants utilisateur.
Un accès continuellement renouvelable, où l'autorisation s'adapte dynamiquement au contexte.
Déprovisionnement instantané sur tous les systèmes lorsque des risques apparaissent : pas de délai, pas de nettoyage manuel.
Des vérifications en temps réel qui valident l'intention au moment de l'action, et pas seulement au moment de l'émission du token.
C'est vers cela que se dirige la sécurité des agents d'IA : l'identité en tant que couche de confiance dynamique pour l'IA.
Et si la prévention n'est pas une motivation suffisante, la réglementation arrive
À partir du 2 août 2026, l'application de l' article 14 de la loi européenne sur l'IA obligera les organisations à prouver que chaque action pilotée par l'IA a été autorisée au moment où elle s'est produite, et pas seulement lorsque les identifiants ont été émis. Ce passage à une responsabilité au moment de l'exécution a un réel poids : les violations pourraient coûter jusqu'à 35 millions d'euros (38 millions de dollars) ou 7 % du chiffre d'affaires mondial.
Les États-Unis vont dans la même direction. Des frameworks tels que la gestion fédérale de l'identité, de la crédibilité et des accès (FICAM) et la règle du programme de sécurité des données du ministère de la Justice commencent à exiger un contrôle du cycle de vie des identités non humaines et un accès automatisé.
L'ancienne façon de penser, avec l'hypothèse que « le token était valide », ne tient plus.
Les auditeurs posent désormais des questions plus difficiles :
« Cet agent a accédé aux données des clients le jour 45. L'employé est parti le jour 30. La tâche s'est terminée le jour 10. Montrez-moi la piste d'autorisation. »
Un système faible pourrait répondre :
« Le token OAuth était valide pendant 90 jours. » Ce n'est plus suffisant.
Un système mature, conscient du cycle de vie, réagit différemment :
« L'agent a opéré sous une identité déléguée unique. » Le jeton a été automatiquement révoqué lorsque la tâche s'est achevée le jour 10. Tous les accès ont été logués, la chaîne de délégation vérifiée et le déprovisionnement s'est produit en quelques secondes. »
Le coût de la dérive d'autorisation
La dérive d'autorisation est la menace silencieuse que la plupart des équipes ne voient pas venir. C'est l'écart entre le moment où quelque chose devrait perdre l'accès et le moment où il le perd réellement. Selon le rapport NHI7 de l'OWASP, les identifiants restent actifs en moyenne 47 jours après qu'ils ne sont plus nécessaires. Cela représente près de deux mois pendant lesquels les attaquants (ou des erreurs imprévues) ont les mains libres.
Les identités non humaines sont désormais plus nombreuses que les identités humaines, dans un rapport de 144 contre 1 dans certaines entreprises. Chaque token persistant lié à un agent d'IA ouvre la porte à un accès non intentionnel, longtemps après la fin de la tâche, le départ de l'employé ou le déplacement de l'intégration.
C'est pourquoi l'autorisation tenant compte du cycle de vie devient essentielle. Elle permet de garantir que l'accès n'est pas simplement accordé et oublié, mais qu'il s'adapte. Les identifiants expirent automatiquement lorsque les workflows sont terminés. L'accès est renouvelé uniquement si le contexte a toujours un sens. C'est la confiance dynamique, et non l'autorisation statique.
Sans cela, les enjeux sont très élevés. Le rapport 2025 d'IBM sur le coût d'une brèche de données estime que le coût moyen mondial d'une brèche est désormais de 4,4 millions de dollars. À moins que l'accès ne soit lié à l'intention et que l'intention ne soit surveillée en temps réel, l'« autorisation durable » devient simplement un autre terme pour désigner un risque caché.
De l'autorisation statique à l'autorisation de cycle de vie
Pour arrêter la dérive d'autorisation, les agents d'IA ont besoin d'identifiants qui s'adaptent aux conditions en temps réel dans lesquelles ils fonctionnent. La plupart des outils de sécurité n'ont pas été conçus pour des agents qui fonctionnent de manière autonome pendant des semaines.
La solution commence par une autorisation tenant compte du cycle de vie : elle vérifie que les identifiants expirent, sont renouvelés ou sont révoqués en fonction du contexte, et pas seulement d'une minuterie prédéfinie. Quatre principes de conception clés permettent d'y parvenir :
Identité déléguée durable : chaque agent d'IA a sa propre identité, distincte des utilisateurs, gouvernée et auditable.
Autorisation continuellement renouvelable : L'accès s'ajuste automatiquement à mesure que la tâche, l'utilisateur ou l'environnement change.
Suppression instantanée de l'accès inter-système : la résiliation de l'accès à un endroit l'arrête partout, rapidement.
Validation de l'autorisation en temps réel : Les actions sont revérifiées par rapport aux politiques actuelles au moment où elles se produisent, et pas seulement lorsque les identifiants ont été émis.
Okta IA agent Lifecycle Management (LCM) framework met ces idées en pratique. Il gère la création d'identité, les contrôles d'autorisation continus et la suppression automatisée de l'accès pour les systèmes d'IA, soutenant des opérations plus sûres et conformes à mesure que l'IA assume plus de responsabilités. Alors que la surveillance réglementaire se renforce et que les agents deviennent plus autonomes, cette approche devient rapidement une exigence, et non un luxe.
Comment Okta et Auth0 concrétisent cela
L’autorisation tenant compte du cycle de vie ne remplace pas l’IAM ; elle l’étend pour répondre aux besoins des systèmes modernes et autonomes. À mesure que les agents d’IA assument davantage de responsabilités à travers les systèmes, les identifiants doivent suivre les mêmes règles que l’accès humain : valides uniquement lorsque cela est nécessaire et révoquées dès qu’elles ne le sont plus.
1. Identité déléguée durable — Gestion du Lifecycle Management des agents d’IA d’Okta
En tant qu'élément de la structure de sécurité des identités, la gestion du cycle de vie des agents d'IA d'Okta enregistre les agents d'IA comme distincts et gouverne ces identités avec des chaînes de délégation claires. Non pas comme des remplaçants d'utilisateurs, mais comme des acteurs non humains gérés avec des politiques adaptées à leurs rôles. Grâce à Okta Identity Governance et Privileged Access, les agents ne reçoivent que ce dont ils ont besoin, quand ils en ont besoin, et sont privés d'accès dès que ce contexte prend fin.
2. Autorisation contextuelle — Auth0 Token Vault + FGA
Auth0 Token Vault émet des identifiants de courte durée, liées à des tâches spécifiques, ce qui minimise la dérive et la persistance des tokens. Auth0 Fine-Grained Authorization (FGA) ajoute une prise de décision dynamique et contextuelle à chaque appel d'API. Pour les actions asynchrones, les frameworks Client-Initiated Backchannel Authentication (CIBA) d'Auth0 vérifient la délégation en direct avant l'exécution, et pas seulement lors de l'émission des identifiants.
3. Révocation continue et visibilité d'audit — Okta Identity Security Fabric
Lorsque l'accès est révoqué, il doit prendre effet partout, instantanément, sinon le potentiel d'exploitation de cet accès demeure. L' Identity Security Fabric d'Okta applique la révocation de signal partagé et les standards ouvertes telles que DPoP (RFC 9449), ce qui permet de garantir que les identifiants révoqués se propagent instantanément dans les écosystèmes SaaS. La propagation en moins d'une seconde permet de s'assurer qu'aucun jeton obsolète ne persiste, et chaque décision est consignée pour une visibilité d'audit complète.
Conclusion
Les agents d'IA sont désormais beaucoup plus nombreux que leurs homologues humains, dans un rapport allant jusqu'à 144 contre 1 dans certaines organisations ! Mais cette échelle s'accompagne d'un fossé dangereux.
La brèche de Salesloft–Drift, ainsi que l'étude de 2025 du NIST sur le détournement d'agents, mettent en évidence un modèle inquiétant : des identifiants valides qui traînent longtemps après avoir dû être révoqués. Le besoin de l'entreprise avait pris fin. Les utilisateurs étaient partis. Mais l'accès est resté.
Le problème n'est pas que les agents d'IA sont trop puissants ; c'est que nos systèmes de gestion de leur accès n'ont pas encore évolué. Ils ont été conçus pour des personnes qui se connectent et se déconnectent, et non pour du code autonome qui s'exécute pendant des semaines tout en effectuant discrètement des tâches sensibles.
L' Identity Security Fabric d'Okta et la pile d'autorisation adaptative d'Auth0 ouvrent une nouvelle voie. Leurs frameworks en évolution montrent à quoi ressemble l'avenir : des agents d'IA avec leurs propres identités, et non des identifiants empruntés, régis par des politiques qui s'adaptent continuellement au contexte en temps réel. L'accès n'est pas seulement accordé au début d'une tâche ; il est constamment réévalué. Et lorsqu'une tâche se termine ou qu'une condition change, l'accès disparaît instantanément. Pas d'attente, pas de nettoyage manuel.
En d'autres termes, il s'agit d'un changement de paradigme :
Les identifiants partagés sont remplacés par des identités déléguées et spécifiques à l'agent.
Les tokens statiques et à longue durée de vie cèdent la place à des identifiants qui se renouvellent ou expirent en fonction du contexte.
Les délais arbitraires sont remplacés par une révocation liée à la logique métier.
Le déprovisionnement manuel est remplacé par des coupures instantanées et automatisées dans tous les systèmes.
C'est plus qu'une mise à niveau de l'IAM, c'est une révolution. L'accès est désormais dynamique, sensible aux workflows, aux rôles et aux tâches. Les identifiants s'adaptent à ce qui se passe en temps réel et disparaissent lorsque leur travail est terminé.
Plus de tokens persistants. Plus d'exposition silencieuse. Juste l'identité comme couche de confiance vivante pour les systèmes autonomes. Tout ce qui est inférieur expose les organisations à des brèches nées non pas de la malveillance, mais de l'inertie.
Suivant : Blog 3 se penche sur la fédération inter-domaines. Comment les agents d'IA peuvent prouver l'autorité déléguée à travers plusieurs organisations, même lorsqu'il n'y a pas de source fiable sur laquelle s'appuyer.
