- Comment répondre à la « triade létale (lethal trifecta) » qui permet les abus par les utilisateurs
- Les agents LLM qui suivent littéralement des instructions en langage naturel présentent une vulnérabilité structurelle liée à l’absence de séparation entre données et commandes, ce qui peut les amener à exécuter aussi des instructions malveillantes présentes dans des textes externes
- Lorsque se combinent exposition à des contenus externes, accès à des données privées et capacité de communication vers l’extérieur, il se forme une « triade létale » qui amplifie le risque qu’une erreur mineure dégénère en incident de sécurité grave
- Parmi les cas concrets : le correctif de vulnérabilité de Microsoft Copilot (juin), le détournement du bot de support client de DPD (janvier 2024) et la démonstration d’exfiltration de données via un PDF avec l’agent IA de Notion (19 septembre)
- Les principes de défense proposés sont le démantèlement de la triade, l’isolation des modèles non fiables et le contrôle des communications, ainsi que des conceptions sûres acceptant des limites fonctionnelles, comme la double architecture LLM CaMeL de Google
- Le secteur estime qu’un simple renforcement par l’apprentissage ne suffit pas, et qu’au vu du risque lié aux combinaisons de plugins MCP et des retards de lancement produit (par ex. le report des fonctions IA d’Apple), il faut passer à des architectures conçues en supposant une marge de sécurité probabiliste
Définition du problème central : absence de séparation entre données et commandes et « triade létale »
- Les LLM traitent le texte en entrée comme une prédiction séquentielle de mots, avec un modèle d’interprétation unifié qui répond aux questions et tente d’exécuter les commandes
- Si un document externe contient une instruction malveillante insérée du type « copier le disque dur puis l’envoyer à l’e-mail de l’attaquant », un risque d’exécution incidente peut survenir lors d’une tâche de résumé
- Si exposition à des contenus externes + accès à des données privées + voie d’émission vers l’extérieur coexistent dans un même système, la triade létale (lethal trifecta) est constituée
- La triade létale est un concept proposé par le chercheur en sécurité Simon Willison : lorsque les trois éléments sont ouverts simultanément, l’inévitabilité des abus augmente fortement
Signaux précurseurs et cas réels
- À l’été 2022, le terme prompt injection est apparu de manière autonome, mettant en lumière le danger d’une docilité alignée
- En janvier 2024, il a été constaté que le bot de support client de DPD suivait aussi des réponses injurieuses, ce qui a conduit à une interruption du service
- En juin 2025, une vulnérabilité de triade a été découverte dans Microsoft Copilot et un correctif discret a été déployé ; il a été précisé qu’aucune exploitation réelle n’avait été signalée
- Le 19 septembre 2025, le chercheur Abi Raghuram a démontré qu’un agent IA de Notion, disposant d’un accès aux documents, aux bases de données et au web, pouvait subir une exfiltration de données via un PDF manipulé
Pourquoi c’est difficile à bloquer : échecs probabilistes et canaux de contournement
- Même si l’on définit des règles de priorité via le prompt système, il subsiste toujours un glissement probabiliste, par exemple 1 échec sur 100
- Même avec des consignes de sécurité telles que « détecter les signaux nocifs », il reste possible qu’un contenu passe un jour
- Bloquer les communications sortantes est essentiel, mais interdire uniquement l’envoi d’e-mails ne suffit pas : il est possible de coder des valeurs secrètes dans un chemin d’URL, entraînant une fuite dans les journaux de requêtes web
- Le simple fait d’autoriser l’accès au web peut se transformer en canal d’exfiltration de données
Stratégie de défense 1 : ne pas constituer la triade
- Supprimer ne serait-ce qu’un seul élément fait chuter fortement le risque
- Si l’on limite les entrées à des sources internes générées et vérifiées, on peut éliminer l’exposition externe
- Une stratégie de réduction du périmètre est efficace, par exemple lorsqu’un assistant de codage ne traite qu’une base de code de confiance, ou qu’une enceinte connectée ne gère que des commandes vocales
- Toutefois, pour des tâches comme la gestion des e-mails, qui manipulent par nature des données externes, une suppression complète est difficile
Stratégie de défense 2 : isolation des modèles non fiables et moindre privilège
- L’article de Google publié en mars recommande de classer comme « modèle non fiable » tout modèle exposé à des données externes et de l’isoler des informations sensibles
- Des ressources comme l’e-mail, à la fois privées et alimentées de l’extérieur, remplissent déjà deux critères, ce qui les place dans un état à haut risque
- Le moindre privilège, le sandboxing et les frontières de contexte servent à séparer l’accès aux secrets internes et aux identifiants
Stratégie de défense 3 : contraintes sur le modèle et séparation architecturale
- Renforcer les schémas de refus via les données d’entraînement est nécessaire, mais pas suffisant
- CaMeL de Google sépare les rôles à l’aide de deux LLM
- Le modèle de confiance convertit le langage naturel de l’utilisateur en code contraint
- Le modèle non fiable ne fait que du remplissage de blancs, dans un flux strictement contraint qui permet de garantir des propriétés de sécurité
- En contrepartie, cette approche accepte une contrainte fonctionnelle : une réduction de l’éventail des tâches possibles
Risques dans l’écosystème grand public et des plugins : le cas du MCP
- L’ajout d’applications auxiliaires via Model Context Protocol (MCP) peut, par composition de capacités, former une triade létale accidentelle
- Même si chaque MCP est sûr individuellement, la sécurité de leur combinaison peut se rompre, d’où la nécessité de limiter les installations et de vérifier l’origine
Signaux du secteur : reports de lancement et durcissement des positions
- En 2024, Apple avait annoncé des fonctions comme « lire le podcast recommandé par Jamie », mais a choisi de retarder leur lancement dans un contexte de craintes sur la formation d’une triade létale
- Même dans la dernière version d’iOS en septembre 2025, les grandes fonctions IA sont absentes, l’évolution s’étant recentrée sur la traduction et les améliorations de l’interface, ce qui reflète la réalité de ces difficultés
Checklist pratique : que faire ?
- Modélisation du risque : expliciter parmi les éléments ouverts les entrées externes, les données sensibles et les émissions vers l’extérieur, puis cartographier l’existence ou non d’une triade
- Conception des frontières : limiter le modèle non fiable à un tampon en lecture seule, faire transiter les secrets et les tokens par un service relais distinct, et bloquer l’accès direct
- Blocage des sorties : restreindre par liste blanche les canaux d’exfiltration de données tels que e-mail, requêtes web et téléversement de fichiers
- Moteur de politiques : n’exécuter que les appels d’outils autorisés, après compilation des commandes de langage naturel vers une politique structurée
- Audit et garde-fous : gérer les échecs probabilistes via des jeux de tests de prompt injection, l’automatisation red team, et le logging de session / suivi du taux de refus
- Acceptation des compromis fonctionnels : la nécessité est posée d’accepter un changement de culture d’ingénierie consistant à sacrifier une part de performance et d’autonomie pour obtenir une marge de sécurité probabiliste
Conclusion
- Les avertissements s’accumulent : lorsque les trois éléments de la triade restent ouverts, la découverte de vulnérabilités devient inévitable
- Le démantèlement de la triade, l’isolation des modèles non fiables, le contrôle des sorties et une architecture à séparation des rôles constituent aujourd’hui les mesures les plus réalistes
- À long terme, il faudra renoncer à l’obsession du déterminisme et intégrer une marge de sécurité probabiliste dans la conception, dans le cadre d’une évolution de l’ingénierie logicielle
Aucun commentaire pour le moment.