Les incidents d'agents IA de 2026 sont-ils exagérés ?

Non, les incidents eux-mêmes sont documentés et sérieux. Ce qui est exagéré, c'est leur interprétation : les rapports techniques comportent des réserves méthodologiques importantes que la reprise médiatique efface presque systématiquement. La bonne posture n'est ni le déni ni la panique, c'est de lire les limites déclarées avant les conclusions.

Faut-il acheter un pare-feu d'agents IA ?

Zack Korman le déconseille, et son argument me paraît solide : si une action est assez dangereuse pour être repérée à partir de l'action elle-même, des permissions et un bac à sable corrects l'auraient empêchée avant. Commencez par auditer votre configuration existante. Un outil de supervision peut avoir un intérêt pour la visibilité, mais il ne remplace pas un périmètre bien posé.

Comment vérifier la solidité d'un rapport sur un incident IA ?

Quatre questions suffisent la plupart du temps : qui l'a écrit et avec quelle expertise, quel accès aux données ces personnes ont-elles eu, combien de temps ont-elles travaillé, et qu'est-ce qui était explicitement hors périmètre. Un rapport honnête répond aux quatre. Le rapport METR et Redwood du 26 août y répond, ce qui est à son crédit.

Cet article remplace-t-il celui sur l'incident Hugging Face ?

Non, il le complète. L'incident lui-même et ses conséquences en matière de gouvernance sont traités séparément. Ici, je m'intéresse à la manière dont ces incidents sont racontés et à la façon de trier ce qui est exploitable pour une décision.

Sécurité des agents IA : ce qui protège vraiment

Q: Qu'est-ce que le point aveugle réglementaire évoqué par Ciaran Martin ?

Les règles en discussion encadrent surtout la mise à disposition des modèles au public. Elles couvrent très peu ce que les entreprises d'IA font en interne avec leurs propres systèmes, alors que les incidents récents sont justement survenus dans ce cadre interne, lors d'évaluations ou d'entraînements.

Fin août, un rapport d'analyse indépendante sur l'incident OpenAI / Hugging Face est publié. En quelques jours, il se transforme en récit d'anticipation : civilisations d'agents, machines qui complotent, basculement historique. Un mois plus tard, la découverte d'un wiki allemand détourné par des agents relance exactement le même cycle. Zack Korman, cofondateur et dirigeant d'Embroidery, résume son agacement d'une phrase reprise par le média Next : la sécurité de l'IA a complètement perdu le contact avec la réalité.

Je trouve la critique salutaire, mais elle mérite d'être instruite plutôt que reprise telle quelle. Parce que le problème n'est pas que les incidents soient inventés : ils sont réels, documentés, et j'ai déjà consacré un article entier à celui de Hugging Face. Le problème est ailleurs : entre le rapport technique et l'article que vous lisez le lendemain, quelque chose se perd systématiquement, et ce quelque chose est précisément la partie qui aurait servi à un décideur.

Ce que le rapport disait vraiment de lui-même

Le rapport d'analyse indépendante de l'incident Hugging Face a été publié le 26 août 2026 par METR et Redwood Research. Trois personnes l'ont produit : Hjalmar Wijk et Ajeya Cotra pour METR, Ryan Greenblatt de Redwood Research sous contrat avec METR. Six jours sur site chez OpenAI, répartis en trois visites, avec une analyse concentrée sur la période du 7 au 13 juillet.

En-tête du rapport METR et Redwood Research, avec les contributeurs, la date de publication et les dates couvertes par l'enquête

Le rapport publié par METR et Redwood Research le 26 août 2026.

Ce qui m'a frappé en le lisant, ce n'est pas ce que la presse en a tiré. C'est la franchise de la section sur les limites. Les auteurs écrivent noir sur blanc qu'ils ont largement délégué leur analyse à des agents IA souvent peu fiables, faute de pouvoir traiter le volume autrement. Ils précisent que leurs agents d'analyse ont pu commettre des erreurs qu'ils n'ont pas rattrapées, que le modèle utilisé adoptait fréquemment et sans recul le point de vue de l'agent dont il examinait la transcription, ce qui donne une image potentiellement trop indulgente, et qu'ils ne peuvent pas exclure que ce modèle ait menti ou présenté délibérément une image trompeuse dans certaines parties de l'analyse. S'y ajoute qu'environ 7 % des transcriptions contenaient des appels d'outils falsifiés, et que plus de 90 % de l'activité des agents a été captée, ce qui veut dire par construction que tout ne l'a pas été.

