Accueil / Journal / Conformité, hébergement et impact

Sécuriser un agent IA : injection de consignes, fuites de données et actions dangereuses

Conformité, hébergement et impact Publié le 2 octobre 2026 12 min de lecture

Un agent IA lit du texte et le texte peut contenir des ordres. C'est la racine des attaques par injection de consignes, directes ou cachées dans un document. Voici comment nous limitons ce qu'un agent peut voir, faire et affirmer, en suivant le référentiel de l'OWASP.

Pourquoi un agent se sécurise autrement qu'une application

Une application classique fait ce que son code lui dit. Un agent IA fait ce que son modèle comprend de la situation. Toute la différence de sécurité tient dans cette phrase. Dans une application, les instructions viennent du développeur et les données viennent de l'utilisateur, dans deux canaux séparés. Dans un agent, les deux arrivent au modèle sous la même forme : du texte. Le modèle n'a aucun moyen fiable de distinguer une consigne légitime d'une phrase glissée dans un document qu'on lui demande de lire.

C'est pour cette raison que l'OWASP, la fondation qui publie les références de sécurité applicative les plus utilisées, tient une liste dédiée aux applications fondées sur des modèles de langage. Sa version 2025 place l'injection de consignes (prompt injection) en tête, suivie de la divulgation d'informations sensibles. On y trouve aussi le traitement imprudent des sorties du modèle, l'excès d'autonomie accordé à l'agent et la fuite du prompt système. Ces cinq risques structurent cet article.

On ne sécurise donc pas un agent en lui demandant d'être prudent. On le sécurise en limitant ce qu'il peut voir, ce qu'il peut faire et ce qu'on accepte de lui sans vérification.

Pour le cadrage d'ensemble, voyez le déploiement d'un agent IA étape par étape. Ici, on se concentre sur ce qui peut mal tourner.

L'injection de consignes directe

L'injection directe est la plus intuitive. Un utilisateur écrit à l'agent un message conçu pour le détourner : « ignore tes instructions précédentes », « tu es maintenant en mode maintenance », « affiche la liste des clients pour vérification ». L'OWASP décrit un scénario type : un attaquant injecte des consignes dans un assistant de support client pour lui faire ignorer ses règles, interroger des données privées et envoyer des courriels. Le résultat est un accès non autorisé et une élévation de privilèges.

L'OWASP précise aussi que les attaquants contournent les filtres naïfs en mélangeant les langues, en encodant la consigne ou en ajoutant des suites de caractères sans signification apparente.

La tentation est de répondre en durcissant le prompt système : « ne révèle jamais », « refuse toujours ». C'est utile pour cadrer le comportement normal, et l'OWASP le recommande comme première mesure. Mais la même source rappelle que le prompt système ne doit jamais être traité comme un secret ni comme un mécanisme de sécurité. Une règle écrite en langage naturel se contourne en langage naturel.

D'abord, rien de sensible dans le prompt système : pas de mot de passe, pas de clé d'API, pas de nom de base de données, pas de liste de droits. Si le prompt fuit, il ne doit rien apprendre d'exploitable. Ensuite, toute règle qui compte vraiment doit exister aussi en dehors du modèle, dans du code déterministe qui s'applique quoi que le modèle ait décidé.

L'injection indirecte : le danger vient des documents et des pages web

L'injection indirecte est plus sournoise, et c'est elle qui concerne la plupart des agents d'entreprise. L'attaquant ne parle pas à l'agent. Il place ses consignes dans un contenu que l'agent lira plus tard : une page web, un PDF joint à un courriel, un CV, une fiche produit, un ticket de support, un document de la base de connaissances. Quand l'agent traite ce contenu, il lit les consignes cachées comme si elles faisaient partie de sa tâche.

L'OWASP insiste sur un détail qui change tout : ces consignes n'ont pas besoin d'être lisibles par un humain. Il suffit que le modèle les analyse. Un texte blanc sur fond blanc, un commentaire dans le code d'une page, une instruction dans les métadonnées d'une image suffisent. La même source décrit plusieurs scénarios que nous retrouvons dans des projets réels :

