Gestion incorrecte des sorties
Comprendre
La sortie du LLM est traitée comme sûre alors qu’elle devrait être validée, nettoyée et contrainte avant d’être exécutée, parsée, envoyée à un outil, injectée dans un e-mail, un script, une requête ou un workflow.
Une sortie fluide paraît « prête à l’emploi », mais elle peut contenir des caractères spéciaux, une structure invalide, des hypothèses non dites ou des actions non autorisées.
Tester
une sortie est branchée sur une action sensible sans validation de schéma, sans typage, sans revue humaine ; un champ manquant est fabriqué pour satisfaire le format.
Trois garde-fous, dans cet ordre : validation de schéma stricte, échappement systématique, revue humaine sur l’irréversible. Une sortie fluide paraît prête à l’emploi — c’est précisément le piège.
Génération de requêtes, de configurations, de fiches articles : la fluidité n’est pas la validité — le contrôle se fait côté système, jamais côté prompt.
Prévenir
- › validation de schéma.
- › sanitation / escaping.
- › allowlist de champs.
- › moteur de politique.
- › confirmation humaine avant exécution.
- › Contrôle résiduel : ne jamais brancher directement une sortie LLM sur une action sensible sans garde applicative.
Référence
Preuve D (cadre/norme, pas une preuve empirique) — OWASP Top 10 for LLM Applications 2025 — LLM05 (S-40) genai.owasp.org/llmrisk/llm052025 improper output handling.
Ce que le cadre fournit — la définition de référence de ce risque et ses mesures de prévention (correspondance de code vérifiée à l’audit v10.12.4).