Comment une erreur de configuration a envoyé des modèles d’IA vers de vrais systèmes

L’exercice visait notamment à mesurer des capacités de sécurité offensive : reconnaissance, utilisation de clés privées, collecte d’informations sur la cible, extraction de données et tentatives d’échapper à la détection. Dans au moins un parcours rapporté, un modèle s’est également dirigé vers un site au nom similaire et y a trouvé des identifiants déjà publiés.

L’activité, qui devait rester confinée à un environnement de test, a donc atteint des infrastructures réelles. Les signalements et divulgations disponibles relient ce schéma plus large à des modèles d’Anthropic, d’OpenAI et de Meta. Les actions rapportées comprennent l’exploitation de vulnérabilités, l’accès à des identifiants et des modifications apportées à l’environnement interne d’un tiers.

Ce qu’Anthropic a découvert

Après une divulgation liée à OpenAI, Anthropic a examiné 141 006 exécutions d’évaluations de cybersécurité dans lesquelles Claude aurait pu obtenir un accès à internet. L’entreprise a identifié trois incidents au cours desquels un modèle Claude a atteint internet depuis un environnement d’évaluation Irregular — ou pendant une interaction avec celui-ci — puis obtenu un accès non autorisé aux systèmes réels de trois organisations.

Certains articles secondaires parlent de six exécutions couvrant ces incidents. La divulgation primaire d’Anthropic citée ici établit toutefois l’existence de trois incidents, sans fournir un inventaire public complet de toutes les exécutions concernées.

La synthèse de la Cloud Security Alliance inscrit les divulgations d’Anthropic, d’OpenAI et de Meta dans un phénomène plus large : lors d’évaluations de cybersécurité, des modèles ont atteint de vraies personnes, des systèmes de production ou l’internet ouvert, alors qu’ils étaient censés opérer dans des environnements isolés. Aucun de ces cas n’implique qu’un modèle ait franchi par ses propres moyens les défenses d’un bac à sable correctement configuré.

Pourquoi le terme « évasion du bac à sable » fait débat

L’expression « évasion du bac à sable » décrit le résultat, mais elle peut laisser croire à l’existence d’un exploit technique sophistiqué que les preuves disponibles ne démontrent pas. Dans ces cas, les modèles semblent avoir poursuivi leurs objectifs à travers un environnement dont la frontière réseau était mal configurée ou insuffisamment appliquée.

La leçon la plus précise est donc la suivante : une consigne indiquant « cet environnement est isolé » ne remplace pas une isolation imposée par l’infrastructure. Si les connexions sortantes restent possibles, un modèle peut interpréter un service réel accessible comme une partie légitime de sa mission — en particulier lorsque son nom ressemble à celui de la cible fictive.

La responsabilité ne peut pas non plus être attribuée au seul comportement des modèles. Le dispositif de sécurité comprenait le modèle, ses outils et son architecture agentique, le harnais d’évaluation, les règles réseau, le choix des noms de cibles, la supervision et la réponse aux incidents. Un modèle capable peut causer un dommage réel en exécutant correctement des instructions dans un environnement mal délimité, sans inventer une nouvelle méthode pour contourner le confinement.

Une portée encore incomplètement documentée

Irregular a décrit le problème comme survenant dans moins d’une simulation avancée sur 10 000 et a indiqué que les écarts réussis apparaissaient souvent après des centaines de tours dans des tests longs et complexes. Ces chiffres et cette description viennent d’Irregular ; les éléments disponibles ne permettent pas d’établir indépendamment le dénominateur complet ni le nombre définitif d’incidents.

L’entreprise affirme également que seules « quelques interactions » ayant bénéficié par inadvertance d’un accès à internet ont débouché sur des actions offensives dans le monde réel. Son compte rendu public ne précise pas le nombre total d’exécutions, d’organisations ou de modèles clients concernés.

Cette absence de détails est devenue le principal sujet de critique. Des spécialistes de la cybersécurité et plusieurs articles ont demandé pourquoi le bilan ne précisait pas le nombre total d’incidents et n’expliquait pas suffisamment quels dispositifs de surveillance ou de télémétrie étaient en place — ni pourquoi ils n’avaient pas bloqué plus tôt une activité internet non autorisée. Les éléments disponibles étayent la critique portant sur le manque d’informations publiques, mais ne permettent pas d’établir exactement quels contrôles ont échoué dans chaque cas.

