«La sécurité a posteriori n’est généralement pas efficace»
Les agents IA ne sont pas de simples chatbots: ils agissent de manière autonome, utilisent des outils et prennent leurs propres décisions. Mais chaque capacité supplémentaire accroît le potentiel de dommages lié aux attaques par prompt injection. Un modèle conceptuel issu de la recherche permet de tracer la limite entre utilité et danger.
Les agents IA sont un sujet en pleine effervescence. Dans le même temps, ils deviennent de plus en plus accessibles aux utilisateurs: avec des applications LLM locales, des navigateurs intégrant l’IA ou des outils de «vibe coding», il est désormais possible de créer et d’utiliser ses propres agents.
Du chatbot à l’agent
Ce qui distingue ces agents IA des chatbots peut se résumer en un mot: agency. Contrairement à un chatbot, qui se contente de répondre à des entrées, un agent interagit activement avec son environnement: il appelle des API, délègue à des sous-agents et choisit lui-même la stratégie de résolution. Plus un agent dispose de capacités, plus son potentiel de nuisance augmente.
Le cas OpenClaw illustre ce risque: cet agent, doté d’un accès complet au système, présentait des vulnérabilités critiques dans 13,4% de ses fonctionnalités selon des chercheurs en sécurité. Une vulnérabilité zero-click dans Claude Desktop (CVSS 10/10) a par ailleurs montré que même des produits commerciaux ne sont pas à l’abri des attaques par prompt injection. Simon Willison décrit le problème central comme une «lethal trifecta». Dès qu’un agent réunit trois conditions – accès à des données sensibles, traitement de contenus non fiables et capacité à communiquer vers l’extérieur – il peut être manipulé pour exfiltrer des informations privées. Les LLM ne sont en effet pas capables d’évaluer de manière fiable l’origine des instructions.
De ce constat découle la «Rule of Two»: un agent ne devrait pas combiner plus de deux de ces trois classes de capacités au cours d’une même session. Tant que seules deux sont réunies, le risque reste maîtrisable.
Le problème est que la puissance des agents repose précisément sur la combinaison des trois. Restreindre ces capacités revient généralement à limiter leur utilité.
Identité et mémoire: des angles morts
Au-delà des capacités, les droits d’accès posent également problème. Les agents personnels héritent souvent des privilèges complets de leur utilisateur, à l’instar d’un stagiaire recevant dès le premier jour un passe-partout. Les clés API statiques aggravent la situation, car elles ne permettent pas un contrôle d’accès contextuel. Les approches modernes d’IAM privilégient au contraire des identifiants temporaires selon le principe du just-in-time.
La mémoire à long terme est également souvent négligée. Elle peut être considérée comme une quasi quatrième classe de capacités, susceptible de contourner la «Rule of Two», car des instructions malveillantes injectées peuvent n’avoir d’effet que lors d’une session ultérieure: une forme de prompt injection différée, inoffensive en apparence au moment de son introduction.
Conclusion: privilégier le pragmatisme aux interdictions
Il n’existe pas de solution universelle. La prompt injection reste un problème fondamental et non résolu des LLM. La «Rule of Two» constitue un complément, et non un substitut, à des principes éprouvés tels que le moindre privilège. En pratique, cela implique une évaluation des risques au cas par cas plutôt que des interdictions générales, des agents différenciés avec des niveaux d’autorisation gradués, et une certaine méfiance face à la promesse qu’un seul agent puisse tout accomplir en toute sécurité. Car dès lors que des outils sont combinés de manière autonome, aucun fournisseur ne peut en garantir pleinement la sécurité.
L’IA agentique est sur toutes les lèvres. Qu’est-ce qui distingue ces systèmes des applications d’IA classiques?
La différence centrale réside précisément dans l’agency. Un agent IA agit de manière autonome: il appelle des API, utilise des outils, délègue des tâches à d’autres agents et prend des décisions. Il planifie, décide et agit en plusieurs étapes et sur plusieurs systèmes, souvent au nom des utilisateurs. Il dispose en outre d’une mémoire qui dépasse une simple session, ce qui lui permet d’apprendre des interactions passées. Tout cela rend ces systèmes bien plus puissants que les applications d'IA traditionnelles, mais aussi plus exposés aux risques.
Quels problèmes de sécurité apparaissent dans ce contexte?
Le Top 10 de l’OWASP pour les applications agentiques couvre une large palette de risques: du Agent Goal Hijack (la manipulation des objectifs de l’agent via des injections de prompt) à l’abus d’outils, en passant par des problèmes d’identité, le memory poisoning ou encore des erreurs en cascade dans des systèmes multi-agents. Un exemple: le Model Context Protocol (MCP), présenté comme un «USB pour l’IA». Mais il permet aussi de combiner des capacités dangereuses dans un seul outil. Un exploit du serveur MCP de GitHub l’a montré: un seul outil pouvait lire des issues publiques, accéder à des dépôts privés et créer des pull requests. Une combinaison idéale pour l’exfiltration de données.
D’où viennent ces problèmes et comment s’en protéger?
Le problème fondamental tient à la «Lethal Trifecta»: dès qu’un agent a accès à des données sensibles, traite des contenus non fiables et communique vers l’extérieur, il peut être détourné à des fins d’exfiltration de données. La difficulté principale est que les LLM ne peuvent pas déterminer de manière fiable l’origine d’une instruction. La «Rule of Two» permet d’interrompre cette chaîne d’attaque. Toutefois, la mémoire à long terme des agents peut contourner cette règle si des instructions malveillantes ne se manifestent que lors de sessions ultérieures. Dans ce cas, la séparation temporelle des capacités ne suffit plus.
Existe-t-il des recommandations de mesures concrètes?
L’OWASP propose des mesures spécifiques pour chaque risque. Un principe clé est celui du «Least Agency», qui va au-delà du «Least Privilege». Il ne s’agit pas seulement de limiter les droits, mais d’éviter toute autonomie inutile. Un comportement agentique superflu augmente la surface d’attaque sans apporter de valeur. Cela implique aussi de revoir les systèmes IAM: ils doivent être capables de délivrer des autorisations temporaires et liées à une tâche, plutôt que de s’appuyer uniquement sur des clés API statiques. Par ailleurs, les cadres réglementaires vont imposer des exigences plus strictes aux systèmes à base d’agents. L’AI Act européen aura ainsi des répercussions sur les entreprises suisses, et une législation spécifique en Suisse est également probable.
Pour conclure, que conseilleriez-vous?
Pas de panique! Les systèmes agentiques sont fondamentalement des systèmes distribués, comparables aux architectures de microservices. Nous savons comment sécuriser ces environnements: grâce à la télémétrie, au contrôle d’accès, au sandboxing et aux modèles Zero Trust. Certains aspects sont spécifiques, comme la gestion de la mémoire ou la communication entre agents, mais des solutions existent déjà, tant en open source que commerciales. L’essentiel est d’intégrer la sécurité dès le départ, même si cela peut sembler difficile dans le contexte actuel. Car, en règle générale, la sécurité a posteriori n’est généralement pas efficace.
