Qu'est-ce qu'une injection de prompt
Une injection de prompt survient quand un texte fourni au modèle est interprété non comme un contenu à traiter, mais comme une instruction à exécuter. La cause tient à la conception même des modèles de langage : instructions et données arrivent sous la même forme, une suite de mots. Rien, dans le flux, ne distingue clairement « voici ce que tu dois faire » de « voici ce que tu dois lire ». Un attaquant insère donc dans un document, une page web ou un message des phrases qui poussent le système à ignorer ses consignes initiales. Cette faille est structurelle et non accidentelle. Elle se révèle dès qu'un agent interagit avec du contenu qu'il ne contrôle pas.
On distingue souvent les injections directes des injections indirectes. Les premières viennent de la personne qui dialogue avec le système, par exemple pour contourner une restriction. Les secondes, plus préoccupantes, sont dissimulées dans un contenu tiers que l'agent va consulter sans méfiance. Une simple page consultée peut ainsi porter une instruction cachée. L'injection indirecte est redoutable parce qu'elle ne suppose aucune action hostile de l'utilisateur lui-même : l'agent est piégé par ce qu'il lit. Dans les deux cas, le problème se situe dans l'articulation entre le texte reçu et la confiance accordée à ce texte, ce qui rend sa correction difficile.
Pourquoi les agents sont plus exposés que les chatbots
Un chatbot qui se contente de répondre reste relativement contenu : le pire effet d'une injection est souvent un texte trompeur. Un agent, lui, dispose de capacités d'action. Il peut envoyer un courriel, modifier une fiche, appeler un service externe. Une injection réussie ne se limite donc plus à fausser une réponse : elle peut déclencher des opérations réelles, au nom de l'utilisateur. Plus l'agent a de droits, plus la faille pèse. C'est pourquoi le nombre et la portée des permissions accordées conditionnent directement l'ampleur du risque. Un agent puissant mal protégé devient une surface d'attaque là où un simple générateur de texte restait inerte.
L'exposition augmente avec l'autonomie. Un agent qui agit sans confirmation humaine, qui enchaîne plusieurs étapes ou qui traite une grande quantité de documents laisse plus d'occasions à une instruction malveillante. La multiplicité des sources qu'il consulte élargit encore la surface. Ce n'est pas un défaut de vigilance de l'utilisateur : l'attaque est conçue pour passer inaperçue au milieu d'un contenu légitime. Le fait que l'agent ait accès à des données sensibles ou à des outils internes aggrave chaque cas. La question n'est donc pas seulement de savoir si l'agent comprend bien une demande, mais ce qu'il est capable de faire quand il la comprend de travers.
Les scénarios d'attaque à connaître
Plusieurs scénarios reviennent. Le détournement d'instructions pousse l'agent à abandonner sa mission initiale pour suivre l'ordre caché. L'exfiltration consiste à lui faire divulguer des informations confidentielles qu'il a en mémoire ou sous les yeux. L'usurpation d'action l'amène à exécuter une opération que l'utilisateur n'a pas demandée, comme transmettre un fichier à une adresse inconnue. Un scénario plus discret vise l'empoisonnement : introduire dans un corpus des éléments faux que l'agent reprendra plus tard comme des faits. Ces schémas ne dépendent pas d'une faille logicielle précise, mais du rapport de confiance que le système entretient avec les contenus qu'il traite.
Ce qui rend ces attaques crédibles, c'est leur discrétion. Une instruction introduite dans un document anodin, une page web sans intérêt apparent, ou un commentaire dissimulé n'attire l'attention ni de l'utilisateur ni du modèle. Rien n'indique, à la lecture, qu'un contenu porte une intention hostile. Il est donc difficile de s'en protéger en comptant sur la vigilance humaine seule. Les équipes qui exploitent des agents doivent raisonner en scénarios : que se passe-t-il si tel contenu est manipulé, quels droits l'agent détient-il, quelles traces conserve-t-il de ses actions. Cette démarche, proche de l'analyse de risque, prépare mieux qu'une liste de règles appliquées sans discernement.
Défenses : réduire le risque sans l'éliminer
Aucune parade ne supprime complètement l'injection de prompt. On peut en revanche en réduire la portée. La première mesure est de limiter les droits de l'agent au strict nécessaire : ce qui n'est pas indispensable au service rendu ne doit pas être accessible. La seconde consiste à exiger une confirmation humaine avant toute action sensible ou irréversible. La troisième est de cloisonner les sources, en séparant les instructions du système des contenus traités quand l'architecture le permet. Ces principes relèvent moins d'une astuce que d'une hygiène de conception. Ils limitent les dégâts d'une attaque réussie davantage qu'ils ne l'empêchent.
La surveillance complète ce dispositif. Journaliser les actions de l'agent, alerter sur les comportements inhabituels, repérer les flux sortants non prévus : ces mécanismes détectent ce que la prévention a laissé passer. Il est également prudent de rester modeste sur les détournements annoncés par certains outils de filtrage, dont l'efficacité est partielle. Adopter une posture de défense en profondeur, où plusieurs protections se complètent, vaut mieux que de parier sur une solution unique. Enfin, la gouvernance compte : définir qui autorise l'accès d'un agent à quelle ressource, et réviser ces choix régulièrement, transforme une question technique en décision d'organisation maîtrisée.
Aller plus loin
Sécuriser un agent, c'est surtout limiter ce qu'il peut faire et surveiller ce qu'il fait, plutôt que croire à une protection parfaite. Pour acquérir ces réflexes de conception, parcourez le catalogue des 31 formations.
Vous voulez maîtriser ce sujet en pratique ?
Cabinet MARA forme en ligne, sur des cas réels, avec des modules courts et un suivi de progression.
Voir la formation liée Les 31 formations