“Construisez un château, pas un mur. Les murs tombent ; les couches vous donnent le temps de détecter et de réagir.”
Défense en profondeur, parce que le modèle vous trahira
Vous ne pouvez pas faire confiance au modèle. Non parce qu'il est malveillant, mais parce qu'il suit des instructions provenant de contenu non fiable et que vous ne pouvez pas empêcher cela de manière fiable. Vous l'enveloppez donc de couches, chacune supposant que la couche intérieure pourrait faillir : filtrez ce qui entre, contraignez ce que le modèle peut faire, filtrez ce qui sort, et surveillez tout. Aucune couche n'est porteuse seule.
Couche 1 — Contrôler les entrées
Avant que du contenu atteigne le modèle, vous avez l'occasion de réduire le risque. Validez et contraignez les entrées utilisateur là où le format le permet. Analysez le contenu récupéré et fourni par l'utilisateur pour y détecter des patrons d'injection évidents et des charges malveillantes connues. Supprimez ou neutralisez le texte caché (caractères invisibles, blanc sur blanc, métadonnées suspectes) dans les documents. Cela attrape les attaques paresseuses et augmente le coût des autres — mais traitez-le comme une friction, jamais comme un mur, parce qu'un payload déterminé passe quand même.
Couche 2 — Contraindre ce que le modèle peut faire
C'est la couche la plus robuste, et celle qui tient indépendamment de la sophistication de l'attaque. Si le modèle ne peut faire que peu de choses, un modèle compromis ne peut faire que peu de choses. Tout ici porte sur la capacité, pas la détection.
- Moindre privilège — chaque outil et source de données délimités à exactement ce que la tâche requiert, rien « au cas où ».
- Zones de confiance séparées — le contenu non fiable et les actions privilégiées ne se rencontrent jamais dans un seul appel au modèle sans une porte (l'idée du double LLM).
- Humain dans la boucle — les actions irréversibles ou à enjeux élevés nécessitent une approbation ; le modèle propose, une personne dispose.
- Bac à sable — l'exécution des outils et tout code généré par le modèle s'exécutent de manière isolée, sans chemin vers le reste de votre système.
- Limites de débit et de budget — des plafonds par utilisateur pour que l'abus ne puisse pas épuiser les ressources ni faire grimper la facture.
Couche 3 — Vérifier les sorties
Avant que la sortie du modèle atteigne un utilisateur ou déclenche une action, inspectez-la. Validez-la par rapport au schéma attendu — et rejetez tout ce qui est malformé. Analysez les sorties pour y repérer des secrets divulgués, des renseignements personnels ou d'autres données qui ne devraient pas figurer dans la réponse. Pour les actions, confirmez que l'appel d'outil proposé est dans l'ensemble autorisé avec les paramètres corrects. Le filtre de sortie est votre dernière chance d'intercepter une compromission que les couches d'entrée et de capacité ont manquée.
Couche 4 — Surveiller et réagir
Vous n'empêcherez pas chaque attaque, vous devez donc être en mesure de les voir. Journalisez chaque prompt, récupération, appel d'outil, sortie et décision (les mêmes traces que le chapitre sur les évaluations du cours de construction demandait — elles font double emploi comme piste d'audit de sécurité). Surveillez les anomalies : pics de refus, patrons inhabituels d'appels d'outils, tentatives d'extraction du prompt système, coûts incontrôlés. Et disposez d'un chemin d'incident : comment détectez, contenez et répondez-vous lorsque — et non si — quelque chose passe ?
La surveillance est aussi comment vous apprenez. Chaque vraie attaque que vous interceptez devient un cas d'évaluation adversariale et un signal d'ajustement pour vos filtres. La posture de sécurité d'un système d'IA en production n'est pas un état que vous atteignez ; c'est une boucle que vous faites tourner.
Équipe rouge : attaquez-vous vous-même en premier
N'attendez pas qu'un attaquant trouve les failles. Constituer une équipe rouge signifie attaquer délibérément votre propre système — essayer chaque injection, contournement et abus de capacité auquel vous pouvez penser — avant la mise en production et continuellement après. Le résultat n'est pas seulement une liste de bogues ; c'est un ensemble croissant d'évaluations adversariales qui prévient les régressions.
Faites-en une boucle, pas un événement ponctuel. Chaque découverte obtient un correctif et un test permanent, de sorte que la même faille ne peut jamais se rouvrir inaperçue. C'est exactement la discipline d'évaluation du cours de construction, pointée vers la sécurité plutôt que vers la qualité — et c'est la différence entre un système sécurisé aujourd'hui et un système qui reste sécurisé à mesure qu'il évolue.
En une ligne chacun
- Défendez en profondeur : supposez que le modèle suivra des instructions hostiles et enveloppez-le de couches dont chacune rattrape la défaillance de la précédente.
- Contrôlez les entrées (friction), contraignez les capacités (la couche robuste), vérifiez les sorties (dernier filet), et surveillez tout (voyez les attaques).
- La contrainte de capacité surpasse la détection : la question est ce qu'un modèle compromis peut faire, pas s'il peut être trompé.
- Constituez une équipe rouge en continu, transformant chaque découverte en un correctif plus une évaluation adversariale permanente — la sécurité est une boucle, pas une case à cocher.
Où aller ensuite