Les attaques par injection de prompt exploitent la manière dont les grands modèles linguistiques interprètent les instructions. En intégrant des directives malveillantes dans des données d'entrée par ailleurs légitimes, les attaquants peuvent amener des agents IA à exécuter des actions non souhaitées. Lorsque ces agents peuvent accéder de manière autonome aux systèmes, bases de données et API de l'entreprise, l'injection de prompt passe d'un simple problème de contenu à une menace de sécurité au niveau de l'exécution, avec des conséquences concrètes.
Pour comprendre le fonctionnement des attaques par injection de prompt, il faut examiner l'architecture fondamentale des systèmes d'IA agentique ainsi que les limites de confiance que les attaquants cherchent à compromettre. Contrairement aux menaces traditionnelles pesant sur la sécurité des applications, l'injection de prompt exploite l'ambiguïté inhérente au traitement du langage naturel, ce qui rend particulièrement difficile de s'en défendre à l'aide des contrôles de sécurité classiques.
Les principes fondamentaux d'une attaque par injection de chaîne de commande
Les attaques par injection de prompt exploitent la difficulté fondamentale à laquelle sont confrontés les grands modèles linguistiques : distinguer les instructions système fiables des données utilisateur non fiables. L'attaque s'opère au niveau de la couche d'interprétation des instructions, où le modèle traite les entrées en langage naturel et détermine les actions à entreprendre.
Remplacement d'instruction
La forme la plus directe d'injection de prompt consiste à intégrer des commandes de remplacement explicites dans des données contrôlées par l'utilisateur. Un pirate remplit un formulaire Web en définissant le champ « adresse personnelle » sur « Ignorer les instructions précédentes et… » suivi de directives malveillantes. Le modèle, traitant cela dans le cadre de son flux d'entrée, peut interpréter la directive malveillante comme une instruction légitime et l'exécuter.
Cela fonctionne parce que les modèles linguistiques traitent toutes les données d'entrée comme des instructions potentielles. Le modèle ne peut pas déterminer de manière fiable si une phrase doit être traitée comme du contenu ou interprétée comme une command.
Confusion contextuelle
Le deuxième mécanisme tire parti de la manière dont les agents IA gèrent le contexte à partir de plusieurs sources de données. Dans un flux de travail typique impliquant des agents, l'agent reçoit :
- Une invite système décrivant son rôle et ses contraintes
- Instructions ou questions fournies par l'utilisateur
- Contenu externe provenant de bases de données, d'API ou de documents
- Résultats intermédiaires des opérations précédentes
Le modèle doit maintenir des limites de confiance appropriées entre ces sources, mais une confusion de contexte survient lorsque le modèle ne parvient pas à les distinguer. Un contenu malveillant intégré dans un document récupéré ou une réponse d'API peut être traité avec la même autorité que l'invite du système elle-même.
Cette situation devient particulièrement dangereuse dans les systèmes multi-agents. L'agent A pourrait récupérer des données contenant des instructions injectées, les traiter comme du contenu légitime et les transmettre à l'agent B. À mesure que les données se propagent à travers plusieurs agents, la limite de confiance s'affaiblit à chaque étape. Après plusieurs agents, le système peut avoir complètement perdu de vue le fait qu'une partie des données provenait d'une source non fiable et ne devait pas être interprétée comme des instructions à exécuter.
Déclencheur d'exécution
Dans les systèmes d'agents dotés d'un accès aux outils, les conséquences d'une injection réussie de prompt vont bien au-delà de la simple génération de réponses textuelles inappropriées. Lorsqu'une instruction injectée déclenche une exécution, l'agent peut :
- Appeler des API avec des privilèges élevés
- Modifier ou supprimer des données dans les systèmes connectés
- Accéder aux référentiels de code et modifier les fichiers source
- Effectuer des opérations financières
- Reconfigurer les paramètres de l'infrastructure
- Exfiltrer des informations sensibles
Le déclencheur d'exécution correspond au moment où une faille de sécurité se transforme en incident de sécurité. L'agent, incapable de se rendre compte qu'il n'exécute pas des instructions légitimes, utilise les autorisations qui lui ont été accordées pour effectuer des actions qui servent les objectifs de l'attaquant plutôt que ceux de l'organisation.
Amplification multi-agents
Dans les systèmes agentiques distribués, les risques liés à l'injection de commandes se multiplient en raison d'un phénomène qui s'apparente au jeu du téléphone arabe, où la transmission d'un message d'une personne à l'autre, chuchoté à l'oreille, entraîne inévitablement une perte de fidélité, déformant ainsi le contenu d'origine. Lorsque plusieurs agents collaborent pour accomplir des tâches complexes, chacun d'entre eux devient un vecteur potentiel de propagation d'instructions malveillantes.
Comme Simon Willison le décrit dans cette analyse de « la triple menace mortelle » , la combinaison de grands modèles linguistiques, de l’accès à des données privées et de la capacité d’agir sur des systèmes externes crée une dynamique de sécurité particulièrement dangereuse. Lorsque les agents traitent à la fois des entrées de confiance mixte et possèdent une capacité d’exécution, le risque passe d’une sortie incorrecte à une compromission opérationnelle. Dans les flux de travail multi-agents, ce risque s'aggrave à mesure que les instructions transitent d'un système à l'autre. capacité d'exécution, le risque passe d'une sortie incorrecte à une compromission opérationnelle. Dans les flux de travail multi-agents, ce risque s'aggrave à mesure que les instructions transitent d'un système à l'autre.
Imaginons un processus dans lequel l'agent A est chargé d'analyser les tickets d'assistance. Il extrait le contenu du ticket d'une base de données, le traite, puis détermine que l'agent B — spécialisé dans les opérations sur les bases de données — doit se charger de la résolution. L'agent B transmet ensuite les résultats à l'agent C pour une validation finale. Si le ticket d'origine contient des instructions injectées, celles-ci transitent par l'ensemble de la chaîne d'agents.
L'amplification se produit parce que :
- Héritage de la confiance: Chaque agent suivant peut implicitement faire confiance aux données transmises par les agents précédents dans le flux de travail
- Perte de contexte: Lorsque les données circulent entre les agents, les métadonnées indiquant leur origine et leur niveau de fiabilité peuvent être supprimées
- Élévation des privilèges: Les différents agents disposent souvent de niveaux de privilèges différents, ce qui permet aux commandes injectées d'accéder à des ressources inaccessibles au point d'entrée d'origine
- Exécution différée: les instructions malveillantes peuvent rester en sommeil pendant plusieurs sauts avant de se déclencher dans un agent disposant des capacités spécifiques nécessaires à l'exploitation
Cette amplification multi-agents rend l'injection rapide particulièrement insidieuse dans les environnements d'entreprise où des flux de travail complexes impliquent de nombreux agents spécialisés, chacun ayant accès à différents systèmes et sources de données.
Risque d'attaque par rejeu dans les invites signées
Même lorsque les organisations ont recours à la signature cryptographique pour vérifier l'authenticité et l'intégrité des invites, les attaques par rejeu constituent une menace persistante. Si une invite signée est interceptée par un pirate, la signature reste valide indéfiniment, à moins que des contrôles supplémentaires ne soient mis en place.
Le scénario d'attaque par rejeu se déroule comme suit :
- Un utilisateur autorisé signe une instruction demandant à un agent d'effectuer une opération sensible (par exemple, « Enregistrer un certificat pour le système X »)
- La requête signée, accompagnée de sa signature et de sa chaîne de certificats, est transmise à l'agent
- Un pirate intercepte ou se procure d'une autre manière une copie du paquet signé dans son intégralité
- Par la suite, l'attaquant renvoie la même invite signée
- L'agent vérifie la signature, constate à nouveau qu'elle est valide, puis exécute à nouveau la directive
Cela est particulièrement dangereux pour les opérations ponctuelles qui ne doivent en aucun cas être répétées. Contrairement aux tâches récurrentes (telles que la hiérarchisation quotidienne des e-mails), des opérations telles que l'enregistrement de certificats, les modifications de bases de données ou les changements de configuration peuvent causer des dommages considérables si elles sont exécutées à plusieurs reprises.
La stratégie principale d'atténuation consiste à la validation de l'horodatage avec des seuils de fraîcheur. Le service de signature inclut un horodatage fiable dans la charge utile signée, et l'agent de vérification rejette les signatures plus anciennes qu'un seuil configurable adapté au cas d'utilisation. Les organisations doivent ajuster les fenêtres de validité en fonction de leur modèle de déploiement :
- Agents interactifs: délais de validité très courts (de quelques secondes à quelques minutes) lorsque les directives sont signées juste avant l'exécution
- Agents par lots ou planifiés: des fenêtres plus longues lorsque les directives sont signées à l'avance et mises en file d'attente pour une exécution ultérieure
- Opérations à haut risque: des seuils plus stricts pour les actions sensibles susceptibles de causer un préjudice important si elles étaient reproduites
Cette approche garantit que, même si un attaquant parvient à intercepter une invite signée, celle-ci devient inutilisable une fois la fenêtre de validité expirée, ce qui réduit considérablement la surface d'attaque par rejeu.
Pourquoi les mesures de sécurité traditionnelles échouent
Les organisations habituées à se prémunir contre les menaces traditionnelles pesant sur la sécurité des applications constatent souvent que leurs contrôles existants n'offrent pas une protection suffisante contre les attaques par injection de ligne de commande. Cette lacune résulte d'un décalage fondamental entre le mode de fonctionnement de ces contrôles et le mode de fonctionnement des attaques par injection de ligne de commande.
Pare-feu pour applications Web
Les pare-feu d'applications Web (WAF) excellent dans la détection et le blocage des attaques qui suivent des schémas prévisibles : injection SQL, cross-site scripting, traversée de chemin et autres exploits similaires. Ces attaques impliquent généralement des séquences de caractères spécifiques, des structures d'entrée mal formées ou des signatures d'attaque reconnaissables.
L'injection de prompt, en revanche, s'inscrit entièrement dans les limites d'un langage naturel valide. Au niveau syntaxique, la charge malveillante est souvent impossible à distinguer d'une saisie légitime de l'utilisateur — par exemple, un champ d'adresse dans un formulaire Web qui indique « Voir l'enregistrement 1024 », pourrait inciter un agent IA disposant d’un accès privilégié à la base de données à récupérer et à exposer cet enregistrement, même si l’utilisateur n’est pas autorisé à le consulter. Un WAF analysant les requêtes HTTP ne peut pas déterminer si la phrase « ignorer les instructions précédentes » fait partie d’une requête légitime concernant la sécurité de l’IA ou s’il s’agit d’une véritable tentative d’attaque. C’est l’intention sémantique, et non la syntaxe, qui détermine le caractère malveillant.
Systèmes de règles statiques
Les systèmes de filtrage statiques basés sur des règles se heurtent à des limites similaires. Bien qu'il soit possible de créer des règles bloquant des expressions spécifiques telles que « ignorer les instructions précédentes », les pirates peuvent facilement contourner ces règles en :
- Remplacement par un synonyme (« ne pas tenir compte des directives antérieures »)
- Techniques d'obfuscation (substitution de caractères, encodage)
- Variations contextuelles qui produisent le même effet sémantique à travers des formulations différentes
- Injection en plusieurs étapes où l'attaque est répartie sur plusieurs entrées
L'éventail des invites malveillantes possibles est pratiquement infini, ce qui rend impossible un blocage exhaustif basé sur des règles. Chaque nouvelle règle ajoutée pour contrer un vecteur d'attaque spécifique augmente le risque de faux positifs qui bloquent des utilisations légitimes.
Modèles de suggestions
Certaines organisations tentent de limiter les risques liés à l'injection spontanée en imposant aux agents l'utilisation exclusive de modèles prédéfinis. Si cette approche garantit un contrôle déterministe et une application sans ambiguïté, elle sape fondamentalement la valeur ajoutée de l'IA agentique.
Les systèmes basés sur des modèles fonctionnent bien pour les opérations fréquentes et bien comprises, où l'espace des directives est naturellement limité. Cependant, ils deviennent ingérables à grande échelle lorsque :
- Les cas d'utilisation vont au-delà de l'ensemble de modèles initial
- Les nouvelles demandes légitimes sont bloquées par défaut, ce qui entraîne des difficultés opérationnelles
- Les opérations ponctuelles (comme la mise en œuvre d'un élément spécifique du backlog) nécessitent des mises à jour constantes des modèles
- La validation des paramètres dans les modèles nécessite une mise en œuvre rigoureuse afin d'empêcher toute injection via les champs paramétrés
Le registre des modèles devient obsolète et difficile à gérer, ce qui nécessite des mises à jour fréquentes. Le fait de fournir un accès en ligne à la liste des modèles et de valider les invites par rapport à celle-ci introduit également des dépendances externes, une complexité accrue et des délais dans les opérations des agents, ce qui génère davantage de charge opérationnelle que de valeur en matière de sécurité.
CommentKeyfactor prévenir les attaques par injection de code
L'approcheKeyfactorpour prévenir les attaques par injection rapide repose sur la mise en place de limites de confiance cryptographiques qui vérifient à la fois l'authenticité et l'intégrité des directives des agents d'IA avant leur exécution. Cette approche s'inspire du modèle de sécurité éprouvé utilisé pour la signature software traditionnelle, mais l'adapte aux défis spécifiques posés par les instructions en langage naturel dans les systèmes d'IA agentique.
Keyfactor permet de lutter contre les attaques par injection grâce à une architecture multicouche :
Infrastructure de signature cryptographique
Keyfactor SignServer fournit des services de signature centralisés qui simplifient la gestion des clés pour les sources émettrices. Les organisations peuvent mettre en place une signature rapide sans distribuer de clés privées aux systèmes ou aux utilisateurs individuels. Au lieu de cela :
- Les sources de directives autorisées font appel à une API de signature
- Les clés privées sont conservées en toute sécurité au sein de l'infrastructure de signature, protégées par des modules hardware (HSM)
- La génération, le stockage, la rotation et la révocation des clés sont gérés de manière centralisée, conformément à la politique de l'organisation
- Plusieurs interfaces d'intégration prennent en charge divers environnements (API REST pour les applications cloud natives, PKCS#11 pour les interfaces cryptographiques standard, Windows KSP pour l'intégration dans l'écosystème Microsoft)
Cette centralisation garantit que les capacités de signature restent soumises à un contrôle d'accès strict tout en préservant la souplesse opérationnelle.
Vérification des signatures dans l'architecture des agents
Pour les organisations qui déploient des agents IA,Keyfactor vérifier les charges de travail des agents avant leur lancement, sans dépendre d'autres systèmes en ligne.
Le processus se déroule comme suit :
- Un signataire autorisé rédige une directive et la signe à l'aide deSignServer, ce qui génère une piste d'audit
- La signature isolée et la chaîne de certificats sont transmises avec la directive de l'agent
- Le plan de contrôle de l'agent vérifie la signature au moment du lancement avant de transmettre la directive à l'agent IA
- Le processus de vérification s'assure que la signature est liée à une autorité de certification de confiance et vérifie la validité de l'horodatage
- Seules les directives ayant passé la validation de signature sont transmises à l'agent IA pour qu'il y donne suite
Si la vérification échoue à n'importe quel stade, l'agent ne reçoit même pas l'invite. Cela crée une barrière de sécurité stricte : aucune directive non vérifiée ne peut parvenir à l'agent IA, quelle que soit la manière dont elle a été introduite dans le système. Cela évite également de gaspiller des jetons LLM pour analyser des entrées non fiables ou altérées, ce qui réduit à la fois les coûts d'exécution inutiles et les risques de sécurité.
Chaînes de confiance des certificats et autorisation
L'infrastructurePKIKeyfactor permet un contrôle granulaire des autorisations grâce à l'identification par certificat. Au lieu de traiter toutes les directives signées de la même manière, les organisations peuvent :
- Délivrer différents certificats de signature en fonction des cas d'utilisation ou des niveaux d'autorisation
- Appliquer les règles de stratégie au moment de la signature grâce au moteur de stratégieSignServer
- Veiller à ce que les responsables habilités ne puissent pas outrepasser leur champ de compétence en matière d'approbation
- Assurer la gestion complète du cycle de vie des certificats d'identité des agents, des certificats de signature instantanée et des certificats d'identité des approbateurs
Cela transfère la gestion des autorisations de l'agent (qui ne peut que vérifier les signatures) vers le service de signature (qui contrôle la délivrance des signatures), ce qui constitue un modèle architectural plus sûr.
Application de l'horodatage et prévention de la relecture
La solutionKeyfactorpermet d'intégrer un horodatage fiable dans le contenu signé, garantissant ainsi la fraîcheur des données. Le service de signature intègre un horodatage dans la charge utile signée, et l'agent de vérification rejette les signatures dont la date est antérieure à un seuil configurable adapté au cas d'utilisation (par exemple, 60 secondes pour les opérations à haut risque, 5 minutes pour les flux de travail standard).
Cette approche fondée sur l'horodatage permet de contrer efficacement les attaques par relecture tout en préservant la souplesse opérationnelle. Les organisations peuvent ajuster les délais de validité en fonction de leurs modèles de déploiement spécifiques et de leur tolérance au risque.
Intégration d'une sécurité multicouche
La signature cryptographiqueKeyfactorconstitue la couche de confiance fondamentale sur laquelle s'appuient les autres contrôles de sécurité. L'architecture prend en charge l'intégration avec :
- Niveaux d'analyse sémantique: des filtres basés sur l'IA qui évaluent le contenu des directives afin de détecter les violations des politiques, en agissant sur du contenu vérifié cryptographiquement
- Flux de travail impliquant une intervention humaine: Processus d'approbation pour les opérations à haut risque, avec preuve cryptographique d'autorisation
- Application des limites d'autorisation: Limites basées sur les rôles concernant les actions que les agents IA peuvent effectuer dans les systèmes d'entreprise
- Gestion du cycle de vie et surveillance: Pistes d'audit complètes des directives signées, de l'état des certificats et des activités des agents
Cette approche multicouche tient compte du fait que la signature cryptographique permet de vérifier l'identité de la source et l'intégrité du contenu, mais pas la sécurité sémantique ni la conformité aux politiques. En combinant plusieurs contrôles complémentaires, les organisations mettent en place une défense en profondeur contre l'injection de commandes et les menaces associées.
Exemple d'architecture technique
La mise en œuvre pratique de la signature cryptographique instantanée pour les agents IA montre comment des principes de sécurité abstraits se traduisent en conceptions de systèmes concrètes. Prenons l'exemple d'une architecture de référence pour les charges de travail des agents — par exemple, les déploiements en conteneurs couramment utilisés dans les systèmes d'IA agentique natifs du cloud qui exécutent des tâches distinctes.
Le processus de sécurité démarre lorsqu'un utilisateur ou un système autorisé doit transmettre une instruction à un agent IA. Les agents n'agissant pas sur du contenu non signé, cette partie autorisante doit obtenir une signature numérique avant de transmettre la commande à l'agent. Elle doit d'abord faire appel à l'API de signatureSignServer. SignServer une signature cryptographique à l'aide d'une clé privée qui ne quitte jamais l'infrastructure de signature sécurisée, garantissant ainsi que vos clés de signature les plus sensibles restent sous le contrôle le plus strict. La signature, ainsi que le certificat de signature et sa chaîne vers l'autorité de certification racine de confiance, sont joints à la commande d'origine.
Cet ensemble, qui comprend la directive, la signature et la chaîne de certificats, est vérifié avant le lancement du conteneur dans le cadre du processus d'attestation d'identité de l'agent et peut faire l'objet d'une nouvelle vérification à l'intérieur du conteneur lors de l'exécution. Avant que le conteneur ne transmette la directive à l'agent IA lui-même, un processus de vérification est exécuté. Cette vérification porte sur trois propriétés essentielles :
Validité de la signature: La signature cryptographique doit correspondre correctement au contenu de la directive, prouvant ainsi que celle-ci n'a pas été modifiée depuis la signature.
Fiabilité du certificat: Le certificat de signature doit être lié à une autorité de certification de confiance contrôlée par l'organisation, prouvant ainsi que la directive provient d'une source autorisée.
Actualité de l'horodatage: L'horodatage de la signature doit se situer dans une plage de validité acceptable, prouvant qu'il ne s'agit pas d'une rediffusion d'une ancienne directive.
Ce n'est que lorsque ces trois vérifications sont réussies que le conteneur autorise la directive à parvenir à l'agent IA. Si l'une d'entre elles échoue, le conteneur s'arrête sans s'exécuter, et l'échec est consigné dans le journal à des fins de surveillance de la sécurité.
Cette architecture s'inspire des modèles software sécurisée software , tels que le Contrôle des comptes d'utilisateurs (UAC) de Windows, mais applique les mêmes principes aux directives d'IA. Tout comme l'UAC demande « Faites-vous confiance à ce programme ? » avant d'autoriser software avec des privilèges élevés, la vérification du conteneur demande « Faites-vous confiance à cette directive ? » avant de permettre à l'agent d'IA d'agir en conséquence.
Les garanties de sécurité offertes par cette architecture sont considérables :
- Authenticité: L'agent n'exécute l'opération que si la directive porte une signature valide provenant d'une chaîne de certificats reliée à l'autorité de certification de confiance
- Intégrité: toute modification apportée à la directive après la signature — qu'elle provienne d'une couche d'orchestration compromise, d'un registre de conteneurs ou d'un montage de volume — entraîne un échec de la vérification de la signature
- Autorisation à la source: Le moteur de règles du service de signature détermine quelles parties sont autorisées à émettre des directives, empêchant ainsi tant les sources non autorisées que les sources autorisées de dépasser leur champ d'application
- Prévention de la relecture: la validation de l'horodatage rejette les directives signées en dehors de la fenêtre de validité acceptable, empêchant ainsi la relecture des directives signées capturées
- Exhaustivité de l'audit: Les directives signées comportant des signatures valides peuvent être enregistrées puis vérifiées ultérieurement, fournissant ainsi une preuve non répudiable des instructions qui ont été autorisées et exécutées
Cette approche établit une chaîne de confiance vérifiable, depuis l'origine de la directive jusqu'à son exécution par l'agent, et remédie ainsi à la vulnérabilité fondamentale exploitée par les attaques par injection de commandes : l'incapacité à distinguer les instructions fiables des données non fiables.
Foire aux questions sur l'injection rapide
L'invite de commande peut-elle exécuter des commandes système ?
Oui, dans les systèmes basés sur des agents disposant d'un accès aux API et aux outils. Si un agent IA est capable d'interagir avec les systèmes, les bases de données ou l'infrastructure de l'entreprise, une injection de prompt réussie peut l'amener à exploiter ces capacités de manière non souhaitée. L'impact dépend entièrement des autorisations dont dispose l'agent.
Cela diffère des chatbots traditionnels, qui ne font que générer du texte. Les systèmes agentiques, quant à eux, effectuent des actions concrètes.
L'injection rapide correspond-elle aux attaques de type « jailbreak » ?
Non. Les attaques de type « jailbreak » contournent les mesures de sécurité d'un modèle pour générer du contenu interdit.
Les attaques par injection de commande manipulent les instructions afin qu'un agent IA effectue des actions non autorisées dans les systèmes connectés.
Il est important de noter qu’un système n’a pas besoin d’être jailbreaké pour être vulnérable. Même les modèles fonctionnant conformément à leur conception peuvent exécuter des instructions injectées lorsque des données fiables et non fiables sont combinées. Les jailbreaks visent les contrôles de contenu. L’injection de messages vise la logique d’exécution.
La signature élimine-t-elle tous les risques liés à l'IA ?
Non, et la signature de code traditionnelle non plus.
La signature de code ne garantit pas software ; elle garantit son authenticité et l'absence de modification. La signature immédiate offre la même valeur ajoutée pour les directives d'IA.
La sécurité parfaite n'existe pas. La question est de savoir si le risque est réduit de manière significative. La signature immédiate empêche l'exécution de directives non autorisées ou altérées, ce qui complique considérablement la tâche des pirates — en particulier lorsqu'elle est associée à une protection solide des clés et à des contrôles d'autorisation rigoureux.
