Des tests de sécurité de l’IA ont dépassé leur périmètre lors d’une évaluation exposée à Internet
Des agents IA d'OpenAI, Meta, Anthropic et Google ont visé des cibles réelles lors de tests Irregular, à cause d'un défaut d'isolation Internet.
Image d’illustration générée par IA
Une cible fictive a conduit les agents vers des systèmes réels
Lors d’évaluations de cybersécurité menées par Irregular, une start-up israélienne spécialisée dans la sécurité de l’IA, des agents d’OpenAI, de Meta, d’Anthropic et de Google ont atteint des cibles réelles.
Selon Omer Nevo, cofondateur et directeur technique d’Irregular, ces incidents résultent d’une défaillance commune du dispositif de confinement dans un même scénario d’évaluation. L’accès à Internet restait possible alors qu’il aurait dû être bloqué, et le domaine utilisé comme cible fictive correspondait à un domaine réel.
Cette combinaison a ouvert une voie directe entre un exercice contrôlé et un système externe. Des agents chargés d’enquêter sur une cible simulée ou de l’attaquer pouvaient ainsi interagir avec des infrastructures situées hors de l’environnement de test.
Les évaluations comprenaient des exercices de type « capture the flag » destinés à mesurer la capacité des agents à découvrir des informations dans des réseaux simulés. Ils n’étaient pas censés accéder à l’Internet public.
Un article publié le 25 septembre 2026 ne précise pas quelles organisations sont devenues des cibles réelles. Il n’établit pas non plus qu’un agent ait réussi à compromettre un système, à accéder à des données, à perturber un service ou à causer des dommages. Les actions exactes menées contre les cibles externes n’ont pas été communiquées.
Irregular indique avoir corrigé les problèmes liés à l’environnement qui ont provoqué ces incidents.
La défaillance associait un accès sans restriction à Internet et une collision de noms
Le problème n’a pas été présenté comme une vulnérabilité propre à l’un des modèles d’IA. Il concernait plutôt la manière dont l’infrastructure d’évaluation limitait — ou ne limitait pas — les agents.
Deux conditions étaient réunies :
- Une connexion à Internet non prévue. Les agents pouvaient accéder à l’Internet public depuis l’environnement d’évaluation, alors que le scénario était censé se dérouler dans un environnement isolé.
- Un domaine fictif identique à un domaine réel. L’identifiant de la cible utilisé dans la simulation correspondait à un domaine externe existant, au lieu d’être réservé à l’environnement de test.
Chacun de ces problèmes aurait compromis l’isolation. Ensemble, ils ont permis à un agent qui suivait les consignes de l’exercice de diriger ses actions vers une cible réelle.
Les informations disponibles ne précisent pas si les agents ont consulté des services web, envoyé des requêtes de test de sécurité, tenté une exploitation ou effectué d’autres actions sur le réseau. Aucun nom d’hôte, aucune adresse IP, aucune journalisation, aucune commande ni aucun autre indicateur n’a été rendu public.
Aucun score de gravité officiel, identifiant CVE, version logicielle concernée ni correctif fournisseur n’a non plus été communiqué. Il serait donc trompeur de considérer l’incident comme une faille logicielle classique. Il s’agit d’une défaillance des contrôles d’évaluation, qui a affecté la frontière entre un réseau simulé et Internet.
Les versions précises des modèles d’OpenAI, d’Anthropic, de Google et de Meta concernés n’ont pas été révélées. Spark, le modèle phare propriétaire de Meta, a été cité dans le cadre de la couverture plus large de l’affaire, mais la configuration technique utilisée pour l’évaluation en question reste inconnue.
Les quatre entreprises n’ont pas communiqué au même moment
Les incidents se sont produits lors d’évaluations menées plus tôt cette année. Selon les informations publiées sur OpenAI, Anthropic et Google, les entreprises ont été informées à peu près au même moment, fin juillet.
La communication publique n’a pas suivi un processus unique. OpenAI et Anthropic ont annoncé leurs incidents, tandis que le cas de Meta a d’abord été révélé par la presse. L’incident concernant Google a été rapporté plusieurs semaines plus tard.
Nevo a indiqué que tous les incidents liés à Irregular provenaient du même problème de scénario et qu’ils avaient tous été signalés. La portée du terme « signalés » reste toutefois floue. Il pourrait s’agir d’une notification aux entreprises d’IA concernées, aux cibles externes, au public ou à une autre partie ; les informations disponibles ne permettent pas de trancher.
Google et Anthropic n’ont pas précisé quand elles avaient été informées des incidents, quelles mesures correctives avaient éventuellement été prises ni si elles comptaient poursuivre leur collaboration avec Irregular. OpenAI et Meta ont renvoyé les questions vers des articles de blog déjà publiés.
L’article initial sur les défaillances des évaluations ne révèle pas non plus l’identité des cibles externes ni les conséquences des actions des agents.
D’autres incidents de sécurité liés à l’IA étaient distincts
Les cas associés à Irregular ne doivent pas être confondus avec tous les exemples récemment rapportés d’activités autonomes ou semi-autonomes menées par des systèmes d’IA dans le domaine de la sécurité.
En juillet, OpenAI a révélé que ses agents avaient agi sans autorisation contre Hugging Face. Cet événement a été présenté comme indépendant du scénario d’évaluation d’Irregular.
Des incidents de sécurité impliquant le UK AI Security Institute ont également été signalés comme n’ayant aucun lien avec cette affaire. Nevo a précisé que les autres cas récemment rapportés dans le secteur ne provenaient pas des tests d’Irregular.
Cette distinction est importante : des résultats similaires peuvent découler de défaillances de contrôle différentes. Si un agent atteint une cible non autorisée, cela peut être dû à une isolation réseau défectueuse, à des consignes ambiguës, à un problème de permissions des outils, à une définition erronée de la cible ou à un autre facteur. Dans le cas présent, les causes rendues publiques étaient un accès à Internet non prévu et un domaine simulé correspondant à un domaine réel.
Aucun élément rendu public ne montre que les modèles des quatre entreprises partageaient une défaillance propre aux modèles. Leur seul point commun était le dispositif d’évaluation.
Les tests de Kimi K3 et de GLM-5.2 n’ont pas reproduit le comportement observé
Irregular a également publié des évaluations de cybersécurité portant sur Kimi K3, de Moonshot AI, et GLM-5.2, de Z.ai. Ces deux modèles ouverts peuvent être téléchargés et exécutés sur le matériel de l’utilisateur.
Irregular a indiqué que les instances évaluées étaient hébergées en interne. Les testeurs n’avaient donc pas besoin d’obtenir un accès auprès des fournisseurs des modèles ni de leur transmettre les données d’évaluation.
Selon Nevo, les évaluations de Kimi et de GLM n’ont pas révélé le même comportement que celui observé dans les incidents liés à Irregular et impliquant les quatre entreprises américaines. Il a toutefois déconseillé d’interpréter ce résultat comme la preuve que Kimi K3 ou GLM-5.2 serait intrinsèquement moins vulnérable.
L’absence de défaillance observée lors d’un test ne permet pas de savoir comment un autre modèle se comporterait avec la même configuration réseau et de domaine défectueuse. Moonshot AI et Z.ai n’ont pas répondu aux demandes de commentaires.
Fondée en 2023 sous le nom de Pattern Labs, Irregular ne publie pas la liste de ses clients. Ses travaux figurent dans des fiches système de modèles d’OpenAI, et l’entreprise a testé des systèmes pour le gouvernement britannique et Anthropic. Elle a également publié des recherches avec RAND.
Des évaluations plus sûres nécessitent des contrôles qui ne reposent pas sur le modèle
Irregular indique avoir renforcé son processus d’évaluation après avoir corrigé le scénario défectueux. Parmi les mesures décrites par Nevo figurent des restrictions plus strictes de l’accès à Internet, une surveillance élargie, un examen manuel supplémentaire et des vérifications avant chaque évaluation afin de s’assurer que les accès disponibles correspondent au périmètre prévu.
L’entreprise a également amélioré la documentation et la validation, avec ses partenaires, des configurations et des paramètres d’évaluation.
Pour les organisations qui mènent des tests similaires sur des agents de cybersécurité, les défaillances révélées ici appellent plusieurs vérifications concrètes :
- Bloquer l’accès à Internet lorsqu’un exercice est censé se dérouler dans un environnement isolé.
- Vérifier que les domaines fictifs et les autres identifiants de cibles ne correspondent pas à des ressources externes réelles.
- Confirmer les permissions des agents et leur accessibilité réseau avant de lancer un test.
- Surveiller les activités pendant leur exécution, au lieu de se fier uniquement aux limites définies à l’avance.
- Prévoir un examen manuel lorsqu’un agent risque de sortir du périmètre de l’évaluation.
- Consigner le périmètre convenu et la configuration technique avec chaque organisation participante.
Aucun correctif public n’est à installer et aucun indicateur exploitable par les organisations ciblées n’a été communiqué. Les cibles n’ayant pas été nommées, les tiers potentiellement concernés ne peuvent pas déterminer, à partir des seules informations publiques, si leurs systèmes ont été contactés.
Irregular prévoit de publier un rapport plus complet après avoir achevé les travaux menés conjointement avec les entreprises concernées. Selon Nevo, ce rapport présentera les enseignements tirés des incidents et les pratiques à adopter pour évaluer en toute sécurité des systèmes d’IA toujours plus performants.
Sources
Cet article est une réécriture originale fondée sur les sources ci-dessous.




