Défenses et contrôles techniques

Pourquoi ce chapitre est structurant

Les chapitres précédents ont établi un constat commun : la prompt injectionInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire, l'empoisonnementempoisonnementCybersécuritéIntroduction délibérée d'exemples corrompus dans un jeu d'entraînement, afin d'altérer durablement le comportement du modèle.Voir dans le glossaire de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire et l'exfiltration exploitent des propriétés structurelles des systèmes fondés sur des modèles de langage, pas des défauts d'implémentation isolés. Aucun correctif ne referme ces failles à la source. Ce chapitre change de registre : il ne s'agit plus de comprendre l'attaque, mais de construire l'architecture qui en absorbe l'impact.

Trois couches de contrôle forment l'ossature de cette architecture : le filtrage des entrées et des sorties, l'isolation de l'exécution, et la gestion des identités et des accès — l'IAM (Identity and Access Management) appliquée aux composants IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire. Aucune de ces couches n'est fiable seule. Un filtre contourné doit être rattrapé par l'isolation ; une isolation percée doit être contenue par l'IAM ; un accès mal maîtrisé doit rester visible dans la supervision. C'est cette redondance délibérée, et non la perfection d'une couche unique, qui constitue une défense robuste.

Un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire ne peut pas être configuré pour « refuser de façon garantie » une action, au sens où un pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire refuse un paquet. Ses refus sont des comportements statistiques, contournables par reformulation. La sécurité réelle se joue dans les couches qui l'entourent — c'est l'objet de ce chapitre.

Filtrage des entrées et des sorties

Le filtrage est la couche la plus visible et souvent la première mise en place, ce qui lui donne une importance disproportionnée : un filtre solide réduit le volume d'attaques triviales, mais ne neutralise jamais une attaque bien construite.

Filtrage en entrée

Le filtrage en entrée intervient avant que le contenu — message utilisateur, document récupéré, résultat d'un appel d'outil — n'atteigne la fenêtre de contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire du modèle. Les techniques courantes :

• Classificateurs dédiés — un modèle distinct, entraîné spécifiquement à détecter les tentatives d'injection ou de jailbreakJailbreakCybersécuritéTentative de contourner les garde-fous d'un LLM pour obtenir des sorties interdites ou dangereuses.Voir dans le glossaire, évalue le contenu avant transmission. Contrairement à un filtre par mots-clés, il généralise mieux aux reformulations, sans être infaillible pour autant.
• Détection de motifs structurels — repérer les formulations impératives inhabituelles dans un contenu censé être descriptif : un CV qui contient une instruction à la deuxième personne est en soi un signal.
• Limitation de la longueur et de la structure attendue — un champ censé contenir un nom de produit n'a aucune raison de dépasser quelques dizaines de caractères ; une entrée hors gabarit est un signal, indépendamment de son contenu.
• Normalisation avant analyse — décoder les encodages courants (base64, encodage URL, homoglyphes) avant d'appliquer les détecteurs, faute de quoi un filtre analyse un texte inoffensif en apparence alors que le modèle décodera lui-même la charge utile.

Filtrage en sortie

Le filtrage en sortie contrôle ce que le système restitue ou transmet à un outil, une fois la génération produite :

• Détection de fuite de donnéesfuite de donnéesIAErreur consistant à laisser entrer dans l'entraînement une information qui n'existera pas au moment réel de la prédiction. Le modèle affiche des scores excellents puis s'effondre en production.Voir dans le glossaire sensibles — repérage de motifs (clés d'API, numéros de carte, identifiants internes) avant qu'une réponse ne quitte le système, y compris quand cette donnée provient du contexte fourni au modèle plutôt que d'un fait appris.
• Validation de schéma structuré — quand une sortie doit alimenter un appel d'outil, la faire passer par une validation stricte de schéma (types, champs attendus, valeurs autorisées) avant exécution, plutôt que de faire confiance au format produit par le modèle.
• Jetons canaris — insérer dans le contexte des valeurs sentinelles inertes ; leur réapparition dans une sortie ou un appel réseau signale une fuite de contexte ou une tentative d'exfiltration, indépendamment de son origine exacte.

Tout filtrage basé sur la détection de motifs se contourne par reformulation, encodage ou fragmentation de la charge utile sur plusieurs échanges. Un filtre efficace réduit le volume d'attaques opportunistes et complique la tâche d'un attaquant déterminé ; il ne doit jamais être la seule ligne de défense d'un système qui expose des actions à conséquence réelle.

Isolation et sandboxing de l'exécution