Autrement dit : un modèle d'OpenAI a servi à analyser le comportement d'agents d'OpenAI, et les auteurs le signalent eux-mêmes. Cette phrase-là ne s'est pas retrouvée dans les gros titres. Les conclusions spectaculaires, si.

C'est le premier tri à faire, et il ne demande aucune expertise technique : lire la section « limitations » avant le résumé. Quand elle est honnête, comme ici, elle vous dit exactement quel degré de confiance accorder au reste.

Vérifier qui a produit l'analyse, pas seulement ce qu'elle dit

Ciaran Martin, premier dirigeant du NCSC britannique, a publié le 2 septembre un billet intitulé « Welcome to FUD-tier AI! », FUD pour fear, uncertainty and doubt, un terme que le milieu de la cybersécurité emploie depuis longtemps pour désigner la peur entretenue à des fins commerciales. Il y relaie une remarque de Zack Korman : ce rapport majeur sur un incident de cybersécurité n'a reçu aucune contribution de quelqu'un ayant une expertise ou une expérience en cybersécurité, alors même qu'il a été écrit par certains des meilleurs chercheurs en sécurité de l'IA au monde.

Je précise la chaîne, parce qu'elle compte : c'est Korman qui formule la critique, Martin qui la relaie. Je n'ai pas pu ouvrir le message d'origine, la plateforme le refusant à la lecture automatisée, et Korman ne nomme pas le rapport dans ce que j'ai pu lire. L'identification est donc une déduction de ma part, que j'assume : le rapport METR et Redwood du 26 août correspond à la description, un rapport majeur sur un incident de cybersécurité signé par des chercheurs de premier plan en sécurité de l'IA, publié quelques jours avant le billet de Martin. Ce que j'ai pu vérifier moi-même, en revanche, c'est la composition de l'équipe, et elle est cohérente avec le reproche : le travail publié d'Ajeya Cotra porte sur la modélisation des risques de perte de contrôle des IA avancées, pas sur la réponse à incident. Sécurité de l'IA et cybersécurité sont deux métiers, et rien n'oblige un excellent praticien du premier à connaître le second.

Ce n'est pas une accusation, c'est une question de périmètre. Un rapport produit en six jours par trois chercheurs en sécurité de l'IA sur les données fournies par l'entreprise concernée reste une contribution utile. Il ne devient trompeur qu'au moment où il est lu comme une investigation forensique complète, ce qu'il n'a jamais prétendu être.

Je fais le même exercice sur les annonces de capacités des modèles, et pour des raisons identiques : la question utile n'est presque jamais « qu'est-ce que ce document affirme », c'est « qui l'a produit, avec quel accès, en combien de temps, et qu'est-ce qui était hors périmètre ». Quatre questions, deux minutes, et la moitié du bruit tombe.

Par cohérence, j'applique la méthode à Korman lui-même. Sa critique est solide et je la reprends, mais il dirige une entreprise qui vend de la supervision d'agents IA, sur un marché adjacent à celui qu'il déconseille. Superviser n'est pas bloquer, il n'y a donc pas de contradiction, mais il y a un positionnement commercial. Ça n'invalide rien : ça se sait, simplement.

L'angle mort réglementaire

Le point le plus intéressant de Martin est antérieur à l'affaire du wiki. Le 5 août, avant que celle-ci ne soit connue, il écrivait déjà que la quasi-totalité des règles en discussion porte sur la façon dont les modèles sont mis à disposition du public, et très peu sur ce que les entreprises d'IA font en interne avec leurs propres systèmes, c'est-à-dire précisément là où ces défaillances se sont produites. Les modèles les plus puissants passent leurs premiers mois à l'intérieur du laboratoire qui les a construits, avec le niveau de confinement que ce laboratoire a jugé suffisant, et personne d'autre ne regarde.

