Le défi
En février 2026, un développeur utilisant un seul jeu d’identifiants valide a découvert qu’il pouvait accéder à plus de 6 700 aspirateurs robots DJI dans 24 pays¹.
Aucun mot de passe n’a été volé. Aucun système n’a été compromis. La plateforme n’avait tout simplement aucune limite entre les données d’un client et celles d’un autre.
Ce brief examine pourquoi cette faille existe aujourd’hui dans la plupart des architectures d’API d’entreprise, comment les risques s’aggravent lorsque les agents d’IA héritent de ces mêmes identifiants et comment y remédier.
Ce qui s’est passé
Un développeur travaillait sur un projet parallèle avec Claude, en essayant de contrôler son robot aspirateur DJI à l’aide d’une manette PlayStation. Alors qu’il connectait son application au réseau de DJI en utilisant ses propres identifiants légitimes, il est tombé sur quelque chose d’inattendu : il pouvait voir et accéder à tous les autres aspirateurs de la plateforme, soit plus de 6 700 terminaux dans 24 pays.
Il n’avait rien piraté. Il n’avait volé le mot de passe de personne. Il a utilisé le produit conformément à sa conception, et le système n’avait aucune limite entre le terminal d’un client et celui d’un autre.
Ce qui a été exposé : des flux de caméras en direct provenant de l’intérieur de maisons, l’audio de microphones et des plans détaillés élaborés par les capteurs de l’aspirateur.
Le développeur l’a signalé de manière responsable. Il n’a jamais fait un mauvais usage de cet accès. Cependant, un acteur malveillant disposant des mêmes identifiants aurait pu le faire.
La brèche n’a nécessité aucun mot de passe volé, aucun outil de piratage ni aucun accès interne. Un jeu d’identifiants valide suffisait. Personne n’avait défini ce que ces identifiants étaient réellement autorisés à faire.
C’était une barrière manquante, pas une serrure cassée.
Votre exposition
Ce n’était pas un problème IoT de niche. Le même défaut structurel — l’autorisation défaillante au niveau des objets — est classé n° 1 dans le Top 10 OWASP des risques de sécurité des API depuis 2019², ce qui en fait la classe de vulnérabilités des API la plus répandue dans tous les secteurs d’activité.
Deux vecteurs d’exposition auxquels chaque entreprise est confrontée
1. Chaque API que vous publiez présente ce problème de limites
Lorsqu’un utilisateur ou un système se connecte avec succès, la plupart des API permettent par défaut à ces identifiants d’accéder à tous les enregistrements à leur portée. Sans limites d’autorisation explicites, un jeu d’identifiants valide déverrouille tout.
2. Exigences réglementaires
Selon le RGPD et la loi CCPA, tout accès non autorisé à des données à caractère personnel (y compris des vidéos ou des audios domestiques) constitue une brèche devant être signalée, même si aucune donnée n’a été délibérément exfiltrée. Une faille du système permettant un accès est traitée de la même manière qu’un vol actif.
La question n’est pas de savoir si vos identifiants peuvent être volés, mais de savoir si des identifiants volés donnent à un attaquant l’accès à l’ensemble de votre système.
La brèche de DJI se situe à une extrémité du spectre : un seul jeu d’identifiants, aucune limite, 7 000 foyers exposés. À l’autre extrémité, chaque jeu d’identifiants est limité exactement à ses besoins, l’accès est appliqué au niveau de la ressource, et un token volé est inutile sans le terminal qui l’a généré.
La solution n’est pas d’avoir de meilleurs mots de passe, mais de combler le fossé entre ces deux extrémités.
Les risques liés à l’IA
Vos outils d’IA (copilotes internes, assistants orientés clients, agents de workflow automatisés) fonctionnent en appelant des API pour accomplir des tâches. Chaque appel utilise des identifiants. Si ces identifiants n’ont aucune limite quant à ce à quoi ils peuvent accéder, une invite malveillante ou un pipeline de fournisseur compromis pourrait exposer tout ce que l’IA peut atteindre.
La brèche des aspirateurs a duré neuf minutes. Un agent d’IA effectuant des centaines d’appels d’API par minute, sans limite d’accès, pourrait reproduire la même exposition en quelques millisecondes sur tous les systèmes à sa portée.
Brèche IoT ou IA agentique : une même faille à une échelle différente
Dimension | Flotte d’aspirateurs intelligents | Agent d’IA |
Temps d’exposition | 9 minutes | millisecondes |
Systèmes concernés | Flotte unique de terminaux | Chaque API à laquelle l’agent peut accéder |
Déclencheur de l’attaque | Identifiants valides requis | Une instruction manipulée |
Supervision humaine | Détectable dans les journaux | Souvent entièrement automatisé, sans évaluation |
Chaque intégration d’IA que vous déployez aujourd’hui hérite de la même architecture d’identifiants qui a rendu cette brèche possible, sauf si vous la concevez explicitement autrement.
Comment Okta peut vous aider
Okta contribue à éliminer cette faille pour votre personnel existant, vos applications orientées clients et vos agents d’IA. Quatre fonctionnalités :
1. Des identifiants qui expirent dès qu’ils quittent le terminal
Okta émet des identifiants qui sont cryptographiquement liés à un terminal spécifique. S’ils sont copiés ou interceptés, ils ne valent rien. Imaginez une carte d’hôtel qui fonctionne uniquement dans la chambre pour laquelle elle a été programmée.
2. Des agents d’IA qui ne peuvent accéder que ce à quoi ils ont explicitement été autorisés à accéder
Chaque outil d’IA, agent de workflow ou intégration reçoit des identifiants limités exactement aux ressources nécessaires. Si un agent est censé résumer les tickets de support, il ne peut pas accéder accidentellement (ou intentionnellement) à vos dossiers financiers.
3. Un modèle de délégation où les sous-tâches obtiennent des autorisations secondaires
Lorsqu’un agent d’IA transmet une tâche à un autre processus, il ne transmet que l’accès nécessaire à cette tâche. Les chaînes de délégation n’accumulent pas les autorisations, elles les contraignent.
4. Un endroit unique pour auditer chaque décision d’accès
Chaque demande d’accès, qu’elle vienne d’un collaborateur, d’une application mobile ou d’un agent d’IA autonome, passe par le même moteur de politiques et le même journal d’audit. Les équipes sécurité et conformité disposent d’un point de contrôle unique.
La brèche de DJI aurait pu être évitée en définissant les actions qu’un jeu d’identifiants valide était réellement autorisé à effectuer. C’est exactement ce que fait Okta, pour chaque personne, application et agent d’IA dans votre environnement.
La faille des identifiants existe dans la plupart des entreprises. La bonne nouvelle, c’est qu’Okta contribue à garantir que le parcours de l’état actuel à l’état sécurisé est bien défini. La plupart des équipes sont plus proches qu’elles ne le pensent.
Apprenez-en plus sur la façon dont Okta sécurise l’IA ici.
¹ Sean Hollister, « A hacker found a way to remotely access thousands of DJI robot vacuums », The Verge, 2026. theverge.com/tech/879088/dji-romo-hack-vulnerability-remote-control-camera-access-mqtt
² Top 10 OWASP des risques de sécurité des API 2023 – owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
