La sortie du modèle est une entrée non fiable

On se méfie de ce que l'utilisateur envoie au modèle. On oublie souvent de se méfier de ce que le modèle renvoie. Or sa sortie peut avoir été influencée par une injection, par un document piégé, ou simplement être fausse. Dès qu'elle est affichée, exécutée ou transmise à un autre système, elle doit être traitée comme une saisie venant d'un inconnu.

Les quatre chemins classiques

• Affichée comme du HTML. Une réponse insérée telle quelle dans une page peut contenir du code qui s'exécute dans le navigateur de l'utilisateur : c'est une faille XSS, connue depuis vingt ans, revenue par cette porte.
• Insérée dans une requête de base de données, une commande système, un chemin de fichier : l'injection SQL ou de commande, version IA.
• Rendue en Markdown avec images. Une attaque bien documentée : une injection pousse le modèle à écrire une image dont l'adresse pointe vers le serveur de l'attaquant, avec des données de la conversation dans l'adresse. L'interface charge l'image, et les données partent, sans aucun clic.
• Utilisée comme paramètre d'action : un montant, un destinataire, un identifiant que l'application exécute sans vérifier.

Les défenses

• Échapper systématiquement tout texte du modèle avant affichage, et passer par un moteur de rendu Markdown configuré de façon restrictive.
• Bloquer les ressources externes dans les réponses (images, contenus chargés automatiquement), ou n'autoriser qu'une liste fermée de domaines, idéalement renforcée par une politique de sécurité du contenu côté navigateur.
• Des sorties structurées validées : quand le modèle produit des données pour une action, exigez un schéma strict et validez-le dans votre code (types, bornes, valeurs autorisées).
• Des requêtes paramétrées et des listes blanches d'actions, jamais de texte du modèle concaténé dans une commande.
• Un bac à sable pour tout code que le modèle écrit et que vous exécutez : sans accès au réseau ni aux secrets par défaut.