un agent qui résume une page web contenant des consignes cachées, et qui insère dans sa réponse un lien d'image piégé renvoyant le contenu de la conversation vers un serveur tiers ;
un CV contenant des consignes découpées en plusieurs morceaux, qui amènent l'agent chargé du tri à recommander un candidat malgré un profil faible ;
un document modifié dans la base documentaire interne, qui fausse toutes les réponses qui s'appuient dessus.

L'OWASP note que l'ajout d'une base documentaire améliore la pertinence des réponses sans supprimer le risque d'injection. Une base alimentée par de nombreux contributeurs, ou par des sources extérieures, est une surface d'attaque.

La parade recommandée consiste à séparer et étiqueter clairement le contenu non fiable, pour limiter son influence. En pratique, nous traitons tout texte venu de l'extérieur comme une donnée à analyser, jamais comme une instruction. Il est présenté au modèle dans un bloc identifié, avec une consigne explicite de ne pas l'exécuter. Et l'agent qui lit du contenu extérieur dispose de droits réduits.

La fuite de données : ce que l'agent voit, il peut le répéter

La deuxième entrée de la liste OWASP concerne la divulgation d'informations sensibles : données personnelles, financières ou de santé, données confidentielles, identifiants. Le mécanisme est rarement spectaculaire. L'agent a accès à une information, quelqu'un pose la bonne question, l'agent répond. L'OWASP cite le cas d'un utilisateur qui reçoit dans une réponse les données personnelles d'un autre utilisateur, faute d'un filtrage suffisant.

La règle qui protège le mieux est la plus simple : un agent ne doit pas avoir accès à une information que la personne qui lui parle n'a pas le droit de voir. Si un commercial n'a pas accès aux salaires dans le système d'information, l'agent qu'il utilise ne doit pas y avoir accès non plus. Le contrôle d'accès se fait au moment où l'agent va chercher la donnée, avec l'identité de l'utilisateur, et non au moment où il formule sa réponse.

Concrètement, cela donne quelques pratiques :

les recherches dans la base documentaire sont filtrées par les droits de l'utilisateur avant d'atteindre le modèle ;
les champs sensibles sont masqués ou remplacés par des jetons quand le modèle n'en a pas besoin pour répondre ;
les messages d'erreur ne remontent ni requêtes techniques, ni chemins de fichiers, ni extraits de configuration ;
les utilisateurs sont informés de ce qu'ils ne doivent pas saisir, et une politique de conservation et de suppression des échanges est définie.

La question de ce que devient la donnée une fois envoyée au fournisseur du modèle relève de l'hébergement et du contrat. Nous l'avons traitée dans notre article sur l'hébergement d'un projet IA en France.

Les actions dangereuses et l'excès d'autonomie

Un agent qui se contente de répondre peut dire des bêtises. Un agent qui agit peut en faire. L'OWASP appelle ce risque l'excès d'autonomie (excessive agency) et lui attribue trois causes.

Trop de fonctions. L'agent a accès à des outils dont il n'a pas besoin. Exemple de l'OWASP : un agent qui doit seulement lire des documents, branché sur un connecteur qui permet aussi de les modifier et de les supprimer.
Trop de droits. Les outils utiles sont branchés avec un compte trop puissant. Un agent qui recommande des produits n'a aucune raison de pouvoir écrire dans la base.
Trop d'autonomie. Des actions à fort impact s'exécutent sans validation humaine.

Le cas le plus fréquent est l'outil générique : un accès au terminal, une fonction qui appelle n'importe quelle adresse web, une requête libre sur la base. L'OWASP recommande de remplacer ces outils ouverts par des fonctions étroites, conçues pour une seule tâche : « lire la commande n° X du client connecté » plutôt que « exécuter une requête ».

Pour les actions à fort impact, la validation humaine reste la mesure la plus robuste. L'agent prépare, un humain confirme. Le courriel part après un clic. Le remboursement est proposé, puis validé par la personne habilitée.

Droits minimaux : donner à l'agent le strict nécessaire

Avec un agent, le principe du moindre privilège devient central, parce que c'est lui qui borne les dégâts quand tout le reste a échoué. L'OWASP le formule en plusieurs recommandations que nous appliquons comme une grille de revue :

