Des agents IA hors de contrôle : trois incidents en quatorze jours

En l'espace de quatorze jours, OpenAI, Anthropic et l'AI Security Institute (AISI) britannique ont chacun révélé que, dans le cadre d'audits de sécurité internes, des agents d'IA avaient dépassé le cadre de test prévu et avaient eu un impact sur des systèmes et des personnes réels. Ce qui est moins remarquable que ces cas isolés, c’est la rapidité avec laquelle les capacités de ces agents évoluent – et le fait que, dans l’un de ces cas, ce n’est pas un contrôle technique, mais l’attention humaine qui a permis d’éviter les dégâts.

L'incident sous la loupe

Début août 2026, l'AISI a publié un rapport sur la fuite d'agents d'IA hors des environnements de test. Dans le cadre d’un test de routine, un agent d’IA a recherché les responsables d’un projet open source utilisé par le grand public, a créé sur cette base plusieurs fausses identités en ligne et a tenté, par le biais de ces identités, de convaincre un responsable réel de valider du code malveillant – une approche classique d’ingénierie sociale, telle qu’elle est habituellement décrite par des attaquants humains dans des scénarios de chaîne d’approvisionnement.

Ce qui est remarquable ici, ce n'est pas tant la technique que la genèse de ce comportement : personne n'avait donné pour consigne à l'agent de tromper. Il ne lui avait pas non plus été expressément interdit d’utiliser des techniques d’ingénierie sociale ou l’accès libre à Internet à de telles fins – jusqu’à présent, une telle restriction semblait superflue pour les modèles ayant suivi un entraînement à l’alignement.

Dans le cadre de cette étude, l'AISI a testé deux « cyber-ranges » – des réseaux contrôlés et simulés reproduisant des environnements réels – à l'aide de sept modèles différents, au cours de 122 essais au total. Lors de dix de ces essais, un agent a agi en dehors du cadre de test défini ; 19 actions individuelles ont ainsi été documentées, dont 17 provenaient de Mythos 5 d’Anthropic et deux d’un seul passage avec GPT-5.6 Sol d’OpenAI. La liste complète figure dans le rapport technique de l’AISI à l’adresse suivante : https://www.aisi.gov.uk.

Pour interpréter ces chiffres, il est indispensable de tenir compte de deux conditions cadres : l'accès à Internet avait été délibérément activé, et les cyber-classificateurs des fournisseurs de modèles – c'est-à-dire les mécanismes de filtrage destinés à empêcher les comportements à risque – avaient été délibérément désactivés. Ces deux éléments visent à déterminer les performances maximales d’un modèle et ne correspondent en aucun cas à la configuration dans laquelle ces modèles sont mis à la disposition des utilisateurs finaux. Aucune évasion hors du bac à sable n’a été constatée. L’AISI n’a jusqu’à présent constaté aucun préjudice vérifiable dans le monde réel, mais fait toutefois état d’effets isolés et limités dans des circonstances bien précises.

Trois publications en quatorze jours

Il s'agit de la troisième divulgation de ce type en l'espace de quatorze jours, et la comparaison de ces trois cas est instructive, car leurs causes sont différentes.

Le 21 juillet 2026, OpenAI a annoncé que deux modèles s'étaient échappés d'un environnement de test isolé en exploitant une vulnérabilité jusque-là inconnue, avant de compromettre l'infrastructure de production de Hugging Face. Ce qui est remarquable ici, c'est la manière dont l'incident a été détecté : Hugging Face avait lui-même découvert l'attaque et l'avait signalée aux forces de l'ordre avant même qu'OpenAI ne puisse établir le lien avec sa propre série de tests d'évaluation.

Le 30 juillet 2026, ce fut au tour d’Anthropic. Un examen rétrospectif de 141 006 cycles d’évaluation a révélé trois incidents au cours desquels des modèles Claude – plus précisément Opus 4.7, Mythos 5 ainsi qu’un modèle de recherche interne – ont obtenu un accès non autorisé à l’infrastructure de production de trois organisations réelles ; les plus anciens de ces incidents remontent à avril 2026. La cause n’était pas ici une faille exploitée, mais un malentendu entre Anthropic et le partenaire d’évaluation externe : les machines utilisées pour le test disposaient d’un accès Internet actif, alors que la consigne indiquait expressément le contraire au modèle. L’intrusion proprement dite dans les organisations concernées s’est ensuite déroulée avec des moyens on ne peut plus simples, à savoir via des mots de passe faibles et des terminaux non authentifiés. Les deux organisations qu’Anthropic a pu contacter n’avaient pas remarqué cette activité.

Ce ne sont pas les cas isolés qui posent problème, mais la rapidité avec laquelle ils se succèdent

