Des agents IA authentifiés peuvent quand même dériver, exposer des données ou subir un empoisonnement de mémoire
En juin, l'agence américaine de cybersécurité CISA a ajouté une faille du logiciel de passerelle pour agents IA LiteLLM à son catalogue des vulnérabilités connues et activement exploitées, après avoir observé des attaques réelles tirant parti du bug. Cette faille permettait d'exécuter des commandes directement sur le serveur hébergeant la passerelle, et pouvait être enchaînée avec une seconde vulnérabilité ne nécessitant aucun identifiant pour être déclenchée. Elle ne constituait qu'un cas parmi sept CVE révélées en un seul mois sur ce même outil, largement adopté par les entreprises comme premier rempart pour sécuriser le déploiement de leurs agents d'intelligence artificielle. Ce constat illustre un problème plus large : les passerelles sont en général le premier dispositif de contrôle mis en place, alors qu'elles reposent sur des couches d'identité et d'attribution qui, dans la plupart des organisations, n'existent tout simplement pas encore.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de VentureBeat AI. Lire l'article original →
Ce décalage a des conséquences concrètes pour les entreprises qui déploient déjà des agents en production. Une passerelle peut authentifier un jeton et valider qu'un appel d'API est techniquement autorisé, sans jamais savoir que la requête provient en réalité d'un agent, qu'elle s'inscrit dans une chaîne d'outils déclenchée par un composant non fiable, ou que l'agent dépasse la tâche pour laquelle il a été délégué. Un agent de rapprochement comptable qui tente de modifier un enregistrement en production illustre le problème : le jeton est valide, l'appel est autorisé, mais l'action contredit l'objet même de la délégation initiale. Limiter les droits d'un agent à ceux de l'humain qu'il représente ne suffit pas davantage, car un plafond de privilèges ne crée pas d'attribution distincte. Vingt agents opérant sous les permissions d'une seule personne ont quand même besoin d'identités propres, de journaux d'audit, de profils de comportement et de mécanismes de révocation individuels. Sans ces fondations, un contrôle coûteux comme la passerelle ne protège en réalité qu'une fraction très limitée du risque réel, laissant les organisations croire à une sécurité qu'elles n'ont pas.
Face à ce constat, une approche baptisée « déploiement conditionné par les dépendances » propose de hiérarchiser les contrôles en six étapes obligatoires plutôt que de partir directement du blocage réseau. Il s'agit d'abord d'établir un inventaire des agents avec un propriétaire nommé pour chacun, puis de leur attribuer une identité distincte incluant le contexte de délégation, des identifiants limités dans le temps et à la tâche assignée, une télémétrie permettant de reconstituer chaque action de bout en bout, une application des règles au moment de l'exécution tenant compte de l'agent, du principal et de la tâche, et enfin des profils comportementaux associés à un mécanisme d'arrêt valable sur l'ensemble des systèmes traversés. Chaque étape dépend du succès de la précédente, même si leur développement peut avancer en parallèle. L'épisode LiteLLM montre ce qui arrive quand l'application des règles est activée en amont de ce contexte d'identité : des entreprises pensent avoir sécurisé leurs agents alors qu'elles n'en ont couvert qu'une infime partie, avec des vulnérabilités critiques qui restent exploitables au cœur même du dispositif censé les protéger.
Les entreprises européennes qui déploient des agents IA via des passerelles comme LiteLLM sont exposées aux mêmes failles et lacunes d'identité décrites, sans qu'aucune régulation ou entité française ne soit concernée.