Ceci est le cinquiè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é :
Mi-septembre 2025, des acteurs étatiques chinois ont détourné Claude Code pour mener la première cyberattaque autonome de grande envergure documentée. L’opération a ciblé de grandes entreprises technologiques, des institutions financières, des entreprises de fabrication de produits chimiques et des administrations publiques. Par ailleurs, fin août, une compromission d’identifiants a entraîné la fermeture des usines de JLR pendant cinq semaines, pour un coût de 1,9 milliard de livres sterling. Imaginez maintenant ce même schéma d’attaque exécuté par un agent d’IA qui ne dort pas et qui peut essayer un millier de combinaisons d’identifiants pendant que vous lisez cette phrase. C’est une réalité. Ces attaques ne font pas que percer les périmètres. Elles exploitent les accès légitimes.
La défense ne réside pas dans de meilleurs pare-feux, mais dans l’autorisation : contrôler ce que les agents peuvent faire à chaque étape, avec une supervision humaine quand il le faut. Pour les systèmes cyber-physiques, l’IAM n’est pas une infrastructure IT — c’est un système de sécurité.
Les enjeux ne sont plus théoriques
L’OpenID Foundation appelle cela le « défi ultime » pour l’identité : la gouvernance des agents dont les actions ont des conséquences directes et potentiellement irréversibles dans le monde physique. L’autorisation, la moitié de la gestion des accès de l’IAM, devient un élément fondamental de la sécurité du système.
Trois incidents survenus fin 2025 ont prouvé que c’est déjà le cas.
Tout d’abord, les agents d’IA ont prouvé qu’ils pouvaient attaquer des infrastructures critiques de manière autonome. En septembre, Anthropic a révélé qu’un groupe soutenu par l’État chinois avait détourné Claude Code pour ce que les chercheurs en sécurité ont appelé la première cyberattaque de grande envergure menée principalement par une IA. L’agent a fait le plus gros du travail : recherche de vulnérabilités, écriture d’exploits, collecte d’identifiants, déplacement latéral sur les réseaux. Parmi les cibles : des entreprises de fabrication de produits chimiques. Certaines ont été compromises. Ce sont des installations où des identifiants compromis pourraient manipuler les contrôles de processus avec des conséquences catastrophiques.
Ensuite, des chercheurs ont prouvé que la surface d’attaque s’étend à tout agent ayant un accès physique. En août 2025, des chercheurs ont démontré qu’une invitation Google Agenda piégée pouvait pirater Gemini afin de contrôler des appareils domestiques intelligents comme des lumières, des volets et des chaudières. L’attaque, que les chercheurs ont baptisée « Promptware », a exploité une faille d’autorisation fondamentale : les autorisations de lecture de l’agenda ne devraient pas accorder d’autorisations de contrôle des actionneurs. Le mécanisme est identique. Seules les conséquences changent.
Et la compromission d’identifiants a prouvé qu’elle pouvait stopper les activités des usines, et ce rapidement. Jaguar Land Rover a subi ce qui est largement considéré comme la cyberattaque la plus préjudiciable économiquement de l’histoire du Royaume-Uni. Les attaquants ont obtenu un accès via un fournisseur de JLR et ont continué jusqu’à atteindre les systèmes de production. Les robots se sont figés. Les ouvriers sont restés chez eux pendant cinq semaines. Plus de 5 000 entreprises de la chaîne logistique de JLR ont été touchées. Imaginez maintenant ce même déplacement latéral exécuté par un agent d’IA qui ne dort pas, ne fait pas de fautes de frappe et peut essayer un millier de combinaisons d’identifiants pendant que vous lisez cette phrase. C’est le modèle de menace.
La crise des identifiants aggrave la situation
Le rapport X-Force 2025 d’IBM confirme cette tendance : l’exploitation abusive de comptes valides est désormais la méthode d’intrusion privilégiée, représentant 30 % des incidents. Au premier semestre 2025, on a constaté une augmentation de 800 % du nombre d’identifiants volés par des infostealers. La compromission d’identités non humaines (clés API, comptes de service, tokens OAuth) est désormais un vecteur d’attaque initial de premier plan.
Cela affecte déjà les systèmes d’IA. Une attaque de la chaîne logistique visant l’écosystème de plugins OpenAI a récolté les identifiants des agents de 47 déploiements d’entreprise ; les attaquants y ont eu accès pendant six mois avant que quelqu’un ne s’en aperçoive. Les attaques de fabrication ont augmenté de 61 % d’une année sur l’autre. Même schéma à chaque fois : identifiants volés, déplacement latéral, dommages concrets.
Le périmètre ne vous sauvera pas
La sécurité traditionnelle se concentre sur le fait d’empêcher les acteurs malveillants d’entrer : pare-feux, segmentation réseau, protection des terminaux… Tout est nécessaire. Mais les agents d’IA ne s’infiltrent pas. Ils sont déjà à l’intérieur, opérant avec des identifiants légitimes.
L’attaque Promptware n’a pas compromis de pare-feu. Elle a piraté un agent autorisé. L’opération Claude Code n’a pas exploité une vulnérabilité réseau. Elle a collecté des identifiants valides et les a utilisés. Ces attaques ont été fructueuses parce que les agents avaient l’autorisation d’être là. Par contre, ils n’avaient pas l’autorisation de faire ce qu’ils ont fait.
La question n’est pas de savoir où les agents peuvent aller, mais ce qu’ils sont autorisés à faire à chaque étape une fois qu’ils y sont.
Imaginez une usine de traitement de l’eau. Un agent d’IA surveille les niveaux de chlore, régule la pression et répond aux fluctuations de la demande. Quelle est son enveloppe d’autorisations ? Elle doit être explicite : maintenir les niveaux du réservoir entre X et Y, ne jamais dépasser la pression Z, alerter un humain si une valeur se trouve en dehors de ces limites. Mais si l’agent a hérité des autorisations étendues de « gestion des systèmes d’eau » de celui qui les a déployés, un agent compromis pourrait pousser le chlore à des niveaux toxiques ou déclencher des défaillances de pression. Posez-vous la question : votre architecture d’autorisation vous permet-elle même d’exprimer ces contraintes ?
L’autorisation en tant qu’infrastructure de sécurité
Pour les systèmes cyber-physiques, l’IAM transcende son rôle traditionnel. Il devient une couche de sécurité et d’application des politiques.
L’identité vous dit qui agit. L’autorisation, quant à elle, vous indique ce que cette entité est autorisée à faire, action par action, avec une supervision humaine quand il le faut. Pour les agents contrôlant des systèmes physiques, c’est l’architecture qui empêche les explosions.
L’aviation ne compte pas sur les pilotes pour se souvenir des limites d’altitude. Les installations nucléaires ne font pas confiance aux opérateurs pour éviter les configurations dangereuses. Ces secteurs ont appris il y a des décennies que l’attention humaine n’est pas un système de sécurité. Ce sont les contraintes techniques qui le sont. L’architecture Zero Trust du NIST (SP 800-207) codifie ceci : ne jamais faire confiance, toujours vérifier, appliquer le principe du moindre privilège à chaque point de décision.
Pour les agents d’IA contrôlant les systèmes physiques, cette contrainte technique réside dans l’autorisation. Lorsqu’elle est correctement appliquée, les identifiants sont délivrés en flux tendu, adaptés à l’opération immédiate et révoqués dès que le contexte change. Les tokens qui n’existent pas ne peuvent pas être volés. Un agent compromis ne peut toujours pas dépasser son enveloppe d’autorisations. Les actions à fort enjeu déclenchent une approbation humaine. Et chaque action peut être reliée à un utilisateur, un agent et un moment précis.
Voici à quoi cela ressemble techniquement. La RFC 8693 (OAuth 2.0 Token Exchange) fournit des tokens de délégation qui préservent le contexte :
{
"sub": "technicienne-jeanne@fabrication.exemple",
"act": {
"sub": "agent-maintenance-7"
},
"aud": "api-fabrication.exemple.com",
"scope": "actuator:write",
"exp": 1737043200
}
sub identifie l’humain. La revendication act identifie l’agent. scope définit exactement ce qui est autorisé. Pas « gérer les systèmes », mais « actuator:write » pour une ressource spécifique. exp définit l’expiration : 5 à 60 minutes pour les opérations cyber-physiques, pas des mois. Lorsque la fenêtre de maintenance se ferme, le token expire.
La loi de l’UE sur l’IA classe les systèmes d’IA utilisés en tant que composants de sécurité dans les infrastructures critiques (y compris l’eau, le gaz et l’électricité) comme étant à haut risque en vertu de l’annexe III, déclenchant des exigences de supervision humaine au titre de l’article 14. Pour les systèmes prenant des milliers de décisions par minute, il est évident que des humains ne peuvent pas examiner chacune d’entre elles. Les systèmes d’autorisation appliquent les limites de manière programmatique et ne font remonter que les conditions véritablement exceptionnelles.
La fenêtre se rétrécit
Gartner prévoit que les agents d’IA réduiront de 50 % le temps nécessaire pour exploiter les expositions de comptes d’ici 2027. Les attaques qui prenaient auparavant des semaines ne prendront que quelques jours. L’opération Claude Code a déjà montré à quoi ressemblent des attaques à la vitesse des machines.
Les entreprises qui mettent en place une architecture d’autorisation appropriée dès maintenant serviront de modèle lorsque les réglementations se durciront.
Comment Okta résout le problème
Aucune de ces attaques n’a percé un pare-feu. L’attaque Promptware a piraté un agent autorisé qui ne disposait pas des autorisations nécessaires. L’attaque visant les plugins OpenAI a exploité des identifiants qui ont perduré trop longtemps et dont les autorisations étaient trop étendues. L’opération Claude Code a collecté des secrets valides et les a réutilisés. Chaque défaillance correspond à un contrôle que nous proposons.
- Cross-App Access (XAA) rend les actions des agents traçables pour l’utilisateur et pour l’agent. Les tokens de délégation fournissent du contexte sur toute la chaîne, avec des revendications act identifiant quel agent a fait quoi.
- Token Vault élimine les identifiants à long terme. Les agents récupèrent les tokens à la demande, limités aux opérations immédiates. Les tokens volés expirent avant que les attaquants ne puissent les utiliser.
- L’authentification renforcée CIBA met des humains dans la boucle pour les actions aux conséquences importantes. Lorsqu’un agent tente de dépasser son enveloppe d’autorisations (ajuster la pression au-delà des limites, modifier les concentrations chimiques, outrepasser les verrouillages), l’utilisateur faisant autorité doit explicitement approuver l’opération.
- Fine-Grained Authorization évalue l’accès au moment de la décision, et pas seulement lors de la connexion. C’est ainsi que vous exprimez « maintenir les niveaux du réservoir entre X et Y ; ne jamais dépasser la pression Z » dans une politique lisible par machine.
La voie à suivre
Avec 21 milliards de terminaux IoT et des millions de robots industriels désormais connectés, les agents d’IA disposent d’un univers en expansion de systèmes physiques auxquels ils peuvent accéder et qu’ils peuvent contrôler.
La question de la gouvernance est simple : votre équipe est-elle capable de définir l’enveloppe d’autorisations de chaque agent ayant accès aux systèmes critiques (quels identifiants il détient, ce que ces identifiants l’autorisent à faire et si ces autorisations dépassent les besoins opérationnels) ? Si la réponse est non, cette faille constitue votre surface d’attaque.
Mais elle peut être comblée. Les modèles d’autorisation qui sécurisent les transactions financières peuvent sécuriser les usines de traitement de l’eau, les réacteurs chimiques et les bras robotiques. L’identité vous dit qui. L’autorisation contrôle ce que chaque entité peut faire à chaque étape, en mettant des humains dans la boucle quand il le faut. Pour les systèmes cyber-physiques, il ne s’agit pas d’un système de gestion des accès, mais d’une infrastructure de sécurité.
L’architecture existe. La question est de savoir si vous l’implémenterez avant ou après être devenu une étude de cas.
Suivant : le sixième article de la série s’intéresse à ce qui se passe lorsqu’un agent sert plusieurs parties prenantes avec des autorisations différentes. Par exemple, lorsque l’agent du directeur financier répond à des questions dans un canal Slack partagé, quels droits d’accès gouvernent la réponse ?