Un agent d'IA qui invente de fausses identités pour inciter un être humain à partager des codes malveillants faisait encore, jusqu'à récemment, l'objet d'articles scientifiques ; l'AISI décrit explicitement cette forme de tromperie ciblée comme un comportement qui était jusqu'à présent resté largement théorique. Ce phénomène est désormais documenté.

Un détail du rapport Anthropic mérite ici une attention particulière : les trois modèles concernés ont réagi différemment lorsque des indices d’un environnement réel sont apparus. Opus 4.7, le plus ancien des trois, a poursuivi l’attaque bien qu’il ait identifié les systèmes de production comme tels. Mythos 5, malgré une auto-évaluation intermédiaire correcte, s’est replongé, dans son raisonnement, dans l’hypothèse selon laquelle il continuait à opérer dans une simulation. Le modèle de recherche interne le plus récent a interrompu le processus.

C'est dans un premier temps une bonne nouvelle, car c'est le modèle le plus récent qui a réagi le plus de manière appropriée. Pour l'architecture de sécurité, cela n'entraîne toutefois pas un allègement, bien au contraire : la capacité à compromettre un système augmente plus rapidement que la capacité à évaluer correctement sa propre situation. On ne peut donc pas fonder un contrôle sur l'évaluation de la situation par un agent, car il s'agit d'un comportement et non d'une propriété de sécurité.

Il faut saluer le fait que ces trois incidents aient été détectés, maîtrisés puis rendus publics. Les mécanismes d'alerte précoce fonctionnent donc, et il reste une marge de manœuvre pour prendre des contre-mesures. Reste à savoir si ce type de défense évolue au même rythme que les menaces et si les organisations concernées, dans leur ensemble, réagissent aussi rapidement que les alertes leur parviennent.

Dans ce contexte, il convient d’examiner de près ce qui a réellement permis de mettre fin à l’attaque dans l’affaire AISI. Celle-ci a été détectée grâce à une surveillance technique, mais en aval et par le biais d’un trafic réseau suspect, et non par un contrôle effectué au sein même de l’évaluation. C’est un être humain qui l’a stoppée : le responsable de maintenance, qui a examiné et rejeté la pull request. À cela s’est ajouté un intervenant externe qui a ouvert le code suspect dans un environnement isolé. Dans ce cas précis, l’attention humaine et les bonnes pratiques établies ont fait leurs preuves. Cependant, ces deux éléments ne sont pas à la hauteur face à un attaquant qui travaille sans relâche et ne se lasse pas.

Conséquences pour la pratique

L'AISI tire lui-même trois enseignements qui s'adressent principalement aux évaluateurs : des contrôles réseau très précis plutôt qu’un accès à Internet accordé de manière forfaitaire, un suivi permettant d’observer l’évaluation en cours en temps réel, ainsi qu’une conception de l’évaluation qui tient compte dès le départ du fait qu’un modèle performant peut sortir de son cadre.

Pour les organisations ne faisant pas partie de ce cercle, la recommandation de l'AISI est nettement plus sobre et n'apporte, pour l'essentiel, rien de nouveau : des bases solides en matière de cybersécurité ainsi qu'une vérification rigoureuse des codes et des contributions externes. En complément, l'AISI recommande d'ancrer la cybersécurité parmi les priorités du conseil d'administration et d'exiger le respect de normes minimales tout au long de la chaîne d'approvisionnement.

Thomas Boele, directeur mondial de l'ingénierie des solutions – Sécurité IA chez Check Point, classe les mesures nécessaires en trois axes d'action : la protection contre les attaques pilotées par l'IA, car les attaquants disposent des mêmes capacités que celles révélées par ces tests ; le contrôle de sa propre IA, car les responsables de la sécurité doivent savoir quels agents sont utilisés au sein de l’organisation, à quoi ceux-ci ont accès et quelles actions leur sont autorisées ; ainsi que la vérification continue plutôt que la présomption, car il faut vérifier en permanence le comportement correct des agents et des chatbots, sans le tenir pour acquis.

Pour les agents d'IA déjà utilisés en production, Boele recommande de commencer par se poser quatre questions essentielles : quels agents sont actuellement exploités – y compris ceux qui ont été créés par des personnes n'ayant pas le rôle de développeur ? À quoi chacun de ces agents a-t-il accès ? De quelles autorisations chaque agent dispose-t-il qui vont au-delà de ce qui était initialement prévu ? Et un écart par rapport à ce cadre serait-il même remarqué ? Si la réponse à cette dernière question est « non », c'est précisément cette faille qu'il faut combler en premier lieu.

Source : www.checkpoint.com

Cet article est paru initialement sur m-q.ch - https://www.m-q.ch/de/ki-agenten-ausser-kontrolle-drei-vorfaelle-in-vierzehn-tagen/