Pour bloquer une cyberattaque d’IA, il suffit parfois d’aborder un sujet que le système n’a pas le droit de traiter
Des chercheurs ont découvert une méthode étrange mais efficace pour stopper net un agent de piratage piloté par IA, en utilisant exactement la même astuce que les hackers emploient déjà contre les systèmes d’IA.
PUBLICITÉ
PUBLICITÉ
Surtout, cette méthode exploite les garde-fous intégrés, ou sujets interdits, sur lesquels reposent les grands systèmes d’IA, comme Claude qui bloque les requêtes liées à la création d’armes biologiques, ou les modèles chinois qui ignorent les sujets politiques sensibles comme la place Tiananmen, afin de mettre fin à une attaque de cybersécurité menée par une IA.
Course contre la machine
Cette technique vient de Tracebit, une société de sécurité basée à Londres, et s’appuie sur une étude que l’entreprise a publiée en mai.
À l’époque, Tracebit a fourni à dix modèles d’IA parmi les plus avancés un faux réseau d’entreprise à infiltrer, avec de vraies vulnérabilités, et les a laissés agir librement comme des attaquants autonomes.
Des leurres, appelés canaris, étaient dissimulés dans ce réseau. Ils étaient conçus pour ressembler à de vrais mots de passe et identifiants de connexion. Dès qu’un canari était touché, les défenseurs recevaient une alerte.
Les résultats étaient encourageants. Sur 951 tentatives d’attaque, ces canaris ont donné un avertissement aux défenseurs avant que l’IA n’obtienne un accès administrateur dans 95,9 % des cas, avec un délai médian de huit minutes.
Cependant, huit minutes, c’est peu de temps pour réagir et stopper une attaque. Les modèles d’IA mettaient en moyenne 14 minutes pour compromettre complètement le réseau, de sorte qu’un avertissement huit minutes avant laisse à l’équipe de sécurité environ six minutes pour remarquer l’alerte, comprendre ce qui se passe et arrêter l’attaque.
Face à quelque chose qui agit à la vitesse de la machine, c’est presque rien.
Mais si les systèmes d’IA sont programmés pour se mettre à l’arrêt lorsqu’ils sont confrontés à certaines requêtes politiquement sensibles, alors cette astuce pourrait réellement fonctionner.
Un développeur peut réentraîner un modèle pour qu’il soit moins frileux sur une question de sécurité, mais il est bien plus difficile de retirer des restrictions politiques intégrées pour des raisons réglementaires ou de politique interne.
Ces sujets politiquement sensibles ou proches des questions de sécurité ne sont pas un bug à corriger, mais un choix de conception délibéré que le développeur est tenu de conserver.
Retourner contre les pirates leur propre arme
L’injection de prompts est jusqu’ici surtout une arme utilisée par les attaquants eux-mêmes.
En cachant une instruction dans un e-mail, une page web ou une invitation de calendrier, un agent d’IA qui la lit peut suivre cet ordre dissimulé au lieu d’accomplir la tâche prévue.
Cette technique a déjà été utilisée directement contre les défenses des systèmes d’IA, avec des malwares conçus pour tromper les outils d’analyse basés sur l’IA et les amener à les déclarer inoffensifs, simplement en y intégrant du texte destiné à embrouiller l’IA qui les lit.
Tracebit a décidé de retourner cette idée. Plutôt que de simples leurres qui se contentent de déclencher une alerte, l’entreprise a glissé de courts textes dans ses faux secrets, rédigés pour pousser tout attaquant piloté par IA vers quelque chose que ses propres règles de sécurité ne lui permettent pas de faire.
Lorsque l’IA lit ce texte en explorant le système, ses garde-fous intégrés se déclenchent et elle s’arrête tout simplement. Tracebit appelle cela une « bombe contextuelle ».
L’astuce a dû être adaptée à chaque modèle d’IA. Des contenus faisant référence à des armes biologiques dangereuses ont, par exemple, stoppé de manière fiable les modèles occidentaux.
Est-ce que cela fonctionne vraiment ?
Tracebit a mené le test sur cinq grands modèles d’IA : Opus 4.8, Gemini 3.1 Pro, GLM 5.2, DeepSeek 4 Pro et Kimi K2.6. Sur 152 tentatives d’attaque, les résultats sont frappants.
La proportion d’exécutions aboutissant à un accès administrateur est tombée de 57 % à 5 %. La compromission totale, c’est-à-dire l’accès administrateur plus un accès persistant au système, a baissé de 36 % à 1 %.
La part des exécutions menant à au moins une étape de l’attaque a chuté de 91 % à 15 %. Et, point crucial, chaque exécution qui rencontrait une bombe contextuelle déclenchait d’abord une alerte canari, y compris celles qui échouaient à s’introduire dans le système.
Opus 4.8 fournit l’exemple le plus clair. C’était aussi l’attaquant le plus performant du groupe, atteignant un accès administrateur dans 93 % des exécutions sans bombe contextuelle. Une fois la bombe ajoutée, il a échoué à chaque fois.
Ce que cela ne résout pas
Personne chez Tracebit ne prétend que cela règle définitivement le problème de l’injection de prompts.
Il n’existe toujours aucun moyen sûr d’empêcher les modèles d’IA de confondre parfois une instruction avec une simple donnée, et c’est précisément cette faille sur laquelle repose cette technique.
Elle ne remplace pas non plus les travaux précédents sur les canaris.
Les deux approches sont conçues pour fonctionner ensemble : l’étude de mai offre aux défenseurs un avertissement huit minutes avant la compromission, et la bombe contextuelle tente de leur offrir encore plus de temps en stoppant l’attaque avant la fin de cette fenêtre d’alerte.