Qu'est-ce que la sécurité des prompts ? Guide pour sécuriser les directives d'IA 

La sécurité des prompts est, en gros, l'équivalent en IA de la sécurité des applications pour software traditionnels. Alors que la sécurité des applications protège les programmes compilés contre les exploitations, la sécurité des prompts protège les programmes en langage naturel qui régissent le comportement des agents. Sans elle, les organisations ne disposent d'aucun mécanisme fiable pour vérifier si les instructions suivies par un agent sont légitimes. 

Pourquoi les prompts d'IA doivent être sécurisés 

Le secteur de l'IA a franchi un cap décisif. Une instruction n'est plus une simple ligne de dialogue ; c'est une directive visant à accomplir une tâche. Il s'agit d'un programme en langage naturel non déterministe. Ce passaged'une IA conversationnelleàune IA agentiquemodifie fondamentalement les enjeux en matière de sécurité. 

Lorsqu'un chatbot donne une réponse erronée, cela entraîne des désagréments – pour un utilisateur averti. Ce dernier prend connaissance d'informations incorrectes, identifie l'erreur et passe à autre chose. Lorsqu'un agent autonome agit sur la base d'une directive compromise, les conséquences sont matérielles : requêtes non autorisées dans la base de données, transactions financières erronées, erreurs de configuration de l'infrastructure ou exposition de données sensibles. Il ne s'agit pas là de scénarios hypothétiques. Ils représentent la réalité opérationnelle du déploiement d'agents IA sans contrôles de sécurité au niveau des directives. 

Les répercussions en aval s'amplifient rapidement. Une seule action non autorisée d'un agent peut entraîner des interruptions de service, des infractions réglementaires, une perte de confiance des consommateurs et l'échec des audits de conformité. Les organisations qui ne prennent pas au sérieux la sécurité en temps réel s'exposent aux mêmes risques que celles qui, par le passé, ont négligé la sécurité des applications web en production. 

Ce nouveau paysage des menaces exige une approche sécuritaire spécifique. La sécurité par prompt fournit les cadres, les contrôles et les modèles architecturaux nécessaires pour garantir que les agents IA opèrent dans les limites autorisées. Pour mieux comprendre comment les attaquants exploitent les limites des directives, découvrez comment les vulnérabilités liées à l'injection de prompts compromettent le comportement des agents. 

Le problème de l'autorisation des directives 

Avant qu'un agent IA n'exécute une instruction, il faut répondre à cinq questions. Si l'une d'entre elles reste sans réponse, cela crée une faille susceptible d'être exploitée. 

1. Authenticité 

Qui a émis cette directive ?
Un agent doit être en mesure de vérifier qu'une directive provient d'une source connue et fiable. Sans preuve cryptographique de l'identité de l'auteur, un agent ne peut pas faire la distinction entre une directive émanant d'un administrateur autorisé et une directive injectée par un adversaire. 

2. Intégrité 

Cette directive a-t-elle été modifiée ?
Même si une directive était authentique au moment de sa création, elle a pu être altérée en cours de transmission. La vérification de l'intégrité garantit que la directive reçue par un agent est identique à celle qui a été émise. Toute modification, qu'il s'agisse d'un simple mot ou d'une instruction ajoutée, doit pouvoir être détectée. 

3. Autorisation 

L'émetteur est-il autorisé à demander cette action ?
L'authentification confirme l'identité ; l'autorisation confirme le champ d'action. Un utilisateur vérifié peut être authentifié pour interagir avec un agent, mais ne pas être autorisé à lui demander d'accéder à des données financières, de modifier l'infrastructure ou de contourner les processus de validation. 

4. Rapidité 

Cette directive est-elle toujours valide ?
Une directive valideémise il y a quelques secondes peut désormais présenter un risque, ou peut devenir dangereuse à tout moment si elle est exécutée une deuxième fois. Les attaques par rejeu consistent à renvoyer des instructions auparavant légitimes à des moments non autorisés. Les contrôles de validité temporelle, tels que l'application de l'horodatage et la validation par nonce, garantissent que les directives ne sont exécutées que pendant leur période de validité prévue. 

5. Sécurité sémantique 

Le contenu de cette directive respecte-t-il les limites comportementales attendues ?
Même une directive authentique, non modifiée, autorisée et émise en temps opportun peut contenir des instructions qui enfreignent la politique de l'organisation. L'analyse sémantique évalue l'intention et la portée d'une directive par rapport à des contraintes comportementales définies. 

