Chapitre 5 — Validation des entrées et filtrage des sorties

Cinquième billet de la tournée chapitre par chapitre de LLM Primer VII : Sécurité de l'IA. Le chapitre qui transforme le cadre de mitigation stratifié du chapitre 4 en discipline opérationnelle — étapes d'assainissement, outillage de garde-fous, sortie structurée, red teaming, et métriques de sécurité qui veulent dire quelque chose.

Pourquoi ce chapitre existe

L'architecture de mitigation à quatre couches nommée au chapitre 4 ne vaut que par le caractère opérationnel de ses couches. Le chapitre 5 en développe deux : le côté entrée, où les requêtes utilisateurs sont inspectées puis passées, transformées ou refusées ; et le côté sortie, où la réponse du modèle est vérifiée contre un second jeu de portes avant de quitter le système. Autour des deux vivent les disciplines de prompting structuré, de test adverse et de mesure de la sécurité. Les outils ont mûri — Llama Guard, NeMo Guardrails, Lakera Guard, AWS Bedrock Guardrails, Garak, PyRIT, promptfoo — et les schémas opérationnels pour les câbler ensemble ont convergé.

5.1 L'assainissement est échelonné, non fait d'un coup

« Assainir l'entrée » porte des connotations trompeuses de l'ère de l'injection SQL. Dans les systèmes LLM, l'assainissement est un processus échelonné — inspecter, classer, transformer, passer ou refuser — dont la sortie n'est pas une entrée « sûre » mais une entrée qui a franchi un jeu de portes politiques avec le résultat enregistré. Le pipeline a typiquement quatre types de contrôle, ordonnés par coût. Les contrôles structurels sont les moins chers : limites de longueur, contraintes de jeu de caractères, normalisation Unicode NFKC, retrait des caractères à largeur nulle et confusables qui composent l'essentiel de la littérature sur la contrebande. Les contrôles à base de motifs attrapent les contournements explicites et les gabarits adverses connus ; ils sont bruyants dans les deux sens mais utiles comme grille grossière quand les correspondances sont journalisées plutôt que bloquées. Les contrôles par classification utilisent des modèles de sécurité dédiés — Llama Guard, l'API OpenAI Moderation, et les équivalents de Lakera et AWS Bedrock — pour noter l'entrée contre une taxonomie définie. Les contrôles à base de LLM, le palier le plus coûteux, invoquent un modèle plus petit pour raisonner sur l'intention quand la confiance du classificateur est intermédiaire. Chaque étape a un taux de faux positif et un taux de faux négatif, et les deux doivent être mesurés avant que le pipeline ne soit chargé de trafic de production.

5.2 La sortie structurée est une défense, pas seulement une commodité de formatage

L'architecture de défense en profondeur du chapitre 4 a une troisième couche structurelle que ce chapitre développe : contraindre la sortie du modèle à un schéma défini, pour qu'une sortie même influencée par l'injection ne puisse échapper à l'enveloppe structurelle. La forme la plus simple est le JSON conforme à un schéma. Le modèle est instruit d'émettre du JSON conforme à un schéma ; l'application analyse et valide ; les sorties non conformes sont rejetées ou relancées. La bibliothèque instructor de Jason Liu enveloppe les clients OpenAI et Anthropic avec des modèles pydantic — le développeur écrit une classe décrivant la structure de sortie et la bibliothèque gère la construction du prompt, la validation et la relance. Guidance de Microsoft Research va plus loin, contraignant la génération token par token contre un gabarit qui définit exactement quelles positions peuvent contenir du texte libre. Côté modération de sortie, la famille Llama Guard de Meta — versions 1 à 3, avec couverture multimodale ajoutée en 3 — est devenue le classificateur open-weight canonique sur la fenêtre 2023-2025, intégré à la plupart des piles de production comme filtre de réponse. NVIDIA NeMo Guardrails et les offres commerciales de Lakera, AWS Bedrock et Cisco AI Defense concourent sur un pied similaire.

5.3 Une défense non mesurée n'est pas une défense

Le red teaming est ce qui transforme une affirmation de sécurité en mesure. Le red teaming manuel — testeurs adverses formés, souvent externes — produit des prompts spécifiques qui ont réussi contre le déploiement, groupés par schéma d'attaque. Le red teaming automatisé passe l'échelle du travail manuel à travers l'espace des entrées. NVIDIA Garak, ouvert en source en 2023 et continuellement mis à jour, exécute une batterie de sondes contre un point de terminaison cible et rapporte lesquelles ont réussi ; les sondes couvrent l'injection de prompt, la fuite de données, l'élicitation de discours haineux, la contrebande par encodage, les jailbreaks par jeu de rôle, et ainsi de suite. Microsoft PyRIT (Python Risk Identification Toolkit), sorti en 2024, ajoute un schéma de red team agentique où un modèle génère des attaques contre un autre. promptfoo compare prompts et modèles sur des jeux d'évaluation, utile quand la question est laquelle des configurations est la plus sûre. Les métriques qui comptent composent deux modes de défaillance. Le taux de succès d'attaque répond à « quelle fraction d'un jeu d'attaques défini passe ? » La calibration des refus répond à « quelle fraction des requêtes refusées n'aurait pas dû l'être ? » Un système avec zéro succès d'attaque et 50 % de refus n'a pas résolu le problème ; il a déplacé le coût des sorties dangereuses vers des sorties inutiles. Les deux métriques exigent des échantillons étiquetés tirés des distributions de trafic réel, et les deux sont conditionnelles à la composition du jeu d'évaluation. Rapporter un chiffre unique sans la composition est là où les affirmations de sécurité induisent le plus souvent en erreur.

Ce que prépare le Chapitre 5

Le chapitre 6 reprend spécifiquement la génération augmentée par récupération. La couche d'entrée développée ici traite le message de l'utilisateur comme la portion non fiable. Les systèmes RAG ajoutent une seconde portion non fiable : les morceaux récupérés, dont la provenance est souvent moins propre que le message de l'utilisateur. L'injection indirecte de prompt de Greshake, la caractérisation par Liu des attaques par injection contre les applications intégrant des LLM, l'empoisonnement de corpus de récupération de Zhong, et les lignes plus récentes PoisonedRAG et BadRAG décrivent toutes comment cette seconde surface échoue. Le chapitre 6 parcourt les frontières de confiance dans le RAG, les schémas d'attaque spécifiques, l'architecture de récupération sécurisée sur laquelle le domaine a convergé, et les pratiques de surveillance qui font émerger les attaques au niveau de la récupération avant qu'elles ne deviennent des incidents.

Prochaine étape — Chapitre 6 : Risques de la génération augmentée par récupération. Frontières de confiance dans le RAG, injection de documents malveillants, empoisonnement d'index via le chemin des embeddings, et la surveillance qui attrape les attaques que l'assainissement a manquées.