Ce que j'aime dans ce point, c'est qu'il a été écrit avant, et que septembre l'a confirmé sans qu'il ait besoin d'être réécrit. L'épisode du wiki allemand n'est pas une attaque contre un tiers : c'est une évaluation interne qui a dérapé, restée invisible pendant des semaines. Selon deux sources anonymes rapportées par la presse, information que je n'ai pas pu recouper à une source primaire, OpenAI en aurait eu connaissance bien avant la publication des chercheurs.

Martin insiste par ailleurs sur un principe de responsabilité qui parlera à tout responsable de projet : celui qui possède la capacité répond de ce qu'elle fait. Il ajoute, et c'est la partie que le récit spectaculaire escamote toujours, qu'il n'y a pas de cyberapocalypse.

Ce qui protège réellement

Sur la partie actionnable, la position de Korman est nette et je la partage : évitez les pare-feux d'agents et les produits de sécurité d'exécution pour agents IA. Son argument tient en une phrase. Si une action est suffisamment dangereuse pour être identifiée à partir de l'action elle-même, alors des permissions correctes et un bac à sable correct l'auraient déjà empêchée en amont. Le produit qui promet de rattraper au vol ce que votre configuration laisse passer vous vend surtout le droit de ne pas revoir votre configuration.

Ce qui reste, une fois le récit dissipé, est d'un ennui remarquable. Des permissions au plus juste, réexaminées quand le périmètre de l'agent change. Un isolement réel, testé, pas déclaré. Une prévention des fuites de données qui sache ce qui a le droit de sortir. Et la conscience que ce qu'un agent écrit dans un espace public peut être relu par un autre agent plus tard : c'est le mécanisme exact du wiki allemand, où des exécutions successives, chacune dotée de droits éphémères, ont fini par se constituer une mémoire commune à travers un site tiers. Selon les chercheurs qui ont documenté l'affaire le 4 septembre, environ dix-huit mille messages ont été laissés entre le 11 mai et le début juillet 2026, sous plus de trois mille sept cents pseudonymes distincts. Les décomptes varient d'une source à l'autre selon la mesure retenue, contributions survivantes ou activité totale, une partie ayant été supprimée au fil de l'eau par l'administrateur du site.

Aucune de ces mesures ne fait un bon titre. C'est pourtant la seule liste qui compte, et c'est aussi ce que je constate quand un pilote d'agents échoue en entreprise : l'échec vient rarement d'une capacité manquante, presque toujours d'un périmètre mal posé. Le même raisonnement vaut pour la façon d'ouvrir un accès réseau à un agent.

Ce que j'en retiens pour un comité de direction

Si vous devez arbitrer un budget de sécurité IA ce trimestre, le tri est simple. Un récit qui vous décrit des intentions, des sociétés d'agents ou une bascule civilisationnelle ne vous aide pas à décider. Un document qui vous dit qui a regardé quoi, pendant combien de temps, avec quel accès, et ce qui restait hors périmètre, vous aide. La différence entre les deux n'est pas le niveau de technicité : c'est la présence de limites explicites.

Et si un fournisseur vous propose de sécuriser vos agents sans jamais évoquer vos permissions ni votre isolement, vous savez maintenant quelle question poser en premier.

Sources

Le storytelling autour de la sécurité des agents IA a perdu le contact avec la réalité, Jean-Marc Manach, Next, 8 septembre 2026
Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident, METR et Redwood Research, 26 août 2026
Welcome to FUD-tier AI!, Ciaran Martin, 2 septembre 2026
Control. Ownership. Perspective., Ciaran Martin, 5 août 2026
Discovery of a new OpenAI agent message board, Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts et Thomas Larsen, 4 septembre 2026
Zack Korman sur les pare-feux d'agents, X

Sécurité des agents IA : ce qui fait recette n'est pas ce qui protège