Une bataille invisible et constante se joue sous nos yeux.
Elle oppose deux forces contraires : d’un côté, les capacités grandissantes des modèles de langage (LLM) à générer des réponses toujours plus précises, rendues possibles grâce à l’ingestion de volumes astronomiques de données parfois sensibles ; de l’autre, les garde-fous intégrés à ces systèmes, qui sont, eux, conçus pour empêcher toute divulgation d’informations confidentielles, sans jamais brider les capacités pratiques de l’outil.
Cette course effrénée, entre montée en puissance et limitation des risques, rythme le quotidien des chercheurs en cybersécurité et des concepteurs de LLM. Tous ont conscience que la sécurité de ces systèmes constitue un pilier essentiel pour assurer leur pérennité dans nos usages futurs.
Au cœur de ces préoccupations se trouvent les attaques par injection de prompt.
Qu’est-ce qu’une injection de prompt dans l’IA ?
Les attaques par injection de prompt regroupent toutes les tentatives visant à manipuler les instructions d’un modèle de langage, afin de lui faire produire des réponses ou exécuter des actions qu’il ne devrait pas réaliser selon ses règles de sécurité ou les intentions de ses concepteurs.
Quand le modèle contourne effectivement ses garde‑fous (divulgation de données sensibles, exécution d’actions proscrites, production de contenu interdit), on parle couramment de « jailbreak ».
On peut distinguer ces attaques en deux catégories : les attaques par injections directes et indirectes.
Quelle différence entre une injection directe et indirecte ?
Attaques par injections directes
Les injections directes consistent à insérer, dans le même message adressé au modèle, une instruction explicite, cachée ou détournée, destinée à le pousser à ignorer ou redéfinir ses consignes initiales.
Le texte malveillant peut se présenter comme une exception, un ordre « supérieur », un test de sécurité ou une consigne interne, jouant sur la tendance des modèles à suivre l’instruction la plus récente, la plus forte ou la plus détaillée.
Le jeu Gandalf de Lakera illustre bien ce scénario en demandant au modèle de protéger un mot de passe tout en incitant l’utilisateur à des tours de passe‑passe textuels pour l’amener à le révéler.
Attaques par injections indirectes
Les injections indirectes, plus insidieuses, ne passent pas par le texte saisi directement par l’utilisateur, mais par des ressources externes que le LLM ou l’agent va consulter : pages web, documents, bases de données, images contenant du texte ou encore d’adresses URL.
Le contenu malveillant y est dissimulé comme une « pseudo‑instruction » que le système lira et interprétera comme une consigne légitime, par exemple lors d’une navigation automatique ou d’une exploration de code.
Ce type d’attaque est particulièrement critique dans les navigateurs IA, les agents autonomes et les assistants de développement, où une ressource externe peut détourner le comportement global.
Pourquoi les modèles de langage sont-ils vulnérables à ce type d’attaque ?
Ces attaques, qu’elles soient directes ou indirectes, exploitent un point structurel que les concepteurs peinent encore à atténuer : pour le LLM, instructions et données sont toutes deux du texte dans un même flux, sans séparation intrinsèque robuste entre ce qui doit être obéi et ce qui doit être traité comme simple contenu.
Si la fuite d’informations sensibles reste l’un des scénarios les plus intuitifs, les attaques par injection de prompt visent un spectre d’objectifs bien plus large. Elles peuvent chercher à influencer ou prendre le contrôle du comportement global du système, en agissant sur les décisions ou sur les actions qu’il déclenche dans son environnement technique.
Dans des systèmes plus intégrés, où le LLM peut appeler des outils, exécuter du code ou invoquer des API, ces attaques peuvent conduire à des actions bien plus concrètes : modification de fichiers, accès à des ressources internes, envoi de requêtes réseau ou même ouverture de rideaux…
Face à ces menaces, la défense ne se repose plus uniquement sur les garde‑fous internes du modèle. L’enjeu consiste à limiter l’impact des injections, même lorsqu’elles parviennent à franchir les protections purement linguistiques.
Parmi les approches couramment explorées, on trouve le filtrage des entrées et des contenus externes, la séparation stricte des rôles et des canaux (instructions système, demandes utilisateur, données issues de documents ou de pages web), ainsi que l’encadrement des actions que le modèle est autorisé à déclencher.
Vous avez lu 0 articles sur Numerama ce mois-ci
Tout le monde n'a pas les moyens de payer pour l'information.
C'est pourquoi nous maintenons notre journalisme ouvert à tous.
Mais si vous le pouvez,
voici trois bonnes raisons de soutenir notre travail :
- 1 Numerama+ contribue à offrir une expérience gratuite à tous les lecteurs de Numerama.
- 2 Vous profiterez d'une lecture sans publicité, de nombreuses fonctions avancées de lecture et des contenus exclusifs.
- 3 Aider Numerama dans sa mission : comprendre le présent pour anticiper l'avenir.
Si vous croyez en un web gratuit et à une information de qualité accessible au plus grand nombre, rejoignez Numerama+.
Toute l'actu tech en un clin d'œil
Ajoutez Numerama à votre écran d'accueil et restez connectés au futur !
Tous nos articles sont aussi sur notre profil Google : suivez-nous pour ne rien manquer !
