ISGroup Conseil en Cybersécurité

Sécurité des applications agentiques : LangChain, LlamaIndex, AutoGen et les risques à surveiller

LangChain, LangGraph, LlamaIndex, CrewAI et AutoGen : sécurité des applications agentiques personnalisées

Avec LangChain, LangGraph, LlamaIndex, CrewAI et AutoGen, l’équipe n’utilise pas seulement un assistant de codage : elle construit des applications dans lesquelles un LLM raisonne, récupère du contexte, utilise des outils, appelle des API et coordonne des étapes. La surface de sécurité n’est plus seulement celle d’une application web ou d’un modèle isolé, mais comprend le runtime agentique, les outils, la mémoire, la récupération (retrieval) et les autorisations qui les régissent.

La question n’est pas de décider si l’IA est un bon ou un mauvais choix pour le développement. La question est beaucoup plus pratique : comprendre quels contrôles sont nécessaires lorsqu’un résultat généré ou accéléré par l’IA entre dans un produit, un workflow d’entreprise ou un environnement contenant des données réelles. Cet article s’adresse aux fondateurs, CTO, développeurs et équipes IT/sécurité qui construisent des applications agentiques personnalisées et souhaitent savoir où concentrer les contrôles : abus d’outils, empoisonnement RAG, empoisonnement de la mémoire, permissions et sorties non validées.

Pourquoi une application qui fonctionne n’est pas nécessairement sécurisée

Les outils d’IA réduisent le temps nécessaire pour créer du code, des interfaces, des workflows, des tests et des configurations. Cependant, cette vitesse peut comprimer les étapes qui rendent normalement le logiciel fiable : modélisation des menaces (threat modeling), revue de code, gestion des secrets, contrôles des rôles, validation des entrées, vérification des dépendances et tests manuels des chemins critiques.

Une démo fonctionne avec un seul utilisateur, des données fictives et des permissions implicites. La même logique peut échouer lorsque des clients réels, des locataires (tenants) multiples, des rôles différents, des API publiques, des intégrations, des données personnelles, des paiements ou des automatisations avec des effets externes entrent en jeu. C’est pourquoi la sécurité doit être évaluée sur le comportement réel de l’application, et non sur la promesse de l’outil qui l’a générée.

Appel d’outils (Tool calling) et permissions excessives

Chaque outil accordé à l’agent est une permission applicative à part entière. La lecture, l’écriture, les e-mails, les tickets, les bases de données, le shell ou le CRM doivent avoir une portée minimale, une politique externe au modèle, des journaux d’audit et une confirmation explicite pour les actions sensibles. Déléguer la gestion des permissions au prompt est l’une des erreurs les plus courantes et les plus dangereuses dans les applications agentiques : les règles critiques doivent résider dans le code, les politiques et les contrôles côté serveur, et non dans le system prompt.

RAG, mémoire et contexte non fiable

Les documents, tickets, pages web, e-mails et bases de connaissances peuvent contenir des instructions hostiles. La récupération (retrieval) doit filtrer selon les autorisations, et le contenu récupéré ne doit pas pouvoir outrepasser les politiques système ou les permissions de l’utilisateur. Le risque d’empoisonnement RAG et d’empoisonnement de la mémoire entre les sessions ou les locataires est concret et souvent sous-estimé : un document malveillant inséré dans la base de connaissances peut altérer le comportement de l’agent de manière indétectable sans tests spécifiques.

Gestion des sorties et décisions automatisées

La sortie du modèle ne doit pas être utilisée directement pour générer du HTML, construire des requêtes, exécuter des commandes, appeler des API, gérer des autorisations ou prendre des décisions irréversibles. Une validation structurée, des schémas, des listes blanches (allowlists), des bacs à sable (sandboxes) et des tests avec des entrées malveillantes sont nécessaires avant que toute sortie n’atteigne un système réel.

Risques principaux à contrôler

Les risques suivants ne sont pas théoriques : ils concernent le comportement concret de l’application sur des données réelles, et doivent être vérifiés sur la base de preuves, de la configuration, du comportement au moment de l’exécution et de l’impact réel.

  • Injection de prompt directe et indirecte : instructions hostiles injectées dans le prompt ou dans les documents récupérés par le système.
  • Abus d’outils avec permissions excessives : agents capables d’exécuter des actions non autorisées car les outils n’ont pas une portée limitée.
  • Empoisonnement RAG et documents hostiles : contenus malveillants dans la base de connaissances qui altèrent le comportement de l’agent.
  • Empoisonnement de la mémoire entre sessions ou locataires : contamination de la mémoire persistante qui influence les sessions ultérieures ou d’autres utilisateurs.
  • Divulgation d’informations sensibles : données sensibles exposées via des sorties, des journaux ou des réponses du modèle.
  • Sortie non validée vers des API ou des shells : résultats du modèle utilisés directement comme entrée pour des systèmes externes sans assainissement.
  • Autorisations déléguées au prompt : logique de contrôle d’accès confiée au system prompt au lieu de politiques côté serveur.

