Injection de prompt et la trilogie mortelle : sécuriser les agents d’IA
Injection de commandes et le trio mortel : pourquoi les agents d’IA ne peuvent pas distinguer vos instructions de celles d’un attaquant, comment EchoLeak et l’attaque GitHub MCP ont fonctionné.
Sources: Prompt Injection and Agent Security: The Unsolved Problem
En juin 2025, des chercheurs ont révélé une faille dans Microsoft 365 Copilot et l’ont nommée EchoLeak. L’attaque se déroulait ainsi : quelqu’un vous envoie un e-mail ayant l’air normal. Vous ne l’ouvrez pas, vous ne cliquez sur rien et vous ne le lisez même pas. Copilot le lit néanmoins, car il lit toute votre boîte de réception pour répondre à vos questions. Cachées dans cet e-mail se trouvent des instructions indiquant à Copilot de collecter des données sensibles provenant de vos autres documents et de les envoyer discrètement vers un serveur externe via une image qui se charge automatiquement. Aucun clic n’est nécessaire, et la victime ne fait rien de mal. L’agent obéit, mais pas à la bonne personne.
EchoLeak a reçu un CVE (CVE-2025-32711), a fait l’objet d’une correction de sécurité et a cessé de fonctionner, constituant ainsi le premier cas connu d’injection de prompt utilisée pour voler des données réelles dans un système d’IA en production. Ce ne sera pas le dernier. Au cours de l’année suivante, ce même type d’attaque est apparu dans l’intégration MCP de GitHub, Duo de GitLab, l’IA de Slack, NotebookLM de Google ainsi que dans tous les navigateurs d’IA lancés. À la fin de 2025, les responsables de la sécurité d’OpenAI affirmaient publiquement que l’injection de prompt ne pourrait peut-être jamais être entièrement résolue pour les agents de navigateur, et le National Cyber Security Centre du Royaume-Uni était d’accord.
Le fait fondamental en matière de sécurité lié aux IA agentes est simple, et nous n’avons toujours pas de réponse claire à ce sujet : le modèle reçoit vos instructions ainsi que celles d’un attaquant par exactement le même canal, et il ne peut pas les distinguer de manière fiable. Ci-dessous : pourquoi c’est le cas, pourquoi cela affecte beaucoup plus les agents que les chatbots, et quelles défenses sont efficaces, par rapport à celles présentées dans les diapositives des fournisseurs.
Un seul canal pour tout
Le mécanisme vient en premier, car c’est une mauvaise interprétation de celui-ci qui entraîne des directives de sécurité insuffisantes.
Un modèle de langage reçoit une seule entrée : une longue séquence de tokens. Le prompt de votre système fait partie de celle-ci. La question de l’utilisateur est constituée de tokens, tout comme la page web que l’agent vient de télécharger, l’e-mail qu’il a lu, la sortie de l’outil qu’il a reçue, le PDF analysé ainsi que le texte alternatif d’une image. Tout cela arrive sous forme d’une seule séquence linéaire, et le modèle prédit ce qui va suivre. Rien dans cette séquence ne permet de distinguer certains tokens comme des commandes fiables émises par l’opérateur et d’autres comme des données non fiables à traiter. Simon Willison, qui a inventé le terme « injection de prompt » en 2022, le décrit ainsi : les modèles suivront volontiers toutes les instructions qui leur parviennent, qu’elles proviennent de l’opérateur ou d’une autre source.
C’est là l’essence du problème, et il est profondément enraciné. Aucune mise à jour du modèle ne pourra y remédier, car la faiblesse fait partie intégrante de la conception. Ces systèmes ont été conçus pour obéir à des instructions formulées en langage simple. Puis nous leur donnons du texte en langage simple extrait d’Internet, et nous feignons la surprise lorsque les ordres intégrés sont exécutés. L’injection n’est rien d’autre que l’obéissance aux instructions, mais au mauvais maître.
Comparez l’injection SQL, qui a donné son nom à cette attaque. Une solution réelle à l’injection SQL existe grâce aux requêtes paramétrées, qui indiquent de manière claire à la base de données que telle partie constitue une commande et telle autre des données, et ne doit donc jamais être traitée comme une commande. Trois décennies de sécurité web dépendent de la capacité à tracer cette frontière au sein de la machine. Au sein d’un LLM, personne ne sait comment faire. Tout se passe en bande, le canal des commandes et le canal des données étant unifiés. C’est pourquoi le réflexe courant, qui consiste à demander au modèle, dans le prompt du système, d’ignorer les instructions présentes dans le contenu web, échoue. Vous utilisez le canal compromis pour défendre ce même canal compromis, et un contenu bien conçu peut toujours contourner une mise en garde en langue anglaise.
Deux types d’attaques sont souvent confondus. Dans l’injection directe, c’est l’utilisateur lui-même qui tape quelque chose de malveillant, comme une demande pour afficher la invite système. Cela ressemble davantage à une évasion : une personne attaque un agent qu’elle est autorisée à utiliser. L’injection indirecte, quant à elle, menace les agents eux-mêmes. L’instruction malveillante se cache dans du matériel externe que l’agent traite dans le cadre de ses tâches, comme une page web, un e-mail, une invitation de calendrier, un commentaire de code ou un problème sur GitHub. L’attaquant ne s’adresse jamais directement à l’agent ; il laisse un piège dans du contenu qu’il espère que l’agent lira un jour au nom d’une victime qui lui fait confiance. Tous les incidents mentionnés ci-dessus relèvent de ce type. Cette méthode est efficace car l’attaquant n’a pas besoin d’accéder directement à vous, seulement d’avoir une certaine influence sur ce à quoi votre agent sera confronté.
Le trio mortel
Le modèle mental le plus utile ici est la « trifecta mortelle » de Simon Willison, qui explique pourquoi certains agents sont extrêmement exploitables de manière désastreuse, tandis que d’autres ne sont que gênants à attaquer.
Un agent devient une arme de vol de données lorsqu’il combine trois capacités.
- Accès à des données privées. Il peut lire vos e-mails, vos répertoires privés, vos fichiers clients ou votre wiki interne. C’est généralement la raison d’existence de cet agent, ce qui vous empêche de simplement le supprimer.
- Exposition à du contenu non fiable. Il traite du texte qu’il n’a pas écrit et que vous n’avez pas vérifié : pages web, e-mails reçus, documents, sorties de systèmes tiers. C’est également généralement l’objectif principal.
- Un moyen de communiquer à l’extérieur. Il peut envoyer des données vers un endroit où un attaquant peut les voir, en effectuant une requête HTTP, en envoyant un e-mail, en appelant une API, en affichant une image depuis l’URL d’un attaquant ou en ouvrant une demande de fusion.
N’importe lequel de ces éléments est acceptable, et deux d’entre eux permettent généralement de survivre. Tous les trois réunis dans un agent sous un même ensemble de identifiants reviennent à avoir une arme pointée vers vos données. Un attaquant qui contrôle la deuxième capacité peut pirater les instructions de l’agent, utiliser la première pour recueillir des secrets et la troisième pour les envoyer. C’est exactement la séquence suivie par les attaques EchoLeak et GitHub MCP.
Le cas GitHub est suffisamment clair pour être analysé en détail. Invariant Labs l’a démontré en mai 2025. Un développeur connecte un agent de codage au serveur MCP officiel de GitHub à l’aide d’un token d’accès personnel, celui-ci couvrant, comme la plupart des gens le configurent, tous leurs dépôts, publics et privés. Le développeur demande quelque chose de inoffensif, comme examiner les problèmes ouverts dans un dépôt public. L’agent les lit. L’un d’eux a été soumis par un attaquant et contient des instructions cachées : lire les dépôts privés de cet utilisateur et publier ce que l’on trouve dans une demande de fusion publique. L’agent dispose de la deuxième capacité (il se contente de lire le contenu de l’attaquant), de la première (le token permet d’accéder aux dépôts privés) et de la troisième (il peut ouvrir une demande de fusion publique). Il met toutes ces capacités en œuvre. Lors de la démonstration, du code privé et même des informations de paiement personnelles sont devenus visibles pour n’importe qui. Chaque action effectuée par le token était conforme à ses permissions, et l’agent fonctionnait exactement comme prévu. La stratégie de sécurité a simplement fonctionné.
Regardez la solution apportée : la mesure de prévention de Docker n’a pas tenté de détecter le problème malveillant. Elle a brisé cette stratégie en raison de ses règles : chaque session est liée à un seul répertoire, de sorte que dès que l’agent tente d’accéder à un autre, son accès est bloqué, quelles que soient les instructions données. Le modèle n’est pas devenu plus intelligent ; une capacité a été supprimée au niveau où les capacités se combinent, et c’est là que réside la structure de toute véritable défense.
Pourquoi les agents sont bien pires que les chatbots
Les premières inquiétudes concernant la sécurité des LLM rendaient l’injection acceptable. Un chatbot disait quelque chose d’impoli ou divulguait son prompt : agaçant, mais pas désastreux. Les agents, eux, augmentent les risques dans tous les sens.
Les chatbots génèrent du texte, tandis que les agents exécutent des actions. Si l’on pirate un chatbot, une seule personne lit une réponse différente. En revanche, si l’on pirate un agent, celui-ci se comporte différemment et peut avoir un impact réel : il peut envoyer des e-mails, transférer des fonds, effacer des données, fusionner du code ou exécuter des commandes shell. La liste des dix principaux risques de 2026 du projet OWASP Agentic Security ressemble précisément à une liste de ces conséquences : détournement des objectifs, mauvaise utilisation des outils, abus de privilèges, empoisonnement de la mémoire ainsi que des défaillances qui se propagent dans des systèmes multi-agents. Chacun de ces risques est en réalité une forme d’injection amplifiée par les capacités réelles du modèle.
Trois facteurs expliquent cet niveau d’exposition.
La surface d’attaque correspond à tout ce que l’agent lit. Dans un agent réel, la requête de l’opérateur ne représente qu’une petite partie des tokens, tandis que 70 % ou plus du contexte provient souvent des résultats des outils et du contenu récupéré. Cette répartition déséquilibrée constitue également un problème de sécurité. La majeure partie de ce qui se trouve dans le modèle lorsqu’il prend une décision provient de sources extérieures, et n’importe quel token peut être une instruction. Votre requête de confiance n’est qu’une petite erreur face à un flot d’entrées non fiables.
L’autonomie élimine les obstacles liés à la vitesse humaine. La valeur d’un agent réside dans sa capacité à exécuter des boucles sans demander d’autorisation à chaque étape, mais chaque étape non supervisée représente une occasion pour une instruction injectée d’être exécutée sans que personne ne puisse l’arrêter. Plus l’agent est autonome et performant, plus cette fenêtre d’opportunité s’élargit. Les capacités et la possibilité d’injection progressent ensemble, ce qui signifie que, autres choses égales, plus un agent est puissant, plus il est coûteux à laisser entre les mains d’un attaquant.
La persistance et la chaînage ajoutent des risques supplémentaires. Les agents disposent de mémoire, et cette mémoire peut être contaminée : un attaquant plante un « fait » faux dans le stockage à long terme un lundi, ce qui fausse les décisions pendant des semaines. Les agents appellent d’autres agents, de sorte qu’une injection dans les données d’un sous-agent se propage le long d’une chaîne que personne ne surveille de bout en bout. De plus, des navigateurs agents tels qu’Atlas et Comet permettent d’insérer un agent injectable dans la même fenêtre que celle utilisée pour se connecter à sa banque, à son e-mail ou à la console d’administration de son entreprise. Des chercheurs ont déjà trompé Atlas en utilisant du texte malveillant déguisé en URL ou des contenus visant à implanter de faux souvenirs. La réponse d’OpenAI mérite d’être saluée pour son honnêteté : l’entreprise a renforcé son produit grâce à un entraînement adversarial et à des tests automatisés, et a clairement indiqué aux utilisateurs que le problème n’était pas entièrement résolu.
Des défenses utiles
Pour être franc, personne ne sait comment faire en sorte qu’un modèle résiste aux injections à 100 %. Chaque mesure de protection mentionnée ci-dessous réduit le risque, mais aucune ne le supprime complètement. Une véritable sécurité provient de l’accumulation de couches imparfaites et, avant tout, d’une conception du système qui empêche une injection réussie d’accéder à quoi que ce soit de précieux. Voici les mesures de protection réelles, distinctes des illusions rassurantes.
Commencez par briser la triade. Cela rapporte plus que tout le reste ici, et cela ne nécessite pas d’apprentissage automatique. Pour chaque agent, vérifiez s’il possède simultanément les trois capacités, et dans ce cas, si l’une d’entre elles peut être supprimée dans ce contexte. Un agent qui lit des pages web non fiables ne devrait pas également disposer de mots de passe pour des bases de données en production. Un agent qui accède à des données privées doit voir sa communication sortante limitée à une liste d’autorisation si stricte qu’il ne reste aucun moyen d’envoyer des secrets. La solution de GitHub consistant à utiliser un seul répertoire par session constitue une façon de briser cette triade. Elle fonctionne parce qu’elle est basée sur l’architecture plutôt que sur des principes probabilistes.
Utilisez un design qui protège le planificateur contre des entrées dangereuses. Les recherches les plus prometteuses considèrent les injections comme une question de flux de données plutôt que de leur détection possible. Le modèle Dual LLM ainsi que CaMeL, sa version plus stricte (« Defeating Prompt Injections by Design », 2025), divisent l’agent en deux rôles. Un modèle privilégié lit votre demande et planifie les étapes à suivre, mais ne voit jamais de matériel non fiable. Un modèle en quarantaine lit ce matériel non fiable, qu’il s’agisse d’un e-mail ou d’une page web, mais ne dispose d’aucun outil et ne peut pas agir. CaMeL va encore plus loin : le plan du modèle privilégié est compilé en un programme restreint, et un interpréteur personnalisé suit l’origine de chaque valeur. Tout ce qui provient d’une source non fiable est ainsi marqué, et il ne peut pas déclencher d’action dangereuse à moins qu’une politique ne l’y autorise. Cela correspond le plus aux requêtes paramétrées pour les LLM, une séparation entre les commandes et les données qui est réellement respectée. Il y a un prix à payer : quelqu’un doit écrire les politiques, et d’interminables demandes d’approbation peuvent amener les utilisateurs à cliquer sur « oui » par réflexe. Néanmoins, cela repose sur des principes, et ces principes résistent à un attaquant déterminé.
Restreignez les actions à l’aide d’une échelle de permissions. Classez chaque action en fonction du niveau de dommage qu’elle pourrait causer, et laissez le système de contrôle, et non la commande, appliquer cette hiérarchie. La lecture se fait en silence, tout ce qui est réversible est enregistré, les actions difficiles à inverser (envoyer, supprimer, payer, fusionner) nécessitent une confirmation humaine indiquant précisément ce qui va se produire, tandis que les actions irréversibles et coûteuses sont bloquées ou acheminées via un processus d’approbation que le modèle ne peut pas influencer. Une commande est une suggestion avec laquelle un attaquant peut discuter, tandis qu’une règle de contrôle est un obstacle qu’il ne peut pas contourner. Dire au modèle de demander toujours l’autorisation avant d’envoyer de l’argent vaut la peine d’être fait, mais cela ne suffit pas à lui seul. Exiger que le code de paiement utilise un jeton que le modèle ne détient jamais constitue une mesure de sécurité.
Appliquez le principe du moindre privilège en utilisant des identifiants à portée restreinte. Les injections ne peuvent causer de dommages que dans la mesure de ce que l’agent est autorisé à faire ; donnez donc à chaque agent la plus petite portée possible, un jeton à durée de vie courte et le minimum d’outils nécessaires pour accomplir sa tâche. L’incident sur GitHub a été causé par un jeton à large portée qui se comportait comme tels, et une portée OAuth par répertoire aurait pu l’empêcher. Il s’agit là d’une pratique de base et un peu ennuyeuse, mais elle est plus efficace que n’importe quel prompt ingénieux.
Ajoutez la détection, mais ne comptez pas trop sur elle. Les équipes privilégient d’abord cette couche, alors qu’elle devrait être la dernière. Les classificateurs d’injection sont des modèles entraînés à reconnaître « ignorer les instructions précédentes » et ses innombrables reformulations, et ils parviennent effectivement à détecter une grande partie des attaques. Les classificateurs d’utilisation informatique d’Anthropic, le filtre XPIA de Microsoft et de nombreuses startups travaillent dans ce domaine. Utilisez-les, car ils font augmenter le coût des attaques. Soyez cependant clair sur ce qu’ils offrent. Un classificateur qui bloque 99 % des tentatives semble excellent, mais du point de vue de la sécurité, cela constitue une échec, car l’injection n’est pas du bruit aléatoire. L’adversaire peut effectuer des tentatives infinies et s’adapter à votre filtre. La première manœuvre d’EchoLeak a consisté à envoyer un e-mail conçu pour passer le classificateur d’injection de Microsoft, ce qu’il a fait. Face à un attaquant capable de s’adapter, un taux de fuite de 1 % représente déjà un obstacle majeur. Gardez la détection en tant que couche supplémentaire, et jamais comme fondement de votre sécurité.
Enregistrez tout. Chaque appel à une fonction, chaque document récupéré et chaque action effectuée doivent être enregistrés et traçables. En termes de sécurité, il s’agit de votre couche de détection et d’analyse forensique. A posteriori, vous voulez savoir ce que l’agent a lu juste avant un comportement anormal et d’où proviennent les instructions, ainsi que recevoir des alertes en cas d’anomalies lorsque l’agent accède soudainement à des ressources hors de son schéma habituel. On ne peut pas se défendre, ni même comprendre, une attaque qu’on ne peut pas voir. Un agent non observable n’est pas seulement difficile à déboguer : c’est une faille dont vous apprendrez l’existence par quelqu’un d’autre.
Trois incidents à étudier
Les schémas restent clairs lorsqu’ils sont associés à des événements réels. Ces trois cas, sur une période d’environ dix-huit mois, illustrent différents niveaux de ce problème.
EchoLeak (Microsoft 365 Copilot, CVE-2025-32711). Ce qui frappe, c’est l’absence totale de clic de la part de l’utilisateur, plutôt que l’usage de quelque astuce que ce soit. Découvert en janvier 2025, corrigé en mai et rendu public en juin, il s’agissait de la première injection de requête permettant d’extraire des données réelles d’un système d’IA en production sans aucune action de la part de l’utilisateur. Ce mécanisme combinait quatre techniques d’évasion : un e-mail conçu pour passer le classeur XPIA, des liens Markdown de type référence permettant d’éviter la censure des liens, une balise d’image qui s’affichait automatiquement et envoyait une requête externe, ainsi qu’une API de prévisualisation Teams inscrite sur la liste blanche servant de relais pour que les données sortent par une voie autorisée. Chaque mesure mise en place par Microsoft était sensée en soi. L’attaquant a simplement trouvé les failles entre elles. Une série de couches de détection représente également une série de failles, et un adversaire patient les explore toutes.
Le vol lié à GitHub MCP (Invariant Labs, mai 2025). Ce sujet a déjà été abordé, mais il convient de le résumer : rien n’a fonctionné de manière anormale. Aucune identifiante n’a échoué et le modèle est resté intact. Une clé d’accès générale, un agent capable de lire les problèmes rédigés par un attaquant, ainsi que la possibilité d’ouvrir une PR publique, formaient ensemble la vulnérabilité. Il n’y avait ni code d’exploitation ni bug mémoire à corriger, seulement trois fonctionnalités qui n’auraient jamais dû partager la même session. C’est ce qui fait de la sécurité des agents une nouvelle discipline. La faille réside dans la manière dont ces éléments se combinent, et non dans l’un d’eux en particulier.
Les navigateurs agents (Atlas et Comet, fin 2025). Dès la sortie de ChatGPT Atlas et de Comet de Perplexity, les chercheurs ont rapidement démontré des injections dans l’omnibox, où du texte présenté comme une adresse web était exécuté comme une instruction, ainsi que des attaques sur la mémoire laissant un contexte falsifié d’une session à l’autre. La co-localisation rend ce cas particulièrement grave : l’agent injectable se trouve là où vous êtes simultanément authentifié auprès de votre banque, de votre boîte mail et de vos consoles d’administration, ces trois éléments étant par défaut rassemblés dans l’endroit le plus sensible. La réaction d’OpenAI a fixé le ton honnête de l’industrie grâce à un entraînement adversarial, à des tests de pénétration automatisés et à une reconnaissance ouverte du fait que ce problème n’est pas encore résolu. Faites confiance à leurs dires et conçez en supposant que votre agent de navigateur sera finalement trompé.
Que valider, par couche
Pensez en couches et choisissez quelque chose pour chacune d’elles.
- Defense basées sur des modèles de conception : CaMeL et le modèle Dual LLM. Ils séparent la planification des données non fiables et suivent l’origine des données, ce qui offre les garanties les plus solides.
- Classificateurs d’injection : les classificateurs d’Anthropic, Microsoft XPIA, Lakera Guard, PromptArmor et protectai/rebuff. Ils détectent le contenu hostile dans les entrées non fiables, augmentant les coûts sans créer de barrière complète.
- Passerelles et application des politiques : les intercepteurs Docker MCP Gateway, Invariant Guardrails et les listes d’autorisation d’égress. Ceux-ci brisent ce trio en appliquant des politiques qui délimitent les sessions, bloquent l’accès entre ressources et limitent le trafic sortant.
- Outils et benchmarks pour les équipes rouges : AgentDojo, AgentDyn, BIPIA, CyberSecEval et deepteam, qui permettent de rendre les tests d’injection reproductibles et mesurables.
Une règle pour éviter les problèmes : ne achetez pas un seul produit en pensant être protégé. Chaque élément mentionné ci-dessus constitue une couche, et l’idée est qu’aucune couche seule ne suffit. Une posture de sécurité solide combine une défense basée sur des modèles de conception, des identifiants ciblés, une hiérarchie des permissions, un classificateur et un suivi complet, choisis de manière à ce que la neutralisation de l’un d’eux oblige encore l’attaquant à faire face au suivant.
Modèles de défaillance dans la pratique
- La chaîne d’exfiltration. Du contenu non fiable indique à l’agent de collecter des données privées et de les envoyer, comme dans EchoLeak et GitHub MCP. Pour y counter, il faut briser cette chaîne en utilisant des listes d’autorisation d’égress, en traçant le flux des données (CaMeL) et en limitant les identifiants utilisés.
- Le représentant confus. Du contenu injecté pousse l’agent à effectuer une action modifiant l’état que l’utilisateur n’a jamais demandée, comme envoyer un e-mail, supprimer un fichier ou valider une transaction. Pour l’arrêter, il faut mettre en place une hiérarchie d’autorisations exigeant que toute action importante soit approuvée par une personne, avec les règles intégrées directement dans le système.
- Zéro clic. Aucune interaction de l’utilisateur n’est nécessaire, car la lecture en arrière-plan habituelle de l’agent sert de déclencheur, comme pour l’image chargée automatiquement dans EchoLeak. Il faut restreindre les téléchargements automatiques et le rendu externe, contrôler les sorties de données et considérer tout ce qui est consommé passivement comme potentiellement hostile.
Un passe sécurité d’une semaine
Il s’agit d’une démarche simple, concrète et applicable avec un agent que vous possédez déjà.
Jour 1 : cartographiez la trinité. Prenez chaque agent que vous utilisez et notez quels données privées il peut accéder, quel contenu non fiable il ingère et comment il peut envoyer des informations à l’extérieur. Tout agent possédant les trois éléments se retrouve en tête de la liste. Cet inventaire constitue le document de sécurité le plus précieux que vous pourrez rédiger, et une après-midi suffit pour le réaliser.
Jour 2 : brisez au moins un aspect de chaque trifecta. Pour chaque agent à risque, retirez une capacité dans ce cadre. Divisez-le en deux agents ayant des tâches plus restreintes, réduisez leurs prérogatives ou limitez le trafic sortant à une liste autorisée. Il ne sera pas toujours possible d’enlever les trois éléments, mais en en supprimant un seul, on gagne du temps par rapport à des semaines de travail intensif pour renforcer la sécurité.
Jour 3 : créez une échelle de permissions. Énumérez toutes les actions que l’agent peut effectuer et classez-les en catégories silencieuses, enregistrées, confirmées et bloquées en fonction de leur portée. Appliquez les deux niveaux les plus élevés via du code, hors de portée du modèle, et assurez-vous que les messages de confirmation indiquent bien ce qui se produira réellement.
Jour 4 : attaquez votre propre agent. Préparez dix entrées hostiles, y compris une page piégée, un message, un problème, une invitation, un PDF contenant du texte invisible et une image dont le texte alternatif contient des ordres. Faites fonctionner l’agent sur chacune d’elles dans un environnement isolé pour voir ce qui se passe. Quelque chose fonctionnera, et le trouver par vous-même vaut mieux que de le laisser découvrir par quelqu’un d’autre. Un outil de référence comme AgentDojo permet de reproduire cet exercice.
Jour 5 : ajoutez des mécanismes de détection et gardez vos attentes modestes. Placez un classificateur d’injection devant les entrées non fiables et enregistrez ce qu’il signale. Il s’agit d’un détecteur de fumée qui augmente les coûts pour l’attaquant, mais pas d’une barrière efficace. Envoyez ses résultats dans le suivi que vous activerez le jour 6.
Jour 6 : activez le suivi à des fins de sécurité. Vérifiez que chaque appel d’outil, récupération et action est enregistré avec un responsable clairement identifié, et configurez des alertes pour les accès aux ressources qui s’écartent des schémas normaux. Lorsque le suivi existe déjà, vous modifiez simplement la configuration, vous ne lancez pas un projet.
Jour 7 : notez tout par écrit et réessayez après chaque modification. La résistance aux injections n’est pas un objectif à atteindre, c’est une propriété à maintenir en permanence. Chaque nouvel outil, source de données ou fonctionnalité peut à nouveau créer la combinaison dangereuse que vous aviez résolue ; ajoutez donc la question « Est-ce que cela crée à nouveau cette combinaison dangereuse ? » à la liste de contrôle et réexécutez les attaques du jour 4 chaque fois que la réponse pourrait être oui.
Aucune fin propre
L’injection de commandes n’a pas été résolue, et elle ne pourra peut-être pas l’être de la même manière que l’injection SQL, car la propriété qui rend ces modèles utiles, à savoir leur capacité à suivre des instructions en langue ordinaire, est aussi celle qui les rend exploitables, et personne ne sait comment conserver l’une sans l’autre. Les développeurs de navigateurs de pointe commencent à le dire ouvertement, ce qui constitue l’évolution la plus encourageante : l’industrie a cessé de prétendre qu’un modèle plus intelligent ferait disparaître le problème.
Attendre une correction n’est pas un plan. Le vrai plan consiste à faire en sorte que les agents restent en sécurité même après que le modèle ait été trompé, car cela arrivera tôt ou tard. Cela oriente les efforts d’ingénierie : loin de prompts systémiques plus astucieux demandant de la prudence, vers la structure qui entoure le modèle. Brisez ce trio de risques, planifiez toujours en vous protégeant des données non fiables, restreignez chaque autorisation, placez chaque action importante derrière une barrière que le modèle ne peut pas contourner par des paroles, et observez tout. Tout cela se trouve dans le système de contrôle, et rien dans le modèle.
Le modèle est un composant compétent, confiant et vulnérable aux injections, et c’est le système de contrôle qui permet d’en utiliser les capacités en toute sécurité. Si vous faites du modèle votre propre barrière de sécurité, vous serez compromis. En plaçant cette barrière à l’extérieur, sous votre contrôle, vous avez une chance de réussir.
Lectures complémentaires
- DS-STAR expliqué : l’agent de science des données de Google et les raisons de son succès — Une présentation détaillée de l’agent de science des données DS-STAR de Google : ses sept modules, le cycle de rapport DS-STAR+, les prompts publiés, les résultats d’ablation et les limites actuelles.
- Notes pratiques : J’exécute un agent de codage IA localement et ses performances sont presque deux fois supérieures — Guide opérationnel des Notes pratiques : J’exécute un agent de codage IA localement et ses performances sont presque deux fois supérieures : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes souhaitant utiliser ce modèle.