Technologies

Injection de prompt, manipulations... : IA agentique, le grand détournement des SI ?

---

Le développement d'agents, appelés à agir au coeur des SI, confronte la DSI à toute une série de nouveaux risques. Sur lesquels mieux vaudrait ne pas fermer les yeux.

PublicitéDéployer rapidement les agents IA pour ne pas rater un virage que beaucoup perçoivent comme essentiel. Si le salon Devoxx, qui se tenait du 22 au 24 avril à Paris, a mis en lumière la volonté des entreprises d'exploiter rapidement l'IA agentique, il n'en a pas occulté les risques, réputationnels et financiers notamment. Au sein de l'événement, plusieurs conférences ont souligné ces chausse-trappes. Certes, le sujet n'a rien d'inédit pour les RSSI et experts de la sécurité (la communauté Open Worldwide Application Security Project, ou OWASP, publiant le top 10 des vulnérabilités des LLM depuis 2023 et, depuis plus récemment, celui des applications agentiques), mais il doit être mieux appréhendé par les développeurs eux-mêmes.

« Toutes les entreprises veulent aller vite, mais oublient parfois les règles de base en matière de sécurité », souligne Philippe Laumay, à la tête de la stratégie technologique pour la plateforme SaaS dédiée aux assureurs de Moody's. La société de 14 000 personnes, à la fois éditeur de logiciels et agence de notation, a conçu une matrice des risques, inspirée des top 10 de l'OWASP et associée à 11 points de contrôle, par laquelle passe tout nouvel applicatif embarquant de l'IA. « Un dispositif implémenté dans un bon vieux tableau Excel », s'amuse Philippe Laumay.

« Selon l'OWASP, la première attaque sur les IA reste l'injection de prompt directe », indique Houssem Belhadj Ahmed, architecte sécurité chez Bpifrance, qui pointait les failles des IA lors d'une démo co-organisée avec Thales et reposant sur un agent bancaire fictif censé accompagner les clients dans leurs opérations. « Dans ce schéma, l'objectif des assaillants consiste souvent à récupérer le prompt système, renfermant le contexte d'utilisation de l'agent, les règles métiers, les outils auxquels il a accès, voire les informations d'identification », ajoute-t-il. Si le déploiement de garde-fous, en entrée et en sortie du modèle, permet de filtrer les prompts et les résultats, évitant dans la plupart des cas ces scénarios, l'attaque peut gagner en sophistication en ciblant non pas le LLM lui-même, mais une base de données à laquelle l'agent a accès. On parle alors d'injection de prompt indirecte. Par exemple, pour un chatbot bancaire, il peut s'agit d'un motif de virement renfermant une injection de prompt activée dès que le client demande la liste des dernières transactions. « La parade consiste à déployer des garde-fous sur ce qui est envoyé par le ou les serveurs MCP ou par d'autres agents... ou garder un humain dans la boucle », note Aymeric Lagier, architecte sécurité au sein de Thales Cyber Solutions.

PublicitéTromper l'agent avec un programme de fidélité fictif

Comme le souligne Philippe Laumay, qui, pour appuyer son propos, avait conçu une démo d'un assistant de réservation d'hôtel ayant accès à 7 systèmes différents, l'injection de prompt a souvent recours à la technique du jeu de rôle (ou role-play), consistant pour l'assaillant à se glisser dans la peau d'un personnage pour tromper le LLM. Par exemple, à se faire passer pour un auditeur de Bureau Veritas ou d'un autre cabinet, mandaté par l'entreprise, afin de récupérer la liste des outils auxquels l'agent a accès et, ensuite, l'ensemble des réservations. « Mais l'attaque peut aussi consister à inventer une fonction qui n'existe pas, par exemple un programme de fidélité », souligne le responsable de Moody 's. Une attaque appelée Excessive Agency qui permet, dans le cas de la démo, de manipuler l'agent pour avoir accès à des tarifs très bas.