Aucun mécanisme ne permet à lui seul de répondre à ces cinq questions. Pour garantir une sécurité efficace et immédiate, il est nécessaire de mettre en place plusieurs niveaux de contrôles complémentaires, de sorte que chaque question soit traitée par au moins un point de contrôle. La signature cryptographique garantit l'authenticité et l'intégrité. Les politiques de contrôle d'accès régissent l'autorisation. L'application de l'horodatage garantit la validité temporelle. L'analyse sémantique définit les limites comportementales. L'architecture doit combiner tous ces éléments. 

L'importance d'une sécurité rapide 

Le classement OWASP Top 10 des applications agentiques (2026) placele détournement des objectifs de l'agent,quiest directement lié à la sécurité des invites, en tête des risques. Le détournement des objectifs se produit lorsqu'un attaquant manipule les directives d'un agent afin de passer outre ses objectifs initialement prévus, transformant ainsi l'agent en un outil permettant d'effectuer des actions non autorisées. 

Il ne s'agit pas d'un risque isolé. Plusieurs éléments du classement « Agentic Top 10 » de l'OWASP sont directement liés à la discipline de sécurité des invites de commande : 

• ASI01, Détournement des objectifs de l'agent :
  Le principal risque lié aux invites. Les attaquants manipulent le comportement de l'agent à l'aide de directives compromises, modifiant ainsi ses objectifs et ses plans, et influençant sa prise de décision. 

• ASI02, Utilisation abusive des outils :
  Les agents utilisent des outils en dehors de leur champ d'application prévu, car les limites des directives n'ont pas été respectées. 

• ASI05 : Code inattendu ASI05, exécution (RCE) :
  Une faille de sécurité mineure peut dégénérer en exécution de code lorsque du code généré ou déclenché par des agents est exécuté sans validation suffisante. 

• ASI06, Contamination de la mémoire et du contexte :
  Les attaquants corrompent le contexte à long terme sur lequel s'appuient les futures invites, ce qui entraîne une influence persistante sur le raisonnement, la planification et l'utilisation des outils d'une session à l'autre. 

• ASI08, Défaillances en cascade :
  Une attaque par invite réussie contre un agent peut se propager aux agents, outils, flux de travail, etc. qui en dépendent, transformant ainsi une vulnérabilité localisée liée à une invite en une défaillance à l'échelle du système. 

Chacun de ces risques trouve son origine dans une défaillance au niveau de l'autorisation des directives. Lorsque les organisations ne sont pas en mesure de vérifier qui a émis une instruction, si celle-ci a été modifiée ou si son émetteur était habilité à formuler cette demande, les agents deviennent des points de vulnérabilité. 

Il est essentiel que les équipes de sécurité comprennentcomment les attaques par injection de ligne de commande exploitent ces faillesafin d'évaluer leur vulnérabilité. Il est tout aussi important de mettre en œuvredes contre-mesures concrètes contre l'injection de ligne de commandequi traitent ces risques au niveau architectural. 

Sécurité instantanée vs sécurité traditionnelle des applications 

Le parallèle entre la sécurité des invites et la sécurité des applications traditionnelles est évident. Alors que les applications traditionnelles sont des programmes déterministes écrits dans des langages tels que Java ou C++, à l'ère de l'IA agentique, une invite d'agent est un programme non déterministe rédigé en langage naturel. Les mêmes principes de sécurité s'appliquent ; ce sont les mécanismes de mise en œuvre qui doivent s'adapter. 

Les professionnels de la sécurité connaissent déjà les domaines qui nécessitent une protection. Prompt établit des cartes de sécurité pour chacun d'entre eux. 

Surfaces d'attaque 

Les applications traditionnelles protègent contre les injections SQL, les attaques de type « cross-site scripting » et les débordements de tampon. Les agents IA sont quant à eux exposés aux injections de prompt, à la manipulation du contexte et aux violations des limites des directives. Dans les deux cas, le problème fondamental réside dans le fait que des données non fiables parviennent au moteur d'exécution sans avoir été soumises à une validation adéquate. 

Identité et accès 

