L'injection de prompts représente le principal risque pour les applications d'entreprise utilisant des modèles de langage, selon l'OWASP, qui conserve ainsi sa première place dans son classement des 10 principaux risques pour la deuxième année consécutive. Il ne s'agit pas d'un scénario théorique ni d'un problème de laboratoire : c'est une conséquence directe du fonctionnement de ces systèmes.
Un modèle de langage ne fait pas de distinction entre les instructions fournies par son développeur et le texte qu'il traite. Tout est perçu comme du texte. Si un document lu par le système contient une instruction, il est possible qu'il la traite comme telle.
La version connue — un utilisateur écrivant « ignorez vos instructions » — est la moins inquiétante, car l'attaquant doit être présent et ses permissions sont celles de n'importe quel autre utilisateur.
La version qui compte dans un contexte professionnel est la injection indirecteLe texte malveillant n'est pas écrit par l'utilisateur ; il provient du contenu que le système traite dans le cadre de son fonctionnement normal.
Les vecteurs habituels :
Dans tous les cas, le processus est identique : une personne extérieure rédige un texte que votre système lira et qui peut influencer son fonctionnement. Et dans tous les cas, les dommages potentiels sont exactement proportionnels à l’étendue des autorisations que vous lui avez accordées.
La solution intuitive consiste à filtrer les instructions suspectes à l'entrée. Cette méthode n'est pas fiable, pour trois raisons :
Le langage possède une infinité de formes. Toute liste de motifs interdits peut être reformulée. Les instructions peuvent être données dans une autre langue, paraphrasées ou divisées en plusieurs phrases.
Il est possible qu'il soit caché. Texte vide sur une page blanche dans un PDF, métadonnées, contenu que l'utilisateur ne voit pas mais que le système lit.
Le filtre ne peut pas connaître l'intention. Un courriel légitime peut contenir la phrase « veuillez transférer ceci au service comptable ». Le système ne dispose d'aucun moyen fiable de déterminer s'il s'agit d'une instruction pour lui-même ou d'une information destinée à une personne.
La conclusion opérationnelle est à la fois dérangeante et éclairante : Nous devons partir du principe que l'injection aura lieu et concevoir le système de manière à ce que cela n'ait pas d'importance..
Principe | Qu'est-ce que cela implique ? | Ce que cela empêche |
|---|---|---|
permis minimum | Le système n'accède qu'aux données nécessaires à sa tâche spécifique. | Qu'une instruction injectée atteigne des données externes |
Séparation des canaux | Le contenu externe n'est jamais considéré comme une instruction système. | Laissons un PDF redéfinir le comportement |
Liste blanche des actions | Seules les opérations explicitement mentionnées sont autorisées. | Qu'un imprévu se produise |
Validation humaine dans l'irréversible | Paiements, communications externes, changements de production | Que les dommages se matérialisent sans examen |
Inscription complète | Il enregistre ce qui a été saisi et ce qui a été exécuté. | Que l'incident est irréparable |
Ces cinq points relèvent de choix architecturaux, et non de la configuration d'outils. De plus, leur mise en œuvre avant la construction n'engendre que peu de coûts ; c'est pourquoi cet article s'inscrit davantage dans une réflexion sur la conception que sur la sécurité.
OWASP ajoute deux risques connexes à ce tableau qu'il convient de mentionner : LLM02, divulgation d'informations sensibles, et LLM06, capacité excédentaire. Ces trois éléments présentent le même problème, abordé sous différents angles : ce que le système peut lire, ce qu’il peut faire et qui peut l’influencer. Nous avons développé cela dans Accorder des autorisations à un agent est une décision risquée
Imaginez un assistant qui traite les factures arrivant dans la boîte mail administrative : il extrait le montant, le fournisseur et le numéro de compte, puis prépare le paiement.
Un fournisseur malhonnête envoie une facture comportant une brève instruction en bas de page demandant au système d'utiliser un numéro de compte différent. Si l'assistant est autorisé à effectuer les paiements et que personne ne vérifie le numéro de compte auprès du fournisseur, la fraude est perpétrée avec l'efficacité d'un système automatisé.
Notez que dans cet exemple, le modèle n'a pas failli : il a exécuté précisément la tâche demandée par le texte. Le problème réside dans sa conception, qui a permis à un texte externe de déterminer une information cruciale sans la vérifier auprès de la source de référence.
D'où la règle que nous répétons dans chaque projet : Le modèle élabore et interprète ; le système établit les faits.. Les montants, les comptes, les statuts et les autorisations sont vérifiés par rapport au système source ; ils ne sont jamais repris du contenu traité.
Lorsqu'une solution basée sur l'IA et capable de lire du contenu externe est présentée, trois questions permettent de distinguer les solutions sérieuses des solutions improvisées :
Un fournisseur qui répond « notre modèle n'est pas concerné par ce problème » n'a pas saisi le risque. Le confinement ne dépend pas de la qualité du modèle, mais du périmètre qui lui est défini.
Il s'agit de la manipulation du comportement d'un modèle de langage par le biais de texte que le modèle traite comme s'il s'agissait d'instructions. OWASP le classe comme le principal risque dans son Top 10 des applications LLM d'ici 2025, car le modèle ne fait pas de distinction structurelle entre les instructions du développeur et le contenu qu'il analyse.
Voici la variante pertinente dans les environnements professionnels : les instructions ne sont pas rédigées par l’utilisateur, mais figurent dans le contenu que le système traite régulièrement — un courriel d’un fournisseur, un PDF, une page Web, un ticket d’assistance ou un champ de formulaire.
De façon non fiable. Le langage permet d'innombrables reformulations, des instructions peuvent être dissimulées dans du texte invisible ou des métadonnées, et un filtre ne peut déterminer l'intention. La bonne approche consiste à partir du principe que cela se produira et à limiter les risques potentiels grâce à des autorisations et des contrôles.
Avec cinq principes de conception : autorisation minimale par tâche, séparation entre le contenu externe et les instructions système, liste blanche des actions autorisées, validation humaine obligatoire dans les opérations irréversibles et journalisation complète des entrées et des actions effectuées.
Oui, si le système les traite et dispose de permissions étendues. Un exemple typique est une facture comportant une instruction de modification du numéro de compte de paiement. Le problème ne réside pas dans le modèle lui-même, mais dans sa conception qui permet à un texte externe de déterminer des données critiques sans vérification auprès de la source.
Que se passe-t-il si le contenu traité contient des instructions adressées au système ? Quelles sont les capacités du système dans le pire des cas ? Un incident survenu il y a un mois pourrait-il être reconstitué ? Nier la possibilité d’une attaque témoigne d’une méconnaissance du risque.
Votre système d'IA lit-il le contenu rédigé par des tiers ? Nous examinons la portée, les autorisations, la séparation des canaux et la traçabilité, et nous vous indiquons quel est le pire scénario possible avec la conception actuelle. Demander un avis →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
