Pour prévenir les attaques par injection de prompt, il faut traiter les prompts des agents comme des directives exécutables plutôt que comme de simples entrées de texte. Dans les systèmes d'IA agentique, un prompt n'est plus une simple ligne de dialogue, mais unecommand effectuer une tâche, c'est-à-dire en réalité un programme en langage naturel non déterministe. Tout comme les organisations s'assurent que seules les applications d'entreprise autorisées sont présentes sur leurs systèmes, elles doivent désormais mettre en place des cadres permettant de distinguer les directives approuvées et autorisées de celles qui ne le sont pas, en filtrant les instructions non autorisées avant qu'elles n'atteignent un agent.
Le paysage des menaces liées à l'injection de commandes
Les systèmes d'IA agentique sont exposés à de multiples vecteurs de menace susceptibles d'introduire, de modifier ou de propager des instructions malveillantes.
Des contenus malveillants peuvent être intégrés dans les données traitées par un agent, annulant ou modifiant ainsi les instructions qui lui sont destinées. Ce risque est amplifié dans les systèmes multi-agents, où un effet de « jeu du téléphone » peut se produire : vous pouvez donner une instruction à un agent, mais c'est un autre agent qui finit par exécuter les instructions qui en découlent. À mesure que les directives transitent d'un agent à l'autre, le contexte permettant de distinguer les instructions fiables du système des données non fiables soumises par l'utilisateur peut se perdre.
Les vecteurs de menace les plus courants sont les suivants :
Attaques de type « homme au milieu »: Interception et modification des directives lors de leur transit entre les systèmes d'origine et l'environnement d'exécution de l'agent. En l'absence de contrôles d'intégrité, les directives peuvent être altérées en cours de transmission sans être détectées.
Attaques par rejeu: Renvoi de directives précédemment autorisées afin de déclencher une exécution répétée non autorisée. Une directive signée qui reste valide indéfiniment peut être capturée et rejouée par un attaquant qui se procure les artefacts d'autorisation.
Menaces internes: Utilisateurs autorisés émettant des directives en dehors de leur champ d'action autorisé, exploitant leur accès légitime pour effectuer des actions non autorisées.
Systèmes en amont compromis: Points d'intégration légitimes qui ont été compromis et qui émettent désormais des directives malveillantes sous le couvert de sources autorisées.
Ingénierie sociale: Manipulation d'opérateurs humains visant à les amener à approuver ou à émettre des directives non autorisées, en contournant les contrôles techniques par le biais de la vulnérabilité humaine.
La compréhension du paysage des menaces met en évidence une réalité cruciale : l'injection de prompt n'est pas une faille isolée, mais une rupture des limites de confiance. Pour la prévenir, il faut mettre en place des contrôles applicables concernant l'origine, l'intégrité et l'autorisation des directives avant le début de l'exécution. Les principes suivants constituent un cadre pratique permettant de réduire le risque d'injection de prompt dans les systèmes d'IA agentique.
1. Distinguer les données d'entrée fiables de celles qui ne le sont pas
Le premier principe fondamental pour prévenir les attaques par injection rapide consiste à maintenir une séparation claire entre les instructions système fiables et le contenu non fiable fourni par l'utilisateur. Dans les systèmes agentiques, cette séparation doit être maintenue tout au long de la chaîne de traitement.
Les organisations doivent séparer les instructions système qui définissent le comportement, les capacités et les contraintes fondamentales de l'agent du contenu fourni par l'utilisateur qui représente les données à traiter ou les tâches à effectuer. Cette séparation architecturale empêche que les entrées de l'utilisateur ne soient interprétées comme des commandes au niveau du système.
Étiquetage Le marquage explicite du contenu fourni par l'utilisateur garantit que les systèmes et agents en aval comprennent quelles parties d'une directive proviennent de sources fiables et lesquelles constituent des données potentiellement non fiables. Dans les architectures multi-agents, ce marquage doit persister au-delà des limites des agents afin d'éviter toute perte de contexte.
Il est essentiel d'éviter la concaténation des données brutes. Lorsque les invites du système et les entrées de l'utilisateur sont simplement concaténées en un seul flux de texte, la frontière entre le contenu fiable et non fiable devient floue. Les attaquants peuvent créer des entrées qui exploitent cette ambiguïté, en injectant des instructions que l'agent interprète comme des directives système légitimes.
2. Mettre en place la signature cryptographique à la demande
Si de nombreuses organisations envisagent au départ la sécurité des invites comme nécessitant des invites figurant sur une liste blanche ou des modèles de directives préapprouvés, cette approche s'avère fondamentalement rigide à grande échelle. À mesure que les cas d'utilisation se multiplient, les registres de modèles deviennent ingérables. Les nouvelles demandes légitimes sont bloquées par défaut, ce qui engendre des frictions opérationnelles. Cela pose un problème particulier pour les invites qui ne sont exécutées qu'une seule fois, comme la mise en œuvre d'un élément spécifique du backlog, où la charge liée à la gestion de la liste blanche l'emporte sur les avantages en matière de sécurité.
La signature cryptographique offre une alternative plus évolutive et plus fiable. Au lieu de tenir à jour des registres de modèles de messages approuvés, les organisations signent les directives autorisées à l'aide de clés cryptographiques, en recourant à des solutions de signature d'entreprise. La signature et le certificat associé sont joints à la directive et vérifiés avant son exécution.
Cette approche reprend le modèle bien établi utilisé pour la signature software traditionnelle. Tout comme les organisations signent les exécutables compilés pour s'assurer que seuls software autorisés software dans leurs environnements, elles peuvent signer les directives d'agent pour garantir que seules les instructions autorisées sont exécutées. Le principe fondamental reste identique ; la seule différence réside dans le fait que les applications traditionnelles sont des programmes déterministes écrits dans des langages tels que Java ou C#, tandis que les invites d'agent sont des programmes non déterministes rédigés en langage naturel. Lorsqu'il s'agit de s'assurer que vos systèmes n'effectuent pas d'activités non autorisées, cette distinction au niveau du format source d'origine n'a aucune importance.
Le processus de signature et de vérification
Le processus de signature cryptographique par invite comporte plusieurs étapes clés :
- Création d'une directive: Une partie autorisée crée une directive de prompt qui donnera des instructions à l'agent
- Signature: La partie autorisée signe à l'aide d'un service de signature d'entreprise tel queSignServer, qui génère une signature cryptographique
- Regroupement de certificats: La chaîne de certificats est extraite et regroupée avec la directive et la signature
- Distribution: Ces trois éléments, la invite, la signature et la chaîne de certificats, sont distribués ensemble à l'environnement d'exécution de l'agent
- Vérification: Avant de transmettre la directive à l'agent IA, la signature est vérifiée par rapport au certificat, ce qui permet de confirmer à la fois son authenticité et son intégrité
Cette vérification peut avoir lieu au moment du lancement du conteneur de l'agent, avant même que la directive n'atteigne l'agent IA lui-même. Toute modification apportée à la directive signée, qu'elle soit le fait d'un intermédiaire compromis, d'une charge utile injectée via une invite ou d'une erreur de transmission, invalide la signature et empêche l'exécution.
Pourquoi la signature cryptographique est-elle nécessaire ?
Parmi les différentes approches existantes en matière d'autorisation par directive, la signature cryptographique offre des propriétés uniques qui ne peuvent être obtenues par d'autres moyens :
Authenticité non répudiable: Une signature valide constitue la preuve mathématique que la directive a été émise par une entité contrôlant la clé privée correspondante. Aucun autre mécanisme n'offre une garantie équivalente. La liste blanche confirme qu'une directive correspond à un modèle approuvé, mais ne peut prouver son origine. Les codes d'autorisation prouvent qu'un jeton a été émis, mais celui-ci peut être volé ou détourné. Les gardiens de l'IA émettent des jugements probabilistes qui ne peuvent être vérifiés de manière indépendante.
Sécurité anti-altération: toute modification apportée à une directive signée invalide la signature. Cette propriété est préservée quel que soit le nombre de systèmes traversés par la directive entre la signature et la vérification. Qu'elle soit modifiée par une couche d'orchestration compromise, un registre de conteneurs ou un montage de volume, toute altération est immédiatement détectable.
Vérification découplée: La vérification de signature ne nécessite que la clé publique et peut être effectuée entièrement au sein de la zone de confiance de l'agent. Contrairement à la validation de jeton, elle ne nécessite pas d'appel en temps réel à un service externe, ce qui évite les dépendances en matière de disponibilité. Sa nature locale et déterministe permet une vérification idempotente (c'est-à-dire répétée) sur plusieurs agents, une propriété essentielle dans les systèmes multi-agents.
Exhaustivité de l'audit: Les directives signées peuvent être enregistrées avec leurs signatures, ce qui permet de vérifier a posteriori que les directives enregistrées sont authentiques et n'ont pas été modifiées. Cela facilite la conformité, les analyses judiciaires et le règlement des litiges d'une manière que d'autres mécanismes ne permettent pas.
Maîtrise totale de la chaîne de confiance: En désignant la racine d'entreprise de confiance propre à l'organisation comme seule infrastructure PKI laquelle la signature immédiate peut être autorisée, les équipes chargées de la sécurité de l'information conservent un contrôle total sur les relations de confiance et le contrôle d'accès à l'infrastructure de signature.
3. Appliquer la validation de l'horodatage
Si la signature cryptographique offre des garanties solides en matière d'authenticité et d'intégrité, les directives signées ne faisant l'objet d'aucun contrôle supplémentaire restent valides indéfiniment. Cela crée une vulnérabilité aux attaques par rejeu : si un attaquant parvient à se procurer tous les éléments nécessaires pour vérifier qu'une directive est autorisée, il peut la soumettre à plusieurs reprises, et la vérification de la signature continuera de s'avérer positive.
La validation par horodatage atténue cette vulnérabilité aux attaques par rejeu en garantissant la fraîcheur des directives. Le service de signature inclut un horodatage fiable dans la charge utile signée. L'agent de vérification rejette alors les signatures dont la date est antérieure à un seuil configurable adapté au cas d'utilisation.
L'âge maximal autorisé pour les signatures dépend du modèle de déploiement :
- Agents interactifs: Des fenêtres de validité très courtes (de quelques secondes à quelques minutes) sont appropriées lorsque les directives sont signées immédiatement avant l'exécution
- Agents par lots ou planifiés: des fenêtres plus longues peuvent être nécessaires si les directives sont signées à l'avance et mises en file d'attente pour une exécution ultérieure
- Scénarios de reprise après sinistre: Les organisations doivent déterminer si les directives signées doivent rester valides en cas d'interruption du service de signature et définir des fenêtres de temps en conséquence
Pour les directives qui ne sont pas censées être exécutées de manière répétée, comme l'enregistrement d'un certificat ou la mise en œuvre d'une tâche spécifique en attente, l'application d'une date et d'une heure de référence est essentielle. Étant donné que les agents sont généralement censés traiter les tâches très rapidement, des délais de validité courts s'avèrent pratiques et efficaces.
4. Appliquer l'autorisation basée sur un certificat
L'infrastructure à clé publique (PKI) ne se limite pas à la vérification cryptographique ; elle établit un cadre complet garantissant l'identité, l'intégrité et la traçabilité dans les systèmes d'IA agentique.
Définition de l'identité
Les certificats associés à des clés de signature permettent de vérifier l'identité des émetteurs de directives. Contrairement aux simples identifiants d'authentification, qui peuvent être partagés ou volés, les clés privées protégées par l'infrastructure de signature de l'entreprise offrent une garantie d'identité solide. La chaîne de certificats permet de vérifier que le certificat de signature a bien été émis par une autorité de certification de confiance placée sous le contrôle de l'organisation.
Garantir l'intégrité
Le lien cryptographique entre le contenu de la directive et la signature garantit que toute altération, aussi subtile soit-elle, est détectable, une garantie qui dépend de la robustesse de l'algorithme sous-jacent. Et pour se protéger contre un adversaire doté de capacités quantiques, il faut recourir à la cryptographie post-quantique. Cette protection de l'intégrité va au-delà de la simple détection des altérations pour inclure les erreurs de transmission, la corruption des données stockées et toute autre modification involontaire.
Garantir la traçabilité
Les solutions de signature d'entreprise basées sur des certificats génèrent des pistes d'audit complètes. Chaque opération de signature peut être consignée avec toutes les informations nécessaires : qui a signé quelle directive, quand la signature a été effectuée et quel certificat a été utilisé. Ces journaux fournissent des preuves non réfutables utiles pour la conformité, les analyses judiciaires et le règlement des litiges.
Les organisations doivent prévoir la gestion de l'expiration des certificats, la vérification des révocations et les mises à jour de la confiance accordée aux autorités de certification. Pour les charges de travail conteneurisées, cela peut nécessiter un accès réseau aux points de distribution des listes CRL ou aux serveurs OCSP, ou encore l'intégration des informations de révocation dans le paquet d'exécution.
Contrôle granulaire des autorisations
Les services de signature tenant compte des politiques peuvent appliquer des règles d'autorisation au moment de la signature. Différents certificats de signature peuvent être utilisés pour distinguer les cas d'utilisation, ce qui permet à chaque agent d'accéder aux systèmes appropriés tout en garantissant qu'un approbateur autorisé ne puisse pas outrepasser son champ de compétence.
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 changement d'architecture est souhaitable car il centralise l'application des politiques en un seul point bien contrôlé, plutôt que de la répartir entre de nombreux déploiements d'agents potentiels.
5. Le modèle de sécurité en couches
Si la signature cryptographique des instructions destinées à l'IA agentique présente des avantages considérables, elle ne constitue pas à elle seule une solution complète. Prise isolément, elle présente des limites majeures qui doivent être pallies par des mesures de contrôle complémentaires.
Une signature prouve qu'une directive a été émise par une source autorisée ; elle ne prouve pas pour autant que cette directive soit judicieuse, conforme à la politique en vigueur ou sûre. Un signataire autorisé compromis ou malveillant peut émettre des directives préjudiciables qui passeront la vérification de signature. Un agent IA agit en dehors des routines préprogrammées et peut ne pas interpréter une directive conformément aux attentes du signataire.
Ces limites ne constituent pas des arguments contre la signature, mais plaident en faveur d'une sécurité à plusieurs niveaux. La signature cryptographique fournit la couche de confiance fondamentale sur laquelle peuvent s'appuyer l'analyse sémantique, la détection des anomalies et la supervision humaine.
Les architectures recommandées intègrent des contrôles complémentaires :
- Fondement cryptographique de confiance: La vérification des signatures avec application d'horodatage constitue la couche de base
- Application des limites d'autorisation: Limites basées sur les rôles concernant ce qu'un agent IA peut faire dans les systèmes d'entreprise, garantissant qu'un approbateur ne dépasse pas ses compétences
- Couche d'analyse sémantique: Guardian Agent agit en tant que gardien IA pour la détection des anomalies, évaluant les directives par rapport à la politique
- Contrôle humain: Processus de validation impliquant une intervention humaine pour les opérations à haut risque
- Gestion et surveillance du cycle de vie: Gestion complète du cycle de vie des certificats d'identité des agents, des certificats de signature immédiate et des certificats d'identité des approbateurs
Dans ce modèle, la signature cryptographique n'est pas une option parmi d'autres, mais le fondement même qui garantit la fiabilité des couches supérieures. L'analyse sémantique d'une directive non signée aboutit à des conclusions concernant un contenu d'origine inconnue, ce qui rend ces conclusions inapplicables. L'analyse sémantique d'une directive signée permet d'interpréter ses conclusions en toute confiance, sachant que l'authenticité du contenu a été vérifiée par des moyens cryptographiques.
Pour les organisations qui déploient des filtres sémantiques basés sur l'IA en complément de la signature cryptographique, le processus doit suivre le principe « signer puis analyser » : signer les directives à la source, vérifier la signature à l'entrée du filtre, effectuer une analyse sémantique du contenu vérifié, puis seulement ensuite le transmettre à l'agent. Cela garantit que même le filtre ne traite que le contenu dont l'authenticité a été établie, ce qui réduit le risque d'attaques par injection de messages de notification contre le filtre sémantique.
6. Architecture de référence : charges de travail des agents en conteneurs
Les conteneurs constituent un modèle de déploiement idéal pour les systèmes d'IA agentique. La nature éphémère des charges de travail conteneurisées, qui sont lancées pour effectuer une tâche distincte puis s'arrêtent, correspond parfaitement aux meilleures pratiques en matière de déploiement d'agents. Ce modèle, dans lequel les agents se réveillent, accomplissent une tâche spécifique puis disparaissent, permet d'éviter la dégradation qui survient lors de sessions d'agents de longue durée.
Dans une architecture conteneurisée pour la signature instantanée :
- La directive est signée viaSignServer un signataire autorisé, ce qui génère une piste d'audit
- Le plan de contrôle utilise la signature dissociée et la chaîne de certificats pour vérifier la directive avant de monter les artefacts dans le conteneur de l'agent
- Le conteneur d'agent vérifie également la signature au moment du lancement, avant de transmettre la directive à l'agent IA, en vérifiant éventuellement 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
Cette architecture offre plusieurs propriétés essentielles en matière de sécurité :
Authenticité: L'agent n'exécute la directive que si celle-ci porte une signature valide provenant d'une chaîne de certificats liée à l'autorité de certification de confiance.
Intégrité: Toute modification apportée à la directive après la signature entraîne un échec de la vérification de la signature, que cette modification concerne la couche d'orchestration, le registre de conteneurs ou le montage de volume.
Autorisation à la source: Le moteur de règles du service de signature détermine quelles parties sont habilitées à autoriser ou à é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.
Piste d'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.
Le rôleKeyfactordans la prévention des attaques par injection rapide
Keyfactor les modèles PKI et de signature de code d'entreprise aux systèmes d'IA, offrant ainsi aux organisations l'infrastructure nécessaire pour mettre en œuvre la signature cryptographique instantanée à grande échelle. Les mêmes principes qui ont permis de sécuriser software traditionnels software des décennies s'appliquent désormais à la sécurisation des directives des IA agentiques.
SignServer fournit une infrastructure de signature centralisée qui dissocie la complexité de la gestion des clés des sources de directives. Les systèmes qui doivent signer des directives font appel à une API de signature ; ils ne possèdent ni ne gèrent jamais directement les clés privées. La génération, le stockage (y compris le support HSM), la rotation et la révocation des clés sont gérés par le service de signature conformément à la politique de l'organisation.
Cette abstraction est fournie via plusieurs interfaces d'intégration :
- API REST pour les applications cloud natives
- PKCS#11 pour les systèmes nécessitant des interfaces de fournisseurs cryptographiques standard
- KSP Windows pour l'intégration dans l'écosystème Microsoft
Les sources de directives s'intègrent via une seule API ; le service de signature gère en arrière-plan toutes les opérations liées au cycle de vie des clés.
Pour les charges de travail des agents en conteneurs,Keyfactor la vérification des signatures à la fois avant le lancement du conteneur et au sein des conteneurs Kubernetes, avant que les directives n'atteignent l'agent IA. La vérification préalable au lancement garantit qu'aucune ressource de calcul n'est consommée pour traiter une invite non autorisée. La vérification au sein du conteneur offre une protection contre les tentatives de contournement, garantissant que même si une directive parvient d'une manière ou d'une autre à échapper aux contrôles en amont, elle ne peut pas détourner l'agent lors de l'exécution. Étant donné que l'image du conteneur elle-même peut également être signée, les tentatives visant à désactiver ou à contourner la vérification au sein du conteneur échoueront, renforçant ainsi la résistance à la falsification.
Les fonctionnalités de gestion des horodatages garantissent l'actualité des directives et permettent de contrer efficacement les attaques par rejeu. Les entreprises peuvent configurer des délais de validité adaptés en fonction de leurs modèles de déploiement : des délais courts pour les agents interactifs et des délais plus longs pour les opérations par lots.
La protection des clés de niveau entreprise, assurée par un module HSM, garantit la sécurité des clés de signature même en cas de compromission du système. L'application centralisée des politiques offerte parSignServer les décisions d'autorisation des agents distribués vers un point unique et rigoureusement contrôlé, ce qui simplifie la gestion de la sécurité et réduit la surface d'attaque.
Cette approche fait évoluer la sécurité de l'IA du filtrage heuristique, qui tente de détecter les contenus malveillants par la reconnaissance de formes et l'analyse probabiliste, vers l'assurance cryptographique, qui offre des garanties mathématiquement vérifiables quant à l'authenticité et à l'intégrité des directives. Il en résulte un dispositif de sécurité qui s'adapte au déploiement de l'IA agentique de l'organisation sans nécessiter d'examen manuel de chaque directive ni la gestion de registres de listes blanches trop volumineux.
Foire aux questions
Quel est le moyen le plus sûr d'empêcher une injection immédiate ?
Il n'existe pas de mesure unique permettant d'éliminer le risque d'injection de code. L'approche la plus sûre repose sur une défense en profondeur.
La signature cryptographique à la demande constitue la couche de confiance fondamentale, garantissant que les directives sont authentiques et n'ont pas été modifiées avant leur exécution. En outre, les organisations peuvent mettre en place des mesures de sécurité supplémentaires, telles que des restrictions d'autorisation basées sur les rôles et l'isolation des conteneurs.
Une pratique de plus en plus répandue consiste à utiliser un « agent gardien » basé sur l'IA — un système d'IA distinct qui n'a pas accès aux systèmes de l'entreprise et qui évalue une instruction avant son exécution. Concrètement, l'agent chargé de l'exécution pose la question suivante : « Cela ressemble-t-il à une tentative d'injection de prompt?» Ce deuxième agent fait office de « gardien sémantique » et ajoute un examen interprétatif sans accorder de privilèges supplémentaires au système.
La signature instaure la confiance. L'analyse sémantique évalue l'intention. Ensemble, elles constituent un modèle de prévention plus solide.
Les invites de la liste blanche sont-elles évolutives ?
Ne convient pas aux charges de travail dynamiques des agents.
Les approches par liste blanche peuvent convenir à des opérations répétitives et bien délimitées, mais ne s'adaptent pas aux tâches ponctuelles ou très variables. La gestion des registres de modèles devient lourde sur le plan opérationnel et peu fiable par rapport à l'autorisation cryptographique.
Comment la validation des horodatages permet-elle d'empêcher les attaques par rejeu ?
La validation de l'horodatage garantit l'actualité des directives.
Lorsqu'une directive est signée, elle comporte un horodatage fiable. Lors de la vérification, les signatures datant d'avant un seuil défini sont rejetées. Cela empêche les attaquants de réutiliser indéfiniment des directives capturées et garantit que l'autorisation reste limitée dans le temps.
Quel rôle PKI dans la prévention des attaques par injection rapide ?
PKI le fondement de la gestion de l'identité et de l'intégrité.
Les certificats associent les clés de signature à des entités autorisées, les signatures empêchent toute altération, et la chaîne de confiance racine de l'entreprise garantit que seuls les émetteurs approuvés peuvent autoriser l'exécution. Cela permet aux organisations de garder un contrôle total sur les relations de confiance entre les directives dans les environnements d'agents distribués.