L'authentification, l'autorisation, la gestion des sessions et l'escalade des privilèges constituent les fondements de ces deux disciplines. Un agent d'IA incapable de vérifier l'identité de l'émetteur d'une directive équivaut à une application web qui accepte des requêtes non authentifiées. 

Protection des données 

La validation des entrées et des sorties, l'accès non autorisé aux données et la gestion des informations confidentielles s'appliquent tout autant aux agents traitant des instructions en langage naturel. Un agent qui divulgue des invites système ou des configurations d'outils internes s'expose au même type de risque de fuite de données qu'une application qui divulgue des identifiants de base de données. 

Chaîne d'approvisionnement 

La confiance dans les dépendances, l'intégrité des plugins tiers et la vérification des sources sont essentielles dans ces deux domaines. Un agent qui charge des outils ou des directives provenant de sources non vérifiées hérite de toutes les vulnérabilités que ces sources comportent. 

Détection et traçabilité 

La détection des anomalies, la journalisation, les pistes d'audit, la transparence et les tests constituent la couche de détection tant dans la sécurité traditionnelle que dans celle basée sur l'IA. Sans une journalisation exhaustive des directives reçues, des actions entreprises et des résultats obtenus, il est impossible de mener une enquête sur les incidents. 

Opérations 

La gestion des incidents, le contrôle de l'étendue des répercussions et les capacités d'intervention humaine constituent des exigences opérationnelles, que le système à protéger soit un microservice en conteneur ou un agent autonome. 

Ce qui complique la sécurisation des invites, c'est la nature même des données d'entrée. La validation traditionnelle des données d'entrée repose sur la correspondance déterministe de modèles : pare-feu d'application Web (WAF), expressions régulières et validation de schémas. Le langage naturel est intrinsèquement ambigu. Une même instruction peut être exprimée de multiples façons, et les invites malveillantes sont spécialement conçues pour contourner les filtres syntaxiques. Cette ambiguïté signifie que les contrôles au niveau du périmètre ne suffisent pas à eux seuls. La sécurité des invites nécessite des architectures de défense en profondeur combinant des contrôles cryptographiques, basés sur des politiques et sémantiques. 

Le modèle de sécurité en couches pour les invites d'IA 

Une sécurité efficace et réactive ne se résume pas à un seul produit ou à une seule technique. Il s'agit d'un modèle architectural composé de cinq couches distinctes, qui se renforcent mutuellement. 

Couche 1 : Base de confiance cryptographique 

La couche de base assure la vérification des signatures et l'application de l'horodatage. Chaque directive est signée cryptographiquement par son émetteur et vérifiée par l'agent destinataire avant son exécution. L'application de l'horodatage empêche les attaques par rejeu en liant chaque directive à une fenêtre de validité spécifique. 

Cette couche n'est pas une option parmi d'autres. C'est le fondement qui garantit la fiabilité de toutes les couches supérieures. Considérez la différence : l'analyse sémantique d'une directive non signée fournit des conclusions sur un contenu dont la provenance est inconnue. L'analyse peut être exacte, mais l'organisation n'a aucun élément lui permettant de se fier à l'origine de la directive. L'analyse sémantique d'une directive signée permet d'interpréter ses conclusions en toute confiance, car la paternité et l'intégrité de la directive sont déjà établies. 

Niveau 2 : Application du périmètre d'autorisation 

Une fois la confiance cryptographique établie, la couche d'autorisation applique des restrictions basées sur les rôles concernant les actions qu'un émetteur vérifié peut demander à un agent d'effectuer. Une directive signée par un utilisateur authentifié doit tout de même faire l'objet de contrôles d'autorisation. Un ingénieur peut être autorisé à demander à un agent de consulter des tableaux de bord de surveillance, mais pas de modifier l'infrastructure de production. 

Niveau 3 : Analyse sémantique 

Des filtres basés sur l'IA analysent le contenu et l'intention des directives vérifiées et autorisées. Ce niveau de contrôle détecte les schémas anormaux, les violations des politiques et les écarts de comportement que les contrôles cryptographiques et d'autorisation ne peuvent pas repérer. Par exemple, une directive authentique, non modifiée et s'inscrivant dans le champ d'autorisation de son émetteur, mais qui demande un volume inhabituel de transferts de données à une heure inhabituelle, peut justifier un examen plus approfondi. 

Niveau 4 : Contrôle humain 

