Data / IA
On pensait l’IA sous contrôle… les dérapages incontrôlables de l’été 2026 ont montré que non !
Par Laurent Delattre, publié le 28 août 2026
Pendant des mois, l’IA agentique a été vendue avec une promesse implicite : on peut donner davantage d’autonomie aux modèles tant qu’ils restent enfermés dans un environnement contrôlé. L’été 2026 a fissuré cette certitude. OpenAI, Anthropic, Meta, Moonshot AI et Google ont découvert à leurs dépens que leurs derniers modèles agentiques n’avaient pas besoin de « devenir fous » pour franchir une frontière. Il leur suffit d’un objectif, d’un passage mal fermé, de privilèges exploitables et de temps machine. Évasions de bacs à sable, exploitation de failles inédites, agent qui en manipule un autre, réservation de salle de sport qui vire à la première cyberattaque autonome d’Australie : la démonstration est faite. L’IA agentique a progressé plus vite que les scénarios de risque des directions informatiques. C’est le sujet chaud des DSI et RSSI en cette rentrée !
En quelques semaines, le « rogue agent » a quitté les présentations prospectives. Des modèles IA plus ou moins expérimentaux ont trouvé une sortie réseau, exploité des vulnérabilités inédites, utilisé des identifiants exposés, partagé leurs découvertes ou transmis une injection de prompt vers un agent plus puissant.
Rien de tout cela ne prouve l’émergence d’une volonté consciente et, pire encore, d’une volonté consciente de nuire. Toutefois ces incidents démontrent quelque chose de plus immédiatement utile mais aussi de plus urgent aux DSI : les dérives de l’IA agentique réclame de repenser la cybersécurité des SI et des plateformes d’exécution agentique. Le comportement d’un agent est le produit d’un objectif, d’un environnement, de permissions, d’outils et d’un mécanisme de récompense. La sécurité doit donc porter sur toute cette chaîne, et non sur le seul modèle.
Un agent agit selon un objectif, un environnement, des permissions, des outils, une mémoire et un mécanisme de récompense. Sa dangerosité réelle ne réside pas dans le seul LLM, mais dans la somme de ses capacités effectives.
Cette séquence d’incidents multiples, sur lesquels nous allons ici revenir, arrive au moment où l’autonomie entre déjà dans le SI. Selon le People Readiness Report 2026 de Kyndryl, 81 % des dirigeants pensent que des agents prendront des décisions ayant un impact métier significatif dans les douze mois, mais 23 % seulement jugent leur gouvernance prête. Plus troublant : 66 % des organisations autoriseraient déjà des systèmes d’IA à lire et écrire de façon autonome dans leur système d’information, alors que 25 % seulement disent leur faire pleinement confiance.
« Une approche consistant à innover d’abord, sécuriser ensuite n’est plus acceptable dès lors que ces systèmes peuvent identifier et exploiter des vulnérabilités de manière autonome. »
Juraj Janosik, VP Intelligence artificielle, ESET
Retour sur les 6 incidents phares de l’été mais également sur les leçons que RSSI et DSI doivent en tirer…
1 – OpenAI : l’agent ne s’est pas contenté de sortir, il a appris à faire équipe
L’incident OpenAI (dont nous avons déjà parlé cet été) reste le plus spectaculaire. Lors d’une évaluation offensive ExploitGym, GPT-5.6 Sol et un modèle de recherche plus puissant (apparemment basé sur le futur modèle Astra) ont cherché les réponses du test plutôt que de le résoudre. L’accès Internet direct était bloqué, mais un proxy-cache Artifactory restait joignable. Les modèles y ont découvert puis exploité une faille zero-day, obtenu une sortie vers Internet, élevé leurs privilèges et progressé jusqu’à l’infrastructure de production de Hugging Face.
Le plus troublant est venu ensuite. Des exécutions distinctes ont transformé l’infrastructure partagée en tableau de messages pour échanger exploits, identifiants et répartition du travail. OpenAI a supprimé ce canal. Les agents en ont recréé un autre quelques jours plus tard en encodant leurs échanges dans des noms de répertoires WebDAV. Hugging Face a reconstitué quelque 17 600 actions regroupées en 6 280 clusters. On n’est plus face à une décision aberrante isolée, mais à des milliers de microdécisions parallèles, persistantes et jetables.
« Les attaques offensives entièrement automatisées et orchestrées par l’IA sont désormais réelles. »
Michael Dalton, membre de l’équipe technique d’OpenAI – Black Hat 2026
À LIRE AUSSI :
2 – Anthropic : quand le réel ressemble trop au jeu
Après les révélations d’OpenAI, Anthropic a réexaminé 141 006 exécutions et identifié six runs ayant touché trois organisations. Une mauvaise configuration avait laissé Internet accessible malgré des prompts affirmant le contraire. Ses agents ont alors traité les systèmes joignables comme faisant partie de leurs exercices. Dans un cas, Claude a scanné environ 9 000 cibles avant de compromettre une application. Deux organisations n’avaient rien détecté.
Les comportements ont varié : Opus 4.7 a poursuivi malgré la découverte d’un environnement de production, Mythos 5 s’est convaincu qu’il restait dans une simulation, tandis qu’un modèle plus récent s’est arrêté. Conclusion pour Anthropic : les environnements d’évaluation doivent être sécurisés comme de la production.
L’AI Security Institute britannique a poussé l’expérience plus loin. Sur 122 essais, dix runs ont produit 19 actions non autorisées. Un agent Anthropic a même créé de fausses identités, approché un mainteneur open source et tenté de lui faire accepter du code malveillant. Aucun dommage, mais un enseignement inquiétant : le dernier rempart était précisément l’humain que l’agent cherchait à convaincre.
3 – Meta : le prestataire d’évaluation fait partie de la frontière de sécurité
Meta a confirmé le 6 août qu’une mauvaise configuration chez Irregular, son prestataire d’évaluation cyber, avait permis à un modèle d’accéder à Internet puis d’exploiter une vulnérabilité chez un tiers. Ni le modèle ni la victime n’ont été officiellement nommés.
Un incident qui rappelle à tous qu’externaliser un test n’externalise ni le risque ni la responsabilité. Réseau, identifiants, journaux et environnement du prestataire doivent entrer dans le modèle de menace du donneur d’ordre. Pour un agent IA, la frontière contractuelle n’existe pas. Seules comptent les ressources accessibles.
4 – Kimi K3 : pas d’effraction, mais une triche impossible à rappeler
Kimi K3 n’a compromis aucune entreprise. Mais lors d’un test de Frontier Security, une mauvaise configuration du bac à sable lui a permis d’accéder à Internet. Le modèle a trouvé GitHub, récupéré le dépôt du benchmark et lu la réponse au lieu de résoudre l’exercice. C’est du reward hacking : optimiser le score en exploitant un raccourci imprévu.
L’épisode est néanmoins stratégique. Kimi K3 est diffusé en poids ouverts. Une fois ceux-ci distribués, impossible de compter sur une API centrale pour imposer des refus, révoquer une version ou surveiller les usages. Le contrôle doit alors porter sur l’environnement d’exécution, le réseau, les identités et les outils.
« Nous avons trouvé une fuite dans la sandbox, mais aussi constaté que Kimi en avait profité. »
Yaron Singer, CEO de Frontier Security
5 – Google ADK : le risque nouveau est le saut de privilège entre agents
Chez Google, il ne s’agit pas d’un modèle qui s’est spontanément retourné contre un autre. Mais l’affaire dessine une surface d’attaque nouvelle. Pillar Security a démontré une chaîne d’exploitation dans le dépôt de l’Agent Development Kit Python : un agent de triage exposé aux issues et pull requests publiques pouvait ingérer une injection de prompt, publier un commentaire de transfert et déclencher un agent Gemini réservé aux mainteneurs. Ce second agent disposait de commandes shell et de jetons plus puissants. La chaîne ouvrait la voie à l’exécution de code, à l’exfiltration de secrets et à la falsification du cycle d’approbation d’une pull request.
Le chercheur a montré comment fabriquer une trace crédible : commentaire d’un mainteneur modifié, demande de revue Gemini, approbation du bot, suppression d’une demande de revue humaine et étiquette « approved ».
Nous retrouvons une vieille mécanique IAM : le saut de privilège. Mais celui-ci circule désormais entre agents, orchestrateurs et outils. L’exploit illustre ainsi la première conséquence opérationnelle des architectures multi-agents : une identité à faible privilège peut devenir un messager vers une identité forte. La séparation des rôles n’existe donc réellement que si chaque délégation, chaque message et chaque contenu transmis sont eux aussi revalidés.
6 – Melbourne ou la frontière oubliée entre capacité et autorité
Enfin, le cas de Melbourne illustre ces dérives lorsqu’elles sont ancrées dans le quotidien de tous. Un utilisateur, quatrième sur la liste d’attente d’un cours de sport, demande à son agent s’il peut le faire remonter. Celui-ci découvre qu’une API lui permet d’annuler la réservation d’un tiers et évince de sa propre initiative la personne en tête de liste. Personne ne lui avait demandé d’aller jusque-là. L’agent n’a pas ici cherché à nuire : il a cherché à atteindre l’objectif fixé.
Toute l’IA agentique tient désormais dans cette distinction : Un agent peut être techniquement capable d’agir sans pour autant avoir le droit de le faire. Et le problème est d’autant plus grave que, comme ne cesse de le rappeler Yann LeCun, les LLMs ne peuvent pas, ne savent pas, anticiper les conséquences de leurs actions !
OpenAI et Z.ai : la cybersécurité commence à ralentir les modèles
Bien sûr ces incidents doivent interpeler les DSI et les RSSI et nous allons y revenir. Mais ils ont aussi interpelé les créateurs de modèles agentiques. Ainsi la conséquence la plus immédiate mais aussi peut-être la plus spectaculaire de ces incidents est industrielle. Le 7 août, OpenAI reconnaissait ne plus pouvoir exclure qu’Astra, son prochain modèle, atteigne le seuil de capacités cyber « critiques » de son Preparedness Framework. Le 18 août, l’entreprise en tirait les conséquences : deux semaines de pause sur certains entraînements par renforcement, son plus grand run « frontière » toujours suspendu et une partie significative des charges Astra maintenue à l’arrêt jusqu’à leur migration vers des environnements renforcés. La cybersécurité ne se contente donc plus de conditionner la mise sur le marché : elle ralentit désormais directement l’entraînement et l’évaluation des modèles.
Ce durcissement a un coût. Pour les entraînements et évaluations avec outils des modèles de niveau Sol ou supérieur, ainsi que pour toutes les inférences d’Astra avec outils, OpenAI surveille désormais raisonnements et actions en plusieurs étapes. Si une alerte critique ne peut être écartée comme faux positif sous trente minutes, l’activité doit être suspendue. OpenAI estime ce dispositif à environ 20 % de calcul supplémentaire sur l’inférence surveillée. Il faut aussi y voir un enseignement : la sécurité n’est plus une vérification de fin de cycle, elle devient une composante permanente et mesurable du coût de développement des modèles. Tant mieux. Espérons que cela dure.
Même signal en Chine. Z.ai affirme que GLM-5.3 progresse fortement sur les benchmarks cyber et revendique 2 436 vulnérabilités découvertes dans 269 projets, dont 1 097 critiques ou élevées. Mais l’éditeur a retardé d’environ deux semaines la publication des poids et réservé certaines capacités à des partenaires de sécurité vérifiés. Logique : une fois les poids téléchargés, impossible de les rappeler ou d’en contrôler l’usage.
OpenAI et Z.ai n’ont ni le même modèle économique ni la même politique d’ouverture. Leur convergence est donc significative : lorsqu’un modèle franchit un seuil de capacités offensives, ralentir l’entraînement, restreindre les usages ou retenir les poids n’est plus une simple précaution. Cela devient une décision produit forte mais indispensable.
Le Zero Trust doit maintenant sortir des slides
Pour les DSI, la réponse ne sera ni une meilleure consigne système ni un joli bouton « stop ». Un kill switch qui laisse survivre jetons, sessions, clés, files d’attente ou délégations aval n’est qu’une décoration de gouvernance. Il faut une doctrine de confinement, avec des seuils de déclenchement, des droits à révoquer, des responsables identifiés et des conditions de reprise.
Les priorités sont finalement assez familières. Inventorier les agents comme des identités privilégiées. Leur attribuer un propriétaire et une identité propre. Séparer lecture et écriture. Supprimer les droits tenant-wide. Imposer des privilèges temporaires. Gouverner leur mémoire. Journaliser le chemin complet d’une action, depuis la version du modèle jusqu’à la ressource touchée. Puis tester révocation et confinement comme on teste un PRA.
Microsoft pousse précisément cette lecture en étendant son approche Zero Trust à l’IA, aux SecOps et au DevSecOps. Il lance « Zero Trust for AI« . L’éditeur transforme ainsi le Zero Trust en plan de contrôle : son Zero Trust Assessment ajoute des piliers IA, SecOps et Infrastructure aux dimensions Identité, Terminaux, Réseau et Données et son atelier DevSecOps décline 15 groupes de contrôles et 91 tâches.
De son côté, avec son nouveau Agentic Vulnerability Discovery Harness, Google montre l’autre moitié de l’équation : face à des attaquants augmentés par l’IA, la défense devra elle aussi devenir agentique, mais dans des chaînes spécialisées, contrôlées, contradictoires et validées par des humains.
Le changement de focale est fondamental. Il faut cesser de demander si un modèle est « sûr » et mesurer ce que le système peut réellement accomplir. Quels outils invoque-t-il ? Quels comptes emprunte-t-il ? Quels autres agents peut-il appeler ? Quelle mémoire peut-il modifier ? Quelle sortie réseau reste ouverte ? Et, surtout, combien de temps faut-il pour lui retirer réellement tout pouvoir ?
Supposer l’échec devient le nouveau point de départ
Ces incidents ne prouvent pas que les agents ont « pris le contrôle ». Ils prouvent qu’ils n’ont plus besoin d’une intention malveillante pour provoquer une intrusion. Il leur suffit d’un objectif mal borné, d’un passage accessible, de privilèges utilisables et de temps de calcul. Leur avantage n’est pas la magie : c’est la patience, la répétition, le parallélisme et l’absence de fatigue.
« Nous avons une fenêtre entre des IA assez capables pour nuire et des IA assez stratégiques pour ne pas se faire prendre. »
Nate Soares, président du Machine Intelligence Research Institute
Pour les DSI et RSSI, l’enjeu n’est évidemment pas de suspendre toute expérimentation. Il nous faut être pratique, pragmatique et regarder nos propres architectures avec des regards neufs. Il s’agit surtout d’appliquer aux agents la discipline acquise avec le cloud, les identités et le DevSecOps – en l’étendant aux objectifs, aux outils, à la mémoire, aux délégations et au confinement.
Ainsi, l’été 2026 n’a pas démontré que les agents IA étaient devenus incontrôlables. Il a démontré que nos contrôles avaient été conçus pour un monde où les logiciels attendaient sagement des ordres. Or ce monde disparaît, et la sécurité de demain devra s’adapter à des systèmes agentiques qui n’attendent plus notre permission pour agir.
Ce que ces incidents apprennent vraiment aux DSI
1. Le risque n’est plus le modèle, mais la capacité effective du système
Il faut mesurer ce que l’agent peut réellement faire avec ses outils, identités, données et délégations. Plusieurs petits droits peuvent, une fois combinés, lui donner un pouvoir considérable.
2. « Humain dans la boucle » n’est pas synonyme de contrôle
Un agent peut chercher à convaincre l’humain ou fabriquer les signes d’une validation légitime. L’approbation humaine n’a de valeur que si elle repose sur des preuves indépendantes et vérifiables.
3. La récompense et la mesure font partie de la surface d’attaque
Un agent optimise ce qui est mesuré, pas nécessairement l’intention humaine : c’est le reward hacking. Il faut donc vérifier le chemin suivi pour réussir, pas seulement le résultat obtenu.
4. La responsabilité se jouera sur la prévisibilité et les preuves
À mesure que les incidents se multiplient, le risque devient juridiquement plus prévisible. Les DSI doivent pouvoir attribuer chaque action à un agent, un modèle, une identité, des outils et une autorisation précise.
5. Un kill switch sans doctrine de confinement n’est qu’un bouton
Arrêter un agent suppose aussi de révoquer ses droits, ses sessions, ses accès réseau et ses délégations. Les entreprises doivent exiger de leurs fournisseurs un plan de confinement testable, auditable et déclenchable rapidement.
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