L'isolation part d'un principe différent du filtrage : au lieu de tenter de reconnaître le contenu malveillant, elle limite ce que l'exécution peut atteindre, quel que soit le contenu traité. C'est la couche qui rattrape ce qu'un filtre a laissé passer.

Isolation de l'environnement d'exécution

Un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire capable d'exécuter du code, de naviguer sur le web ou d'interagir avec un système de fichiers doit le faire dans un environnement dont le rayon d'action est borné a priori :

• Conteneurs ou machines virtuelles éphémères — chaque session, ou chaque tâche, s'exécute dans un environnement recréé de zéro et détruit à la fin, empêchant la persistance d'un artefact malveillant d'une session à l'autre.
• Contrôle strict des flux réseau sortants (egress) — un interpréteur de code n'a, par défaut, aucune raison de pouvoir initier des connexions sortantes vers des domaines arbitraires ; une liste blanche explicite de destinations autorisées ferme le canal d'exfiltration le plus direct.
• Isolation du système de fichiers — un espace de travail dédié et temporaire, sans accès en lecture ou écriture aux données de production, aux secrets d'autres sessions ou au système hôte.
• Limites de ressources — plafonner le temps CPU, la mémoire et le nombre d'appels d'outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire par tâche empêche une boucle détournée de consommer des ressources indéfiniment ou de multiplier les tentatives d'une même attaque.

Un agent doté d'un interpréteur de code sans restriction d'egress reçoit, via un document piégé, l'instruction d'encoder des données sensibles présentes dans son contexte sous forme de sous-domaines DNSDNSRéseauxSystème qui traduit un nom de domaine en adresse IP, par interrogations successives de la racine, des serveurs de premier niveau puis des serveurs faisant autorité.Voir dans le glossaire puis d'effectuer des résolutions vers ces sous-domaines. Aucun fichier n'est transféré au sens classique, mais chaque résolution DNS journalisée côté attaquant reconstitue la donnée exfiltrée. Un contrôle d'egress restreint aux seules destinations nécessaires à la tâche aurait bloqué ce canal, indépendamment de la capacité du filtre de sortie à reconnaître la manœuvre.

Isolation entre sessions et entre locataires

Dans un système multi-utilisateur, l'isolation doit aussi empêcher qu'une session accède au contexte, aux documents ou aux résultats d'une autre. Un cache de contexte partagé par erreur entre deux utilisateurs, ou une base vectoriellebase vectorielleIABase spécialisée qui indexe des embeddings pour retrouver rapidement les passages les plus proches d'une requête (cœur du RAG).Voir dans le glossaire interrogée sans filtrage par identité, transforme un incident limité à un utilisateur en fuite transversale touchant l'ensemble d'un locataire, voire plusieurs.

Gestion des identités et des accès (IAM) pour les systèmes IA

L'IAM est la couche qui détermine ce qu'une action peut réellement produire, indépendamment de ce que le modèle a été « instruit » de faire ou de ne pas faire. C'est une distinction fondamentale : dire au modèle, dans son promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire système, qu'il n'est pas autorisé à effectuer une action n'est pas un contrôle d'accès — c'est une instruction parmi d'autres, dans le même canal texte que tout le reste, contournable comme n'importe quelle autre instruction.

Principes appliqués aux agents IA

• Identité propre par agent ou par tâche — un agent ne doit pas hériter d'un compte de service générique à privilèges larges partagé par l'ensemble du système ; chaque agent, ou chaque type de tâche, dispose d'une identité dédiée dont les droits sont audités indépendamment.
• Moindre privilège strict — les permissions accordées correspondent exactement au périmètre de la tâche, jamais à un ensemble large « au cas où ». Un agent chargé de résumer des tickets n'a aucune raison de disposer d'un droit d'écriture sur la base de données correspondante.
• Identifiants à courte durée de vie — des jetons d'accès limités dans le temps et dans leur portée (scopes OAuth précis, jetons signés à expiration courte) réduisent la fenêtre d'exploitation d'un identifiant compromis, comparés à des clés statiques valables indéfiniment.
• Séparation entre l'identité de l'agent et celle de l'utilisateur final — quand un agent agit pour le compte d'un utilisateur, ses actions doivent être bornées par les droits réels de cet utilisateur, pas par un privilège technique plus large accordé à l'agent pour simplifier l'intégration.
• Validation humaine explicite pour les actions irréversibles — l'envoi d'un message externe, une suppression, un paiement, une modification de configuration en production doivent franchir une étape de confirmation qui ne dépend pas de la seule décision du modèle.
• Gestion des secrets hors du contexte du modèle — une clé d'API ou un identifiant ne doit jamais transiter en clair dans le prompt ou l'historique de conversation ; l'agent invoque un outil qui détient le secret, sans jamais y avoir accès lui-même en texte.

