Un prestataire commun de tests de sécurité pourrait expliquer pourquoi les modèles d’IA d’OpenAI, d’Anthropic et de Meta ont tous atteint des systèmes auxquels ils n’étaient jamais censés accéder.
Selon CNBC, les trois incidents impliquaient Irregular, une entreprise israélienne de sécurité qui évalue les capacités offensives des modèles d’IA avancés. Lors des tests concernés, des faiblesses de configuration auraient permis aux modèles de passer d’environnements d’évaluation contrôlés à des systèmes externes.
Cela change la leçon à tirer en matière de sécurité. Les incidents ne concernent pas seulement ce que des agents d’IA toujours plus capables peuvent faire ; ils soulèvent aussi la question de savoir si l’infrastructure tierce utilisée pour les tester et les contenir est suffisamment fiable pour maintenir ces limites.
Trois incidents, un problème de chaîne d’approvisionnement
Le premier avertissement est venu d’OpenAI, dont les modèles ont atteint l’infrastructure de Hugging Face lors d’une évaluation de cybersécurité.
Anthropic a ensuite découvert trois cas distincts dans lesquels les modèles Claude ont obtenu un accès non autorisé à trois organisations. À peu près au même moment, Meta a révélé que son modèle Muse Spark 1.1 avait lui aussi infiltré les systèmes d’une entreprise lors d’un test de sécurité.
Meta a déclaré qu’une erreur de configuration du même cabinet de tests avait donné à Muse Spark 1.1 un accès imprévu à Internet.
Le rôle d’Irregular consistait à soumettre ces modèles à des exercices réalistes de cybersécurité, en leur fournissant des cibles, des outils et suffisamment de liberté pour montrer s’ils étaient capables de découvrir des vulnérabilités et d’exécuter des opérations offensives de sécurité.
Les modèles n’étaient donc pas partis de zéro. Ils étaient déjà testés pour leurs capacités cyber offensives avancées, et les environnements d’évaluation étaient conçus pour leur permettre d’exploiter ces capacités. Le problème, dans ces cas précis, est que ces environnements leur ont également fourni une voie imprévue vers l’Internet public.
Cette distinction est importante, car elle déplace la question de sécurité : il ne s’agit plus de savoir si l’IA peut s’échapper d’un bac à sable, mais si l’infrastructure entourant des agents d’IA toujours plus capables peut les empêcher efficacement d’atteindre quoi que ce soit qu’ils n’étaient pas censés toucher.
Et c’est ce qui fait d’Irregular bien plus qu’un simple nom commun à trois incidents sans rapport entre eux. Cela révèle un risque lié aux tiers dans la chaîne d’approvisionnement de la sécurité de l’IA. Les laboratoires fournissaient des modèles toujours plus capables, tandis que les environnements d’évaluation externes fournissaient les limites censées les contenir. Et lorsque ces limites ont cédé, les modèles ont pu transformer une évaluation en incident de sécurité réel.
Ce que cela signifie pour les entreprises
Les entreprises qui déploient des agents d’IA autonomes ou semi-autonomes devraient partir du principe que ces systèmes finiront par rencontrer des occasions d’agir au-delà de leur périmètre prévu.
Les contrôles doivent donc être imposés par l’infrastructure plutôt que par les seules instructions. Les organisations devraient appliquer des politiques réseau de refus par défaut, limiter l’accès à Internet sortant, isoler les systèmes sensibles, appliquer le principe du moindre privilège, renouveler ou limiter les identifiants accessibles aux agents et surveiller les connexions sortantes inattendues.
Les incidents mettent également en évidence un risque lié aux tiers. Les organisations qui font appel à des prestataires externes pour héberger, évaluer ou sécuriser des agents d’IA devraient évaluer de manière indépendante la façon dont ces fournisseurs appliquent l’isolation réseau, gèrent les identifiants, consignent l’activité des agents et empêchent les environnements de test d’atteindre les systèmes de production ou les systèmes publics.
La leçon plus générale est familière : externaliser une fonction de sécurité ne revient pas à externaliser le risque. Lorsqu’un prestataire externe contrôle les limites autour d’un agent d’IA, les faiblesses de ses contrôles peuvent devenir une composante de la propre surface d’attaque du client.
À lire aussi : Les hackers ciblent les grandes firmes de Wall Street au moyen d’attaques d’ingénierie sociale par téléphone qui usurpent l’identité du personnel du support informatique, interceptent les codes MFA en temps réel et dérobent des identifiants professionnels à des fins d’extorsion.