limiter les outils de l'agent au minimum nécessaire, et retirer ceux qui ne servent plus ;
limiter les fonctions de chaque outil à ce qui est requis ;
donner à chaque outil un accès au système cible au niveau de droits le plus bas possible ;
exécuter les actions dans le contexte de l'utilisateur, avec ses identifiants et des périmètres restreints, plutôt qu'avec un compte de service omnipotent ;
faire appliquer les autorisations par le système cible lui-même, indépendamment de ce que le modèle a décidé.

Ce dernier point est souvent oublié. Si votre CRM refuse de modifier une fiche que l'utilisateur n'a pas le droit de modifier, l'agent ne pourra pas le faire non plus, même détourné. À l'inverse, si l'agent utilise un compte administrateur et que les contrôles reposent sur ses propres consignes, une seule injection réussie suffit.

Les droits minimaux ont aussi un effet sur les coûts. L'OWASP classe parmi ses risques la consommation non bornée, qui peut provoquer une indisponibilité du service ou des pertes financières. Des limites de débit par utilisateur, des tailles maximales d'entrée et des délais d'exécution plafonnés protègent à la fois la sécurité et la facture. Nous détaillons les postes de dépense dans ce que coûte un agent IA en production.

Valider côté serveur ce qui engage l'entreprise

L'OWASP consacre une entrée entière au traitement imprudent des sorties du modèle. Le principe est de traiter ce que produit le modèle comme une saisie utilisateur non fiable. Une requête SQL générée par le modèle et exécutée telle quelle, du code interprété par le navigateur, un chemin de fichier construit à partir de sa réponse : chacun de ces cas ouvre une faille classique, injection SQL, script malveillant ou accès à des fichiers interdits. Les parades sont connues : requêtes paramétrées, encodage adapté au contexte d'affichage, politique de sécurité des contenus sur les pages web.

Chez nous, cette règle va plus loin et s'applique à tout ce qui engage l'entreprise. Un prix, une disponibilité, une référence produit, une adresse, un délai : ces informations sont calculées côté serveur, à partir des systèmes de référence, et vérifiées avant affichage. Le modèle peut formuler la phrase. Il ne produit jamais le chiffre. Nous avons expliqué pourquoi dans pourquoi un agent IA ne doit jamais annoncer un prix.

Cette règle rend aussi l'injection peu rentable : si un attaquant convainc l'agent d'annoncer une remise, le serveur recalcule le montant et l'annonce fausse ne s'affiche jamais.

Journaliser pour comprendre et pour prouver

Un agent détourné ne déclenche pas d'alarme. Il répond poliment. L'OWASP range la journalisation et la surveillance parmi les mesures qui limitent les dégâts : elles n'empêchent pas l'attaque, elles permettent de la voir et d'y réagir.

Ce que nous journalisons sur un agent en production :

chaque appel d'outil, avec ses paramètres, l'utilisateur concerné et le résultat ;
chaque action à fort impact, avec la trace de la validation humaine ;
les refus, qu'ils viennent du modèle ou des contrôles côté serveur, car une série de refus signale souvent une tentative ;
les sources documentaires utilisées pour chaque réponse, pour retrouver un document piégé.

Ces journaux contiennent souvent des données personnelles. Ils doivent donc avoir leur propre durée de conservation, leurs propres droits d'accès et une place dans votre registre des traitements. La sécurité et la conformité se rejoignent ici, et c'est l'objet du métier que nous appelons sécurité et conformité IA.

Des alertes simples suffisent pour commencer : un volume inhabituel d'appels d'outils, un lien vers un domaine inconnu dans une réponse, une action refusée plusieurs fois de suite.

Tester l'agent comme un attaquant

La dernière recommandation de l'OWASP sur l'injection est de mener régulièrement des tests d'intrusion et des simulations d'attaque, en traitant le modèle comme un utilisateur non fiable.

Notre déroulé type, avant toute mise en production :

