Prompt injection et agents IA : le problème est architectural, ce que CaMeL propose

Il existe une différence subtile, souvent négligée dans les présentations léchées des produits IA, entre un modèle qui répond et un agent qui agit. Le premier traite du texte et renvoie du texte, le second lit le courrier, ouvre des documents, navigue sur des pages web, appelle des API de paiement, écrit du code dans le dépôt de l'entreprise. Ce saut, de « générateur de phrases » à « exécuteur de tâches », est la raison pour laquelle en 2026 la sécurité des agents IA est devenue un sujet de conseil d'administration.

Gartner l'a écrit noir sur blanc le 9 juin dernier, plaçant la prompt injection à la première place des menaces liées à l'IA pour la deuxième année consécutive. Le motif est presque banal à énoncer, complexe à résoudre : les agents multiplient les points où un texte peut se transformer en commande. Un e-mail, un PDF joint, un avis sur un site de voyage, même un fichier README sur GitHub deviennent de potentiels vecteurs d'instructions que l'utilisateur n'a jamais écrites, ni approuvées.

L'idée clé, avant les détails techniques, est la suivante : plus un système d'IA devient opérationnel, plus les mêmes précautions que le logiciel critique applique depuis des décennies sont requises — séparation des privilèges, vérification des entrées, traçabilité des actions. C'est la même leçon que l'informatique a apprise avec les bases de données (l'injection SQL) et avec le web (le cross-site scripting), appliquée à un domaine nouveau où l'attaquant n'écrit pas de code, mais écrit des phrases en langage naturel.

Le risque caché dans les données

La définition technique, selon le Top 10 de l'OWASP pour les applications basées sur les LLM, distingue deux variantes principales. L'injection directe est la tentative explicite, l'utilisateur qui écrit « ignore les instructions précédentes et fais X » : une attaque facile à imaginer, relativement simple à filtrer. L'injection indirecte est plus insidieuse, car le texte malveillant ne vient pas de l'utilisateur, mais d'un contenu externe que l'agent traite dans le cadre normal de son travail — un document partagé, une page web, le champ de notes d'un ticket.

Le point, expliquent les chercheurs de l'article CaMeL que nous analyserons tout à l'heure, est que le problème ne concerne pas seulement le modèle linguistique, il concerne l'ensemble du système qui l'entoure : le contexte qu'il reçoit, les outils auxquels il peut accéder, les permissions avec lesquelles il opère, les outputs qu'il produit. Un modèle, aussi bien aligné soit-il, reçoit en entrée une séquence de tokens indiscernables quant à leur provenance, comme l'a reconstitué ICT Security Magazine en analysant le cas EchoLeak : le modèle se moque de savoir si ce texte provient du prompt système du développeur ou d'un e-mail reçu une heure plus tôt, tout finit dans la même fenêtre de contexte, avec le même niveau de confiance implicite.

Un exemple simple aide à fixer l'idée. Un agent qui doit résumer un e-mail pourrait tomber sur un texte caché, peut-être écrit avec des caractères invisibles ou formaté pour ressembler à une partie du contenu légitime, qui lui ordonne de transférer des informations confidentielles à une adresse externe. L'utilisateur a seulement demandé un résumé, l'agent exécute également la commande cachée, car pour lui il n'existe aucune différence sémantique entre « ce que l'utilisateur veut » et « ce que le document dit de faire ».

Pourquoi les agents changent les règles

Les chatbots traditionnels, ceux qui se limitent à converser, contiennent le dommage potentiel dans les limites de la conversation elle-même : dans le pire des cas, ils renvoient une réponse embarrassante ou fausse. Les agents non. Ils ont accès à des outils réels, souvent avec des privilèges étendus, et cela change la nature du risque, qui passe d'un « mauvais output » à une « action dommageable et irréversible ». IBM le décrit bien : la combinaison entre processus décisionnel automatisé et capacité d'appeler des outils externes crée une surface d'attaque sur deux fronts ; les attaquants peuvent manipuler le comportement de l'agent en l'incitant à un usage abusif des outils, ou frapper directement l'outil avec des vecteurs plus classiques comme l'injection SQL.

À cela s'ajoute un problème d'observabilité. Un modèle linguistique, par sa nature, produit une inférence probabiliste, non un algorithme déterministe et inspectable ligne par ligne. Cela rend imprévisible, du moins en partie, ce que fera l'agent face à une entrée jamais vue auparavant, ce qui complique énormément le travail des équipes qui doivent surveiller et répondre aux incidents.

Le risque croît proportionnellement à trois facteurs qui se combinent, et non individuellement : l'accès à des données privées, l'exposition à des contenus non fiables, et la disponibilité d'un canal vers l'extérieur pour faire sortir des informations. Quand un agent possède les trois ensemble — il lit des données sensibles, traite du texte qu'il ne contrôle pas, peut contacter des systèmes externes — la surface devient structurellement vulnérable, quel que soit le degré de sophistication du prompt système qui lui ordonne de bien se comporter. C'est pourquoi la sécurité doit être conçue comme une architecture de système, et non confiée à un filtre appliqué au prompt.

Le cas le plus cité de 2025 illustre parfaitement cette dynamique. Microsoft a corrigé en silence, lors du Patch Tuesday de juin, une vulnérabilité critique dans Microsoft 365 Copilot, connue sous le nom d'EchoLeak (CVE-2025-32711, score CVSS 9.3), qui permettait l'exfiltration de données sans aucun clic de la part de la victime : il suffisait d'un e-mail formaté avec art, traité des mois plus tard par Copilot lors d'une requête de travail tout à fait ordinaire, pour déclencher la fuite d'informations vers un domaine externe masqué en endpoint de confiance. Aucun malware, aucun lien cliqué, juste du texte interprété de la mauvaise manière.

Ce que CaMeL propose

En juin 2025, un groupe de chercheurs de Google DeepMind et de l'École polytechnique fédérale de Zurich (ETH) a publié un article, intitulé « Defeating Prompt Injections by Design », qui propose une approche différente par rapport aux tentatives précédentes visant à rendre le modèle lui-même plus robuste. CaMeL, acronyme de CApabilities for MachinE Learning, ne modifie pas le modèle, il construit une couche protectrice de système autour de lui, en s'inspirant de concepts déjà éprouvés dans la sécurité informatique traditionnelle, comme l'intégrité du flux de contrôle et le contrôle des accès.

L'intuition de départ reprend une idée proposée en 2023 par le développeur Simon Willison, le pattern « Dual LLM » : un modèle Privilégié, qui ne voit que la requête originale de l'utilisateur et planifie les actions, et un modèle Quarantané, privé de la capacité d'appeler des outils, qui traite les contenus non fiables (e-mails, documents, pages web). L'idée, élégante sur le papier, montre toutefois une limite : même en isolant la planification des données sales, un attaquant peut tout de même manipuler les arguments passés aux outils, détournant le flux de données sans toucher à la séquence des actions planifiées — l'équivalent agentique d'une injection SQL, qui n'altère pas la structure de la requête, mais en corrompt seulement les paramètres.

CaMeL surmonte cette limite en extrayant explicitement, de la requête de l'utilisateur (supposée de confiance), à la fois le flux de contrôle et le flux de données, sous forme de code Python généré par le modèle Privilégié et exécuté par un interpréteur personnalisé. De cette manière, les données récupérées de sources non fiables ne peuvent jamais influencer le chemin logique de l'exécution, seulement leur contenu, et seulement dans les limites imposées par des règles explicites. Image tirée de l'article officiel de CaMeL

Capability, policy, flux contrôlés

Le cœur technique du système repose sur un concept emprunté à la sécurité des systèmes d'exploitation, celui de capability : une étiquette de métadonnées associée à chaque valeur qui traverse le programme, capable d'enregistrer sa provenance et ses destinataires autorisés. Quand l'agent récupère un fichier sur un stockage cloud, ce fichier porte avec lui l'information sur qui l'a partagé et qui peut le lire, un peu comme un colis qui arrive avec son propre bon de livraison joint. Si par la suite le code généré par le modèle tente d'envoyer ce fichier à une adresse e-mail non autorisée, l'interpréteur bloque l'opération avant qu'elle ne soit exécutée, en demandant éventuellement une confirmation explicite à l'utilisateur.

Aux côtés des capabilities opèrent les security policies, des fonctions écrites en Python qui définissent ce qu'il est permis de faire avec certaines données, contrôlées à chaque appel d'un outil. L'article présente un exemple relatif à la création d'événements dans le calendrier : le titre, la description, le lieu et l'heure doivent être lisibles par tous les participants, à moins que ces derniers ne proviennent directement d'une instruction de confiance de l'utilisateur. La granularité est telle qu'elle permet des logiques aussi complexes que nécessaire, évitant à la fois l'excès de restriction (qui dégrade l'utilité de l'agent) et l'excès de permissivité (qui rouvre la porte aux attaques).

Les chiffres de l'évaluation, menée sur le benchmark AgentDojo, sont instructifs. Avec Claude 4 Sonnet et des modèles comparables, CaMeL réduit les attaques réussies pratiquement à zéro, face à des centaines de succès obtenus contre la même suite de modèles utilisés avec les API de tool-calling natives, en payant un coût en termes d'utilité (le pourcentage de tâches légitimes accomplies avec succès) qui varie selon le domaine, marqué surtout dans les tâches les plus ambiguës ou les moins documentées, contenu ailleurs. Le prix de calcul tourne autour d'un facteur 2,8 fois plus de tokens, tant en entrée qu'en sortie, par rapport au tool-calling natif : un coût réel, soutenable selon les auteurs au vu des garanties obtenues.

Note technique : CaMeL aborde également le sujet des side-channels, par exemple la possibilité d'inférer une donnée privée en observant indirectement combien de fois est exécutée une certaine requête conditionnée par sa valeur. Un problème que l'article reconnaît comme non résolu, le comparant aux techniques de return-oriented programming qui échappent encore partiellement au Control Flow Integrity dans les systèmes traditionnels.

Gouvernance : la confiance ne suffit pas

Pour ceux qui s'occupent de conformité, de sécurité en entreprise ou d'administration publique, le discours technique se traduit par une question plus simple : comment rendre un agent non seulement précis, mais aussi contrôlable, vérifiable et auditable. Microsoft, dans son guide architectural pour les agents, identifie trois piliers fondamentaux pour un développement responsable : l'adéquation à l'usage, l'opérabilité fiable dans le temps, et un troisième pilier qui résume l'essence du problème, confiance, traçabilité et transparence, c'est-à-dire la possibilité concrète pour les utilisateurs et les administrateurs de savoir où résident les données, comment elles sont utilisées, et de vérifier la provenance de chaque information affichée par le système.

C'est ici qu'intervient un détail qui rend CaMeL intéressant au-delà du périmètre de la sécurité pure : le graphe des flux de données que l'interpréteur construit pendant l'exécution peut être réutilisé dans l'interface utilisateur pour montrer l'origine d'un contenu, permettant à celui qui lit de s'apercevoir, par exemple, qu'un prétendu message « de Google » provient en réalité d'une source non vérifiée. La traçabilité non pas comme une contrainte bureaucratique, donc, mais comme un outil réel de défense contre le phishing véhiculé par l'agent lui-même.

Le cadre réglementaire évolue rapidement. L'AI Act européen, à l'article 15, impose aux systèmes à haut risque, banques, santé, infrastructures critiques, de démontrer leur robustesse face aux tentatives d'altération par des tiers non autorisés, avec des sanctions pouvant aller jusqu'à 7 % du chiffre d'affaires mondial, entrée en vigueur en août 2026. En Italie s'ajoutent la NIS2, en vigueur depuis janvier, et les lignes directrices de l'ACN de février, avec une évaluation spécifique sur la prompt injection pour la fonction publique : trois régimes superposés, qui transforment chaque incident en problème juridique avant même d'être technique. Image tirée de l'article officiel de CaMeL

Où cela fonctionne et où non

Les points forts de CaMeL, relus à la lumière des données de l'article, sont concrets : il réduit drastiquement la confiance aveugle accordée au texte externe, introduit une barrière architecturale vérifiable au lieu d'une énième instruction dans le prompt, aborde le problème à la racine au lieu de filtrer les symptômes. Dans la comparaison avec d'autres défenses disponibles dans AgentDojo, tool filter, spotlighting, prompt sandwiching, CaMeL réduit presque à néant les attaques réussies, tandis que les alternatives en laissent passer de cinq à vingt-quatre sur 949 tentatives testées.

Les limites, tout aussi concrètes, méritent le même poids. Le coût d'implémentation est élevé : construire un système basé sur des capabilities nécessite un changement de paradigme, pas un simple plugin à installer, et ne fonctionne bien que si l'ensemble de l'écosystème d'outils collabore, une contrainte qui se complique dès que l'agent doit interagir avec des services tiers hors du contrôle direct des développeurs. Il existe de plus le risque, bien connu de ceux qui travaillent avec des systèmes de permissions granulaires, de la « fatigue de l'autorisation » : si les demandes de confirmation se multiplient, l'utilisateur risque d'approuver mécaniquement des actions même dangereuses, annulant une partie du bénéfice.

Les auteurs eux-mêmes sont explicites sur un point qui mérite d'être répété sans détour : la prompt injection n'est pas « résolue ». CaMeL ne protège pas, de l'aveu même des auteurs, contre les attaques qui altèrent uniquement le texte affiché à l'utilisateur sans toucher au flux de données — comme un résumé biaisé d'un e-mail qui ne provoque pas d'exfiltration —, ni contre le phishing induit lorsqu'il reste confiné au niveau du langage. Reste par ailleurs ouvert le front des side-channels, des canaux latéraux difficiles à fermer complètement, même dans les logiciels traditionnels.

L'état de l'art en 2026

Le cas CaMeL s'inscrit dans un paysage d'incidents réels qui en confirment l'urgence. Outre EchoLeak, 2025 a vu une vulnérabilité de remote code execution dans GitHub Copilot et Visual Studio Code (CVE-2025-53773), capable de se propager entre dépôts comme un ver en exploitant des fichiers README apparemment inoffensifs, et une attaque sur ServiceNow Now Assist où un utilisateur à faibles privilèges incitait, via un champ de ticket, un agent à privilèges plus élevés à effectuer des actions non autorisées, exploitant la confiance implicite entre agents d'une même plateforme.

Le cas le plus grave, reconstitué par Anthropic dans un rapport public et repris par la presse spécialisée, décrit une campagne d'espionnage attribuée à un groupe parrainé par un État, qui a compromis un système agentique en décomposant l'attaque en une séquence de requêtes petites et apparemment légitimes, convainquant le modèle qu'il exécutait un penetration test autorisé. Une anecdote qui rappelle de près la logique du « snow crash » imaginé par Neal Stephenson dans son roman de 1992, un virus qui se propage en exploitant non pas un bug dans le code, mais la propension du système à exécuter aveuglément ce qui lui est présenté.

L'OWASP, dans sa révision dédiée aux applications agentiques de décembre 2025, a ajouté des sous-catégories spécifiques, telles que l'injection par abus d'outils et l'injection persistante dans la mémoire de l'agent : des catégories impensables à l'époque des chatbots isolés, centrales désormais à l'heure où le LLM sert d'orchestrateur de systèmes interconnectés. Cisco estime que 83 % des organisations prévoient d'adopter des systèmes agentiques, tandis que seulement 29 % se déclarent prêtes à les protéger convenablement, un écart qui rappelle, pour ceux qui sont familiers avec certains jeux de survival horror, la sensation d'avancer dans un couloir sombre avec plus de munitions que de serrures.

Construire l'environnement, pas seulement le modèle

Le problème, résumé sans jargon, n'est pas de « défendre le prompt », c'est de concevoir des systèmes capables de distinguer clairement instructions, données et actions, un peu comme un bon jeu de vérification bureaucratique apprend à distinguer le document authentique du document contrefait, en ne se fiant jamais aux apparences de surface. CaMeL, avec toutes ses limites déclarées, reste utile comme cas d'étude précisément parce qu'il indique une direction plus mûre pour le secteur, une sécurité intégrée dès la conception du système, non déléguée à l'espoir que le modèle se comporte bien.

Pour le public qui n'implémente pas directement ces systèmes, mais les adopte, les finance ou les régule, la traduction pratique est celle-ci : il ne suffit pas d'apprendre au modèle à bien se comporter, il faut construire l'environnement dans lequel il opère, avec des privilèges minimaux, une traçabilité complète, et une confirmation humaine pour les actions irréversibles. Une leçon aussi vieille que l'informatique elle-même, redécouverte chaque fois qu'une nouvelle technologie promet de tout simplifier, et finit par proposer les mêmes problèmes avec un vocabulaire différent.