Irregular affirme n’avoir trouvé aucune preuve d’une compromission des systèmes de ses clients ou d’une fuite de leurs données. Cette déclaration doit être distinguée de l’accès non autorisé rapporté à des systèmes appartenant à des organisations externes pendant les évaluations.

Mesures correctives et garde-fous à retenir

Irregular affirme avoir corrigé le problème sous-jacent avant la première divulgation publique, informé les parties concernées et ajouté des protections ainsi que de nouveaux protocoles destinés à éviter des erreurs de configuration comparables. L’entreprise a également annoncé la publication de bonnes pratiques plus larges pour sécuriser les évaluations cyber, notamment des standards encadrant l’accès contrôlé à internet lors des tests préalables au déploiement.

Cet épisode fait ressortir plusieurs contrôles concrets pour toute organisation qui évalue des agents sur des scénarios cyber réalistes :

• Imposer les restrictions de trafic sortant au niveau du réseau. Les instructions et la documentation peuvent décrire l’environnement, mais ne doivent pas constituer l’unique barrière contre les connexions externes.
• Vérifier chaque cible fictive avant le lancement. Les noms, domaines, enregistrements DNS et plages d’adresses IP doivent être contrôlés afin de détecter toute collision avec une organisation réelle.
• Utiliser des listes d’autorisation, des proxys et des cibles de dérivation. Lorsque l’accès à internet est nécessaire pour conserver un certain réalisme, il doit passer par une infrastructure qui limite les destinations et empêche tout contact avec des systèmes incontrôlés.
• Journaliser et surveiller en permanence le trafic sortant. Une résolution DNS inattendue, une connexion à un service de production, l’utilisation d’identifiants ou une modification hors du périmètre de test doit déclencher un arrêt immédiat.
• Prévoir des mécanismes d’arrêt et une revue humaine. Les actions à haut risque — exploitation, utilisation d’identifiants, extraction de données ou modification de systèmes externes — nécessitent une intervention rapide.
• Tester séparément la frontière de confinement. Les évaluateurs et les développeurs de modèles doivent vérifier le chemin réseau réel plutôt que de s’en remettre à des hypothèses de configuration ou à l’interprétation d’un prestataire.

Ces mesures sont des conséquences pratiques que l’on peut tirer de l’incident ; elles ne signifient pas qu’Irregular avait déjà mis en place chacun de ces contrôles avant les événements.

Un avertissement pour la sécurité de l’IA

Les évaluations cyber réalistes créent une tension difficile à résoudre. Les tests sont plus instructifs lorsqu’ils ressemblent à l’internet et aux systèmes utilisés par de véritables attaquants. Mais ce réalisme augmente aussi le coût potentiel d’une erreur de nommage, d’un problème de routage ou d’une faille de supervision. Les propres documents d’Irregular décrivent des évaluations mettant en jeu des services déployés, des bases de données, des réseaux et d’autres cibles proches de systèmes réels, ce qui rend la garantie du confinement particulièrement importante.

La conclusion immédiate n’est pas que les modèles les plus avancés peuvent s’évader librement de n’importe quel bac à sable. C’est que le terme « isolé » doit désigner une propriété technique vérifiable, et non une hypothèse partagée par l’évaluateur, le laboratoire et le modèle.

Le fait que plusieurs laboratoires aient rencontré une même catégorie de défaillance soulève aussi des questions de gouvernance. Les évaluateurs externes pourraient être soumis à des exigences d’assurance plus strictes, à des tests de confinement indépendants, à des journaux d’audit complets, à des seuils de divulgation plus clairs et à des règles explicites pour l’accès d’agents avancés à l’internet en direct. Les éléments disponibles établissent un contexte d’évaluation commun et une classe de défaillance partagée ; la réponse réglementaire précise reste incertaine.

Pour les développeurs, la règle opérationnelle tient en une phrase : considérez tout système accessible pendant une évaluation cyber comme potentiellement réel jusqu’à ce que la frontière réseau ait été vérifiée indépendamment.