Vous construisez un agent LLM capable d'appeler des outils (e-mail, BDD). La saisie utilisateur pourrait contenir des instructions cachées. Comment réduire le risque d'injection de prompt ?

Un LLM mélange instructions et données dans le même flux de texte, donc tout contenu contrôlé par l'attaquant — tapé directement ou tiré d'un e-mail, d'un document ou d'une page web que l'agent lit — peut porter des instructions que le modèle est susceptible de suivre. C'est l'injection de prompt, et dès lors que le modèle peut appeler des outils (envoyer un e-mail, interroger ou modifier une base), une injection réussie se transforme en action réelle. On ne peut pas y répondre de façon fiable par le prompt.

Pourquoi « dis-lui simplement d'ignorer » échoue

Le modèle n'a pas de frontière robuste entre votre prompt système et le texte injecté ; les deux ne sont que des tokens. Une ligne disant « ignore les instructions malveillantes » est elle-même susceptible d'être annulée par une injection habilement formulée. Défendre au niveau du texte, c'est combattre sur le terrain de l'attaquant.

L'architecture qui réduit réellement le risque

• Traiter toute sortie du modèle comme une entrée non fiable pour le reste de votre système. Validez, vérifiez les types et bornez les arguments d'outil avant l'exécution.
• Moindre privilège par outil. Limitez chaque outil au minimum de données et de capacités, avec des identifiants éphémères et restreints — pas un large jeton admin.
• Validation humaine pour les actions sensibles ou irréversibles : envoi d'e-mail externe, suppression d'enregistrements, mouvements d'argent.
• Isoler et contraindre l'exécution et le trafic sortant pour limiter l'exfiltration et le SSRF.

Cela correspond directement aux risques LLM de l'OWASP : excès d'autonomie (trop de capacité/autonomie) et gestion inadéquate des sorties (agir sur la sortie du modèle sans validation).

Pourquoi les autres options échouent

• Augmenter la température ne fait que rendre les sorties plus aléatoires ; cela n'a aucun rapport avec le fait qu'une instruction injectée soit suivie.
• Journaliser en espérant enregistre l'incident une fois le dommage causé — utile en investigation, inutile en prévention.

Ce que l'examinateur cherche à évaluer

Si vous comprenez que l'injection de prompt est une contrainte de conception, pas un bug que l'on corrige par la formulation, et si vous architecturez la zone d'impact à la baisse : moindre privilège, points de confirmation et validation des sorties, pour qu'un modèle détourné ne puisse toujours pas faire grand mal.