Ces risques doivent être liés au périmètre concret de l’application. Une application exposée nécessite des tests applicatifs manuels ; une modification critique du code nécessite une revue ; un workflow interne nécessite un contrôle des permissions et des identifiants ; une application agentique nécessite des tests sur les prompts, les outils et les sorties. La combinaison correcte dépend de l’impact réel, et non du nom de l’outil utilisé pour la construire.

Contrôles minimaux avant la mise en production

  • Cartographier les utilisateurs, les rôles, les données réelles, les intégrations, les environnements et les propriétaires du service.
  • Identifier quelles parties ont été générées ou modifiées avec l’IA et qui les a révisées.
  • Vérifier les autorisations côté serveur, l’isolation des locataires et les fonctions administratives.
  • Rechercher des secrets dans le code, les prompts, les journaux, les variables d’environnement, les builds et l’historique du dépôt.
  • Contrôler les dépendances, les licences, les paquets, les modèles, les plugins et les composants générés.
  • Tester les entrées hostiles, la gestion des erreurs, la journalisation, les limites de débit (rate limits) et les chemins non prévus.
  • Séparer les correctifs bloquants, la remédiation planifiée et le risque résiduel accepté.
  • Répéter le test ou le retest après des corrections touchant des flux critiques.

Quand une vérification indépendante est-elle nécessaire ?

Une vérification indépendante est nécessaire lorsque l’application ou le workflow gère des données réelles, des utilisateurs externes, des rôles, des API, des intégrations d’entreprise, des paiements, du stockage, des workflows automatiques ou du code critique généré avec l’IA. Elle est également nécessaire lorsque l’équipe ne peut pas démontrer quelles parties ont été révisées et quels contrôles bloquent les régressions ou les abus.

Pour les applications agentiques, le périmètre conseillé comprend : AI Application Testing, Code Review et Secure Architecture Review. La revue la plus utile n’est pas générique : elle doit produire des conclusions reproductibles, des priorités de remédiation, une indication du risque résiduel et, si nécessaire, un retest après les corrections.

Questions opérationnelles pour les fondateurs, CTO et équipes de sécurité

  • Quelles données réelles entrent dans le système et où sont-elles enregistrées, journalisées ou envoyées ?
  • Quels rôles existent et quelles actions sont bloquées côté serveur, et non seulement dans l’interface ?
  • Quels secrets, jetons, webhooks ou identifiants permettraient d’accéder à des systèmes critiques ?
  • Quelles parties ont été générées ou modifiées par l’IA et lesquelles ont été révisées par une personne compétente ?
  • Quels tests couvrent les abus, les erreurs, les rôles différents et les locataires différents, et pas seulement le chemin nominal ?
  • Quelles preuves peuvent être présentées aux clients, aux audits, aux achats ou à la direction ?

Approfondissements utiles

FAQ

  • Quelle est la différence entre une application LLM et une application agentique ?
  • Une application agentique ne se limite pas à répondre à un prompt : elle récupère du contexte, planifie, utilise des outils, appelle des API ou coordonne des étapes avec des effets externes sur des systèmes réels.
  • Le prompt peut-il être une barrière de sécurité ?
  • Non. Les règles critiques doivent résider dans le code, les politiques, les permissions et les contrôles côté serveur. Le system prompt peut guider le comportement du modèle, mais ce n’est pas un mécanisme de sécurité fiable.
  • Comment tester l’injection de prompt indirecte ?
  • En insérant des instructions hostiles dans des documents, des pages, des tickets ou des enregistrements récupérés par le système et en vérifiant les appels d’outils, les sorties et l’accès aux données dans les réponses de l’agent.
  • Quand l’AI Application Testing est-il nécessaire ?
  • Lorsque l’application intègre des LLM, du RAG, de la mémoire, des appels d’outils, des agents ou des workflows avec des actions sur des systèmes réels, surtout si elle gère des données sensibles ou des utilisateurs externes.
  • Une Code Review est-elle également nécessaire ?
  • Oui. Il faut lire les autorisations, les wrappers d’outils, la validation des sorties, la récupération, la journalisation, la gestion des secrets et les limites opérationnelles : des aspects qu’un test applicatif seul ne couvre pas.

[Callforaction-CR-Footer]

Sources et références

In

, , ,

Leave a Reply

Your email address will not be published. Required fields are marked *