Sorties d'IA non filtrées : quand la réponse du modèle attaque votre système

Une sortie de LLM branchée telle quelle sur votre base de données, un shell, un navigateur ou un appel d'outil revient à exécuter du code écrit par un inconnu : c'est le risque LLM05 de l'OWASP, et il se neutralise en interposant quatre couches de contrôle entre la réponse du modèle et votre système. Dans cet article, je vous montre pourquoi une réponse d'IA ne doit jamais être considérée comme fiable, et la méthode pour la valider, l'encoder et l'isoler avant qu'elle ne se retourne contre vous.

Le problème : vous traitez la réponse du modèle comme du code de confiance

La plupart des incidents que je rencontre ne viennent pas du prompt reçu par l'IA, mais de ce que l'application fait de sa réponse. Un développeur récupère le texte produit par le modèle et le passe directement à une requête SQL, à une commande système, à un rendu de page web ou à un outil qui agit sur votre système d'information. La sortie est implicitement considérée comme propre, alors qu'elle est le résultat direct de ce qu'un utilisateur a demandé, y compris un utilisateur malveillant.

Un attaquant n'a alors pas besoin de percer votre modèle. Il lui suffit de formuler sa demande de façon à ce que la réponse contienne une charge utile : une clause SQL qui vide une table, une balise de script qui s'exécute dans le navigateur d'un autre utilisateur, une commande shell glissée dans un nom de fichier, ou une instruction d'outil que votre agent va exécuter sans broncher. Le modèle n'est qu'un tuyau ; la faille est en aval, dans le composant qui exécute sa sortie.

C'est l'un des dix risques de sécurité propres aux grands modèles de langage. Pour le situer dans le tableau d'ensemble, je vous renvoie à mon guide sur l'OWASP LLM Top 10 expliqué pour décider. Voyons maintenant comment refermer précisément cette porte.

La méthode : quatre couches entre la sortie et l'exécution

La règle fondatrice tient en une phrase : une sortie de LLM est une donnée non fiable, au même titre que n'importe quelle saisie venue de l'extérieur. Vous ne l'exécutez jamais directement. Vous l'interposez entre quatre couches, dans l'ordre, avant qu'elle n'atteigne le composant qui agit.

Couche 1 : ne jamais faire confiance à la sortie

C'est un changement de posture avant d'être une technique. Partez du principe que toute réponse du modèle peut être hostile, exactement comme un formulaire rempli par un visiteur anonyme. Concrètement, aucune sortie ne doit atteindre un interpréteur, une base ou un navigateur sans passer par les couches suivantes. Si un composant de votre chaîne exécute une réponse brute, c'est déjà une vulnérabilité, indépendamment de la qualité de votre modèle.

Couche 2 : valider contre un schéma strict

Plutôt que de laisser le modèle répondre en texte libre, contraignez sa sortie à une structure que vous vérifiez ensuite. Demandez une réponse dans un format connu, puis validez ce format côté application avant tout usage :

• Le type et le format : la sortie attendue est-elle bien un entier, une date valide, un identifiant conforme à votre modèle de données ?
• Une liste blanche de valeurs: quand le champ des réponses possibles est fini (un statut, une catégorie, un nom de table), n'acceptez que les valeurs prévues et rejetez tout le reste.
• Les bornes : longueur maximale, plage de valeurs, absence de caractères de contrôle. Une réponse hors gabarit est refusée, jamais réparée à la volée.

Ce filtrage positif, qui n'accepte que le connu au lieu de tenter d'interdire l'inconnu, est de loin le plus robuste. Une liste noire de motifs interdits sera toujours contournée par une variante que vous n'aviez pas prévue.

Couche 3 : encoder selon la destination

Une même sortie n'est pas dangereuse de la même façon selon l'endroit où elle atterrit. Avant de la transmettre, encodez-la ou échappez-la pour sa cible précise, avec les mécanismes éprouvés que vous utiliseriez déjà pour une saisie utilisateur :

Couche 4 : isoler l'exécution et confirmer les actions sensibles

Même validée et encodée, une sortie ne doit jamais s'exécuter avec plus de droits que nécessaire. Faites tourner le composant qui l'exécute avec le strict minimum de privilèges : un compte en lecture seule pour une requête d'analyse, un périmètre d'outils fermé pour un agent, un environnement isolé pour tout code généré. Et pour toute action irréversible ou sensible, écriture, envoi, suppression, transaction, interposez une confirmation humaine explicite. La supervision humaine n'est pas seulement une bonne pratique de sécurité : c'est aussi une exigence de l'AI Act pour les usages qui pèsent sur des personnes.

Le résultat : une injection en aval qui n'a plus de prise

Avec ces quatre couches empilées, la réponse la plus piégée du modèle se heurte à un mur avant d'atteindre quoi que ce soit d'exécutable. La charge utile est rejetée par la validation, neutralisée par l'encodage, ou contenue par l'isolation et la confirmation. Vous ne pariez plus sur la sagesse du modèle : vous rendez sa sortie inoffensive par construction, ce qui est le seul niveau de garantie tenable.

Cette rigueur produit aussi une preuve. Journalisez ce qui est rejeté à chaque couche : vous obtenez une trace des tentatives d'injection et la démonstration que votre chaîne les arrête, un élément précieux le jour d'un audit ou d'un contrôle. Pour éprouver ces défenses en conditions réelles, c'est l'objet d'un red teaming de votre LLM, qui attaque votre application comme le ferait un adversaire.

Questions fréquentes

N'est-ce pas suffisant de bien filtrer ce qui entre dans l'IA ?

Non. Filtrer l'entrée réduit certains abus, mais la réponse du modèle reste imprévisible et peut fabriquer une charge dangereuse à partir d'une demande d'apparence anodine. La sécurité se joue des deux côtés, et le côté sortie est le plus souvent négligé.

Mon IA ne fait que générer du texte affiché, suis-je concerné ?

Oui, dès que ce texte est rendu dans un navigateur. Une réponse contenant du code de script peut s'exécuter chez la personne qui la consulte si vous ne l'échappez pas à l'affichage. Le risque n'existe que si la sortie touche un interpréteur, mais un navigateur en est un.

Faut-il traiter différemment un agent qui appelle des outils ?

C'est même le cas le plus sensible. Un agent transforme une sortie en action sur votre système. Restreignez le périmètre d'outils accessibles, typez chaque paramètre et imposez une confirmation pour toute action irréversible. Une sortie qui déclenche une action mérite plus de contrôle qu'une sortie qui s'affiche.

Une liste noire de mots interdits ne suffit-elle pas ?

Elle donne une fausse sécurité. Les motifs d'attaque se déclinent en variantes infinies qu'une liste noire ne couvre jamais entièrement. Préférez une liste blanche qui n'autorise que le format et les valeurs attendus : tout ce qui n'y figure pas est refusé par défaut.

Reprendre le contrôle sur ce que vos IA renvoient à votre système, c'est exactement le travail de mon audit Sécurité & Conformité IA: cartographier chaque canal de sortie, tester son exposition et sécuriser son exécution avant la mise en production. Le même réflexe s'applique aux données que le modèle peut laisser échapper, un sujet que je traite dans mon article sur la fuite d'information par un LLM.

Cet article a une visée pédagogique et ne constitue pas un conseil juridique. Chaque situation mérite une analyse au cas par cas.