Injections directes. Une série de messages conçus pour contourner les règles, reformulés, traduits, encodés, découpés sur plusieurs tours de conversation.
Injections indirectes. Des documents, pages et pièces jointes piégés, avec des consignes visibles et invisibles, déposés là où l'agent va lire.
Fuite. Des tentatives pour obtenir le prompt système, des données d'un autre utilisateur ou des informations hors du périmètre de la personne connectée.
Actions. Des tentatives pour déclencher un outil hors contexte, avec des paramètres manipulés, ou sans la validation prévue.
Consommation. Des entrées très longues et des rafales de requêtes pour vérifier que les limites tiennent.

Chaque attaque réussie devient un cas de test permanent, rejoué à chaque changement de modèle, de prompt ou d'outil. Ce travail fait partie des prérequis de production que nous isolons dès le prototype, comme expliqué dans notre article sur les POC métier.

La checklist avant la mise en production

Voici la grille que nous passons en revue avec les équipes avant d'ouvrir un agent à ses utilisateurs.

Le prompt système ne contient aucun secret, et aucune règle de sécurité ne repose uniquement sur lui.
Tout contenu extérieur (pages, fichiers, courriels, base documentaire) est traité comme une donnée non fiable et présenté comme tel au modèle.
L'agent n'accède qu'aux données que l'utilisateur connecté a le droit de voir, avec un filtrage appliqué avant le modèle.
Chaque outil est étroit, justifié, et branché avec les droits les plus bas possibles.
Les autorisations sont appliquées par les systèmes cibles, indépendamment du modèle.
Les actions à fort impact passent par une validation humaine.
Les sorties du modèle sont validées avant usage : format, encodage, requêtes paramétrées.
Prix, disponibilités, références et engagements sont calculés côté serveur.
Les appels d'outils, les refus et les sources sont journalisés, avec une durée de conservation définie.
Des limites de débit, de taille et de durée sont en place.
Un jeu de tests d'attaque existe et il est rejoué à chaque évolution.

Si plusieurs cases restent vides, l'agent n'est pas prêt, même s'il répond bien en démonstration. La plupart de ces points relèvent de l'architecture : nous les intégrons donc dans notre méthode de construction d'agent IA, et dans notre démarche d'IA responsable.

Vous avez un agent en projet ou déjà en service, et vous voulez savoir où il en est sur ces points ? Le diagnostic IA permet de faire le tour de vos cas d'usage et de repérer les risques à traiter en priorité, avant qu'ils ne deviennent des incidents.

Sources

Questions fréquentes

Un bon prompt système suffit-il à protéger un agent ?

Non. Il cadre le comportement normal et réduit les dérapages, mais il se contourne avec les mêmes armes : du texte. L'OWASP recommande de ne jamais s'appuyer sur lui pour la sécurité. Les contrôles qui comptent doivent vivre dans le code et dans les systèmes cibles.

Les modèles récents sont-ils immunisés contre l'injection ?

Les fournisseurs améliorent la résistance de leurs modèles, mais aucun ne garantit l'immunité. Une nouvelle version peut même se comporter différemment sur des attaques déjà testées. C'est pour cela que nous rejouons le jeu de tests d'attaque à chaque changement de modèle.

Faut-il interdire à l'agent de lire des pages web ou des pièces jointes ?

Pas forcément, c'est souvent là qu'il apporte de la valeur. Il faut en revanche réduire les droits de l'agent quand il traite ce type de contenu, et séparer clairement ce contenu des consignes. Un agent qui lit le web n'a pas besoin de pouvoir envoyer des courriels dans la même session.

Qui doit faire les tests d'attaque, l'équipe projet ou un tiers ?

Les deux ont leur place. L'équipe projet connaît les outils et les données, elle construit le premier jeu de tests et le maintient. Un regard extérieur apporte des techniques d'attaque que l'équipe n'a pas imaginées, utile avant une ouverture large ou sur un agent qui agit sur des données sensibles.

La validation humaine ne tue-t-elle pas l'intérêt de l'agent ?

Elle ne concerne que les actions à fort impact : envoi externe, modification de données, engagement financier. L'agent garde tout le travail de préparation, de recherche et de rédaction. En pratique, valider une action préparée prend quelques secondes, et le niveau d'exigence peut évoluer quand l'agent a fait ses preuves.