Ceci est le deuxième article d’une série en sept parties sur la sécurité des identités dans le contexte de la sécurité de l’IA.
Résumé — Une brèche silencieuse s’est produite dans le monde du SaaS en août 2025. Pas de demande de ransomware, pas de défiguration d’un site web qui fait parler d’elle... Simplement des identifiants volés en toute discrétion et dangereusement actifs. La cible était Salesloft Drift, une plateforme d’automatisation marketing qui connecte l’agent d’IA conversationnel Drift à une instance de Salesforce ou de Google Workspace, entre autres. Les attaquants n’ont pas eu besoin de recourir à la force brute, ils ont utilisé des tokens OAuth (clés numériques émises plusieurs mois auparavant) pour infiltrer plus de 700 entreprises. Les retombées ont été considérables : des contacts commerciaux, des données Salesforce et des clés API internes ont été détournés en masse. L’une des plus grandes compromissions de la sphère SaaS à ce jour, elle a mis en lumière un problème plus profond en matière de gestion des identités. Les agents d’IA ne se déconnectent pas et leurs identifiants persistent souvent pendant des mois, oubliés et non révoqués. Ces tokens en dormance 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 des autorisations » — un risque de sécurité croissant où les identifiants machines survivent aux workflows et aux objectifs métier pour lesquels ils ont été créés. Ce n’est pas surprenant, étant donné que 51 % des entreprises n’ont toujours pas de processus formel pour révoquer ces secrets à longue durée de vie. Les identités non humaines étant désormais 144 fois plus nombreuses que les humains, cette négligence représente une lacune majeure 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’entrée en vigueur de l’article 14 de la loi européenne sur l’IA obligera les entreprises à prouver que chaque action pilotée par l’IA a été autorisée au moment où elle s’est produite, et non pas seulement lorsque les identifiants ont été émis. Cette évolution vers la responsabilisation au moment de l’exécution est lourde de conséquences : 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 le programme FICAM (Federal Identity, Credibility and Access Management) et la règle applicable aux programmes 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 des accès automatisés.
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 des autorisations est la menace silencieuse que la plupart des équipes ne perçoivent pas immédiatement. C’est l’écart entre le moment où un accès devrait être supprimé et le moment où il l’est 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, soit près de deux mois pendant lesquels les attaquants (ou des erreurs imprévues) ont le champ libre.
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 Cost of a Data Breach Report 2025 d’IBM estime que le coût moyen mondial d’une brèche s’élève désormais à 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, « autorisation durable » n’est qu’un terme de plus 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 l’écosystème 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 assure la gouvernance de 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 bénéficient d’un accès qu’à ce dont ils ont besoin, quand ils en ont besoin, et cet accès leur est retiré dès que ce contexte prend fin.
2. Autorisation contextuelle – Auth0 Token Vault + FGA
Auth0 Token Vault émet des identifiants à courte durée de vie, liés à des tâches spécifiques, ce qui réduit la dérive et la persistance des tokens. Auth0 Fine-Grained Authorization (FGA) ajoute une prise de décisions 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 active avant l’exécution, et pas seulement lors de l’émission des identifiants.
3. Révocation continue et visibilité sur les audits – Écosystème de sécurité des identités d’Okta
Lorsque l’accès est résilié, la résiliation doit être effective partout, instantanément, sans quoi le risque d’exploitation de cet accès subsiste. L’écosystème de sécurité des identités d’Okta applique la révocation des signaux partagés et des standards ouverts tels que DPoP (RFC 9449), contribuant ainsi à 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 token obsolète ne persiste, et chaque décision est journalisée pour une visibilité complète sur les audits.
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 Salesloft–Drift, ainsi que l’étude 2025 du NIST sur le détournement d’agents, mettent en évidence un schéma inquiétant : des identifiants valides persistent longtemps après qu’ils auraient dû être révoqués. Le besoin métier avait pris fin. Les utilisateurs avaient disparu. Mais l’accès a persisté.
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’écosystème de sécurité des identités d’Okta et la pile d’autorisation adaptative d’Auth0 ouvrent une nouvelle voie. Leurs frameworks évolutifs montrent à quoi ressemble l’avenir : des agents d’IA dotés de leur propre identité, et non d’identifiants empruntés, régis par des politiques qui s’adaptent en permanence au contexte en temps réel. L’accès n’est pas seulement accordé au début d’un emploi ; il est constamment réévalué. De plus, lorsqu’une tâche se termine ou qu’une condition change, l’accès disparaît instantanément. Aucune attente, aucun 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.