Un prompt système qui énonce « tu ne peux accéder qu'aux dossiers du département marketing » décrit une intention, pas une contrainte technique. Si le compte de service sous-jacent a un accès en lecture à l'ensemble du système de fichiers, une injection réussie peut faire ignorer cette consigne. L'IAM applique la contrainte au niveau du compte, indépendamment de ce que le modèle « croit » être autorisé à faire.

Une matrice de permissions comme outil de conception

Avant de connecter un agent à un outil, il est utile de documenter pour chaque capacité : l'action précise permise, les données ou systèmes atteignables, la réversibilité de l'action, et si une validation humaine est requise. Cette matrice, tenue à jour, sert à la fois de spécification technique lors de la conception et de référence lors d'un audit ou d'un incident.

Assembler les trois couches : une architecture en profondeur

Les trois couches ne se recouvrent pas : chacune arrête ce que les précédentes ont laissé passer, et chacune a un mode d'échec distinct qu'il faut connaître pour ne pas en surestimer la portée.

Cette lecture en trois colonnes rappelle pourquoi la couche IAM est souvent la plus déterminante en cas d'échec des deux premières : même si un contenu piégé traverse le filtre et que le sandbox laisse une capacité d'action, une politique d'accès correctement restreinte borne le dommage maximal possible.

Supervision, journalisation et détection

Les trois couches précédentes réduisent la probabilité et l'impact d'une compromission ; elles ne garantissent pas son absence. La supervision permet de savoir qu'un incident a eu lieu, quand, et quelle a été son étendue.

• Journalisation de la provenance du contexte — pour chaque réponse ou action générée, conserver quelles sources (documents, résultats d'outils, tours de conversation) ont contribué au contexte, condition nécessaire pour investiguer après coup.
• Journalisation des appels d'outils avec leur identité d'origine — chaque appel doit être traçable à l'agent et à la tâche qui l'a déclenché, avec ses paramètres complets, pas uniquement un résumé.
• Limitation de débit par identité (rate limiting) — plafonner le nombre de requêtes, d'appels d'outils ou de volumes de données par identité et par fenêtre de temps ralentit une exploitation automatisée et rend une anomalie plus visible.
• Détection d'anomalies comportementales — un agent qui accède soudainement à un volume ou à un type de ressource inhabituel par rapport à son profil d'usage historique constitue un signal, même en l'absence de règle explicite violée.
• Jetons canaris de détection — au-delà du filtrage de sortie, disperser des valeurs sentinelles dans des zones du système normalement non accessibles ; leur apparition dans un journal ou un appel externe signale un accès qui n'aurait pas dû se produire.

Un jeton canari qui ne se déclenche jamais sur une longue période ne prouve pas l'absence de compromission : il peut simplement ne pas être positionné là où une attaque réelle passerait. Faire évoluer régulièrement leur emplacement, en fonction des nouvelles capacités accordées au système, garde ce mécanisme utile dans le temps.

Checklist de déploiement

• Un filtre d'entrée et un filtre de sortie sont en place, avec un plan de mise à jour régulier face aux nouvelles techniques de contournement.
• Toute exécution de code ou navigation web par un agent se fait dans un environnement isolé, éphémère, avec un contrôle explicite des flux réseau sortants.
• Chaque agent dispose d'une identité propre et de permissions strictement limitées à sa tâche, documentées dans une matrice de permissions à jour.
• Les secrets et identifiants ne transitent jamais en clair dans le contexte fourni au modèle.
• Toute action irréversible déclenchée par un agent passe par une validation humaine explicite, indépendante du raisonnement du modèle.
• La provenance du contexte et les appels d'outils sont journalisés avec une granularité suffisante pour une investigation après incident.
• Des mécanismes de détection (limitation de débit, canaris, anomalies comportementales) sont en place et testés périodiquement, pas seulement déployés une fois.

Ce qu'il faut retenir

Aucune des trois couches présentées dans ce chapitre — filtrage, isolation, IAM — ne suffit isolément à sécuriser un système fondé sur un modèle de langage, parce qu'aucune d'entre elles ne corrige la propriété structurelle à l'origine du risque : l'absence de séparation fiable entre instruction et donnée dans le modèle lui-même. Leur combinaison, en revanche, construit une défense en profondeur où l'échec d'une couche est rattrapé par la suivante, et où la supervision garantit qu'un échec complet reste détectable. C'est cette architecture, pas la robustesse d'un composant unique, qui distingue un système IA déployé avec rigueur d'un système qui repose sur la seule bonne volonté du modèle.