Les attaques contre l'IA agentique peuvent aussi viser la manipulation du workflow dans sa globalité, thématique qui apparait par deux fois dans le top 10 de l'OWASP. « Par exemple, imaginons une offre de crédit associée à une réponse immédiate via un workflow agentique. Dans ce schéma, un agent orchestrateur va en solliciter un d'éligibilité avant de solliciter celui d'approbation. Par une injection de prompt, demandant à shunter l'étape de conformité, il est possible de court-circuiter le premier agent », illustre Houssem Belhadj Ahmed. Donc de bénéficier d'un prêt alors que votre situation financière ne le permet pas. Là encore, des garde-fous classiques bloqueront la plupart des attaques. « Mais ils peuvent être eux-mêmes être bypassés », avertit l'architecte, qui pointe l'intérêt des solutions reposant sur un LLM placé en contrôle (on parle de LLM-as-a-judge), afin de classifier les entrées des utilisateurs, et des approches zero trust entre agents. « Dans ce schéma, les agents ne se font pas confiance entre eux et utilisent des mécanismes classiques d'authentification, de chiffrement ou de vérification des tokens avant toute opération », résume l'expert de Bpifrance.

Des nouveaux composants dans le SI

Par ailleurs, l'objectif des assaillants n'est pas forcément d'outrepasser leurs droits ou de récupérer de l'information. Ils peuvent se contenter de vous faire dépenser beaucoup de jetons. Donc beaucoup d'argent. « Par exemple, via un prompt déclenchant une boucle infinie », souligne Houssem Belhadj Ahmed. Là encore, dans le contexte d'un chatbot bancaire, une telle attaque peut passer par le libellé d'un virement contenant une instruction. Si ce type de comportement est assez facile à parer - via une limitation du nombre de transactions similaires ou du budget alloué à l'application -, encore faut-il y avoir pensé avant que la facture ne vous parvienne.

Enfin, la construction de ces systèmes agentiques suppose l'introduction de nouveaux composants au sein des systèmes d'information. Des composants aux comportements non déterministes pour certains. Par exemple, l'agent bancaire fictif imaginé par Bpifrance et Thales utilise le modèle Qwen 2.5, mais, pour qu'il fournisse des suggestions de placement financier, les équipes de développement ont eu recours à un adaptateur LoRA (technique permettant de spécialiser rapidement les modèles sur de nouveaux contextes) pour améliorer les résultats. Des composants que les entreprises récupèrent souvent sur la marketplace Hugging Face. « Attention, les descriptifs de modèles (model card) y sont purement déclaratifs », souligne Aymeric Lagier, de Thales. Et d'appeler les équipes de développement à rester vigilantes quant aux biais, backdoors ou tentatives d'empoisonnement que peuvent renfermer ces composants librement disponibles. Mieux vaut donc systématiquement tester modèles et adaptateurs avec un outil de tests dynamiques ou avec un autre LLM (toujours selon le principe du LLM as-a-judge).

Ne pas négliger les bons vieux principes cybersécurité

Comme le note toutefois Loïc Gudet, responsable des projets d'innovation de Moody's, l'approche LLM-as-a-judge n'est pas magique. Et suppose aussi quelques compromis. « Certes, elle permet de détecter les attaques ayant recours à de la nuance, indique-t-il. Mais il s'agit encore d'une technologie non déterministe et elle va induire des coûts et un temps de latence supplémentaire. Par ailleurs, ce LLM représente lui aussi une nouvelle surface d'attaque. » Une façon aussi de prévenir contre la tentation de certains développeurs d'empiler les LLM pour tenter de limiter les risques. L'alternative ? Des règles reposant sur du code standard. Une approche rapide et robuste, mais qui, évidemment, sera limitée à une liste de cas définis à l'avance.

Pour Loïc Gudet, au-delà de la protection contre telle ou telle attaque, la sécurité de l'IA agentique commence par l'application des bons vieux principes de la cyber. « D'abord, il faut sécuriser tout le reste, cloisonner soigneusement le périmètre et les applications, avec des listes blanches d'outils, des schémas d'appels contraints et une approche consistant à considérer par défaut toutes les entrées comme hostiles. » Ce qui signifie en limiter la taille, les normaliser et rejeter les images, par exemple. L'expert de Moody's pointe également les risques associés aux systèmes de RAG, en particulier quand ils font appel à une recherche sur Internet. « Par défaut, mieux vaut considérer qu'aucune sortie de ces systèmes n'est fiable, en particulier quand il s'agit de code informatique », avertit Loïc Gudet, qui conseille d'exécuter systématiquement tout code dans des bacs à sable. Enfin, dans les outils eux-mêmes, les principes de moindre privilège et de séparation des droits de lecture de ceux d'écriture doivent être strictement respectés.

Article rédigé par

Reynald Fléchaux, Rédacteur en chef CIO
Suivez l'auteur sur Twitter

Partager cet article