Les opérations à haut risque nécessitent des processus d'approbation humaine. Ce niveau définit des seuils en fonction de la gravité de l'action, de la sensibilité des données ou de l'impact financier. Lorsqu'une directive dépasse les paramètres de risque définis, son exécution est suspendue jusqu'à ce qu'un responsable l'approuve explicitement. 

Couche 5 : Gestion du cycle de vie et surveillance 

La couche supérieure répond aux besoins opérationnels permanents en matière de sécurité immédiate : gestion du cycle de vie des certificats, rotation des clés de signature, vérification des révocations, mises à jour de la confiance des autorités de certification et surveillance continue. La sécurité ne se résume pas à un déploiement ponctuel. Les identités cryptographiques et les relations de confiance qui sous-tendent l'ensemble du modèle nécessitent une gestion active tout au long de leur cycle de vie. 

Pour plus de détails sur la mise en place d'unedéfense multicouche contre l'injection de commandes, consultez le guide de mise en œuvre. 

Sécurité des requêtes dans les systèmes multi-agents 

Les architectures multi-agents soulèvent une catégorie distincte de défis en matière de sécurité des invites. Dans ces systèmes, il arrive qu’un agent reçoive une invite, mais que ce soit un autre agent qui, en fin de compte, exécute les instructions qui en découlent. À mesure que les directives transitent d’un agent à l’autre, le contexte permettant de distinguer les instructions système fiables des données non fiables soumises par l’utilisateur peut se perdre. C’est ce qu’on appelle le problème du « jeu du téléphone » dans le domaine de l’IA agentique. 

Lorsque l'agent A reçoit une directive signée et délègue des sous-tâches aux agents B et C, ces derniers doivent vérifier de manière indépendante la provenance de la directive. Si, lors de la communication entre agents, les signatures cryptographiques sont supprimées ou ne sont pas transmises, les agents en aval agissent sur la base d'instructions d'origine inconnue. 

La sécurisation des architectures multi-agents nécessite un ensemble complet de mesures de contrôle : 

• Identités uniques pour chaque agent.
  Chaque agent du système doit disposer de sa propre identité cryptographique, généralement étayée par un certificat numérique. Cela permet l'authentification mutuelle et la traçabilité de chaque agent. 

• Authentification mutuelle entre agents.
  Avant qu'un agent n'accepte une directive provenant d'un autre agent, les deux parties doivent vérifier l'identité de l'autre. La confiance ne peut être présumée sur la base de la position sur le réseau ou du contexte de déploiement. 

• Délégation explicite des autorisations.
  Lorsqu'un agent A délègue une tâche à un agent B, les autorisations accordées doivent être explicitement délimitées. L'agent B ne doit en aucun cas hériter implicitement de l'ensemble des privilèges de l'agent A. 

• Principe du privilège minimal par agent et par tâche.
  Chaque agent fonctionne avec le minimum d'autorisations nécessaires à sa fonction spécifique. Les autorisations ne s'appliquent pas seulement à l'agent, mais aussi à la tâche individuelle en cours d'exécution. 

• Validation de toutes les communications entre agents.
  Les directives transmises entre agents doivent être validées à chaque interface. La concaténation d'entrées non fiables (qu'elles soient générées par un utilisateur ou par un autre agent) avec des instructions système au-delà des interfaces entre agents peut avoir des conséquences désastreuses en aval. 

• Journalisation par agent et pistes d'audit traçables.
  Chaque directive reçue, chaque action effectuée et chaque résultat produit par chaque agent sont consignés de manière indépendante. Les pistes d'audit doivent permettre de retracer l'intégralité de la chaîne de directives, depuis leur origine jusqu'à leur exécution finale. 

• Confinement de la zone d'impact.
  Les contrôles architecturaux limitent l'impact d'un agent compromis. Si l'agent C est piraté, les dommages qu'il peut causer sont limités par ses autorisations, les outils auxquels il a accès et sa portée réseau. 

• Détection des anomalies et boutons d'arrêt d'urgence.
  La surveillance automatisée détecte les écarts de comportement en temps réel. Les boutons d'arrêt d'urgence permettent aux opérateurs d'arrêter des agents individuels ou des chaînes d'agents entières sans attendre la fin de l'exécution en cours. 

Nouvelles normes et sécurité immédiate 

La communauté de la sécurité est en train de formaliser la sécurité des agents IA et des invites dans le cadre des travaux de normalisation menés au sein de l'IETF.  

À titre d'exemple, un projet portant surl'authentification et l'autorisation des agents IA(draft-klrc-aiagent-auth) vise à définir un modèle décrivant comment les agents IA sont identifiés, authentifiés et autorisés lorsqu'ils interagissent avec des systèmes et des services. Ce projet décrit les agents comme des charges de travail nécessitant une gestion structurée des identités, comprenant des identifiants, des informations d'identification et des mécanismes d'attestation. Il considère les invites comme faisant partie intégrante des interactions authentifiées et autorisées plutôt que comme des entrées autonomes. Il définit également l'exécution des requêtes des agents comme dépendant d'un contexte d'identité vérifié et d'autorisations déléguées.   

Par ailleurs, un deuxième projet de document surles exigences de sécurité des agents IA(draft-ni-a2a-ai-agent-security-requirements) adopte une vision plus large des systèmes agentiques, en structurant les considérations de sécurité à travers les différentes étapes du cycle de vie de l'interaction avec les agents. Ce projet inscrit les invites dans un cycle de vie d'interaction plus large, au sein duquel les requêtes sont gérées par des composants d'infrastructure tels qu'un agent maître (défini dans le même document). Les entrées de prompt sont donc implicitement soumises à la validation, à l'authentification et à l'application des politiques à plusieurs étapes, y compris lors des communications interdomaines et des décisions de contrôle d'accès. Ces efforts, ainsi que d'autres à venir, visent à fournir des lignes directrices pour des prompts sécurisés et, à terme, pour une utilisation sûre de l'IA. Les organisations qui investissent aujourd'hui dans une infrastructure cryptographique pour la sécurité des prompts seront en mesure d'adopter ces normes à mesure qu'elles mûrissent, plutôt que de devoir mettre en place des contrôles de sécurité a posteriori après le déploiement. 

CommentKeyfactor vous aider 

Keyfactor l'infrastructure cryptographique nécessaire pour mettre en place une sécurité rapide à l'échelle de l'entreprise. Les mêmes principes PKI de signature de code qui protègent les chaînes software , l'identité des appareils et l'authentification des charges de travail s'appliquent directement à la sécurisation des directives des agents d'IA. 

SignServer fournit une infrastructure de signature centralisée pour la signature des directives. Les organisations peuvent signer les directives des agents via des API REST, PKCS#11 ou Windows KSP sans avoir à distribuer de clés privées aux agents individuels ou aux équipes d'application. La gestion des clés est gérée de manière abstraite par un service centralisé, ce qui réduit la complexité opérationnelle liée à la maintenance de l'infrastructure de signature dans le cadre de déploiements d'agents à grande échelle. 

Gestion du cycle de vie des certificats automatise les exigences opérationnelles continues en matière de sécurité : renouvellement des certificats, vérification des révocations et mises à jour de la confiance des autorités de certification. À mesure que le déploiement des agents prend de l'ampleur, la gestion manuelle des certificats devient intenable. La gestion automatisée du cycle de vie garantit que les relations de confiance cryptographiques restent à jour sans nécessiter d'intervention manuelle constante. 

EJBCA fournit une infrastructure d'autorité de certification d'entreprise pour l'émission et la gestion des certificats numériques qui établissent l'identité des agents et les informations d'identification de signature. Chaque agent reçoit une identité unique adossée à un certificat, ce qui permet l'authentification mutuelle et la responsabilité individuelle de chaque agent, deux éléments indispensables aux architectures multi-agents. 

L'application des politiquestransfère les décisions d'autorisation des agents décentralisés vers un service de signature centralisé. Plutôt que de compter sur chaque agent pour appliquer de manière indépendante les politiques d'autorisation, les organisations définissent et appliquent ces politiques au moment de la signature des directives. Seules les directives qui satisfont aux contrôles de conformité reçoivent une signature valide. 

La protection des clés via un module de sécurité matériel (HSM)garantit que les clés de signature sont stockées dans des modules hardware , offrant ainsi un stockage inviolable qui répond aux exigences de conformité des secteurs réglementés. 

Ensemble, ces fonctionnalités font évoluer la sécurité de l'IA du filtrage heuristique vers une assurance cryptographique, garantissant ainsi une sécurité immédiate sur les mêmes fondements éprouvés qui protègent les infrastructures critiques à travers le monde.