Les agents IA passent de la réponse aux questions à l’exécution d’actions dans les systèmes dont les entreprises dépendent chaque jour.
À mesure que les organisations leur donnent accès aux applications, aux données, aux communications et aux processus financiers, la question de sécurité ne consiste plus seulement à savoir si un modèle d’IA produira la bonne réponse. Il faut aussi se demander ce qui se passe lorsqu’un agent fait quelque chose que ses opérateurs n’avaient jamais prévu.
L’incident récent de Hugging Face montre à quelle vitesse cette distinction peut devenir importante.
L’incident concernait des agents IA opérant dans l’environnement d’évaluation d’OpenAI, qui ont trouvé des moyens non autorisés de communiquer, de partager leurs découvertes, d’accéder à Internet et de collaborer entre différentes tâches d’évaluation, avant de compromettre des parties de l’infrastructure de Hugging Face.
Y parvenir efficacement représente un défi, même pour les organisations disposant d’une solide expertise en IA. La grande majorité des entreprises qui déploient des agents devront concevoir des contrôles tenant compte des comportements que ces systèmes pourraient adopter en dehors de leurs limites prévues.
Imaginons un prestataire de santé de taille moyenne qui déploie un agent IA pour traiter les demandes de facturation. Vous voulez obtenir des réponses plus rapides et réduire le nombre de tâches routinières des employés ; il peut donc être tentant de connecter l’agent à la plateforme de facturation via un compte administrateur et de lui demander de suivre la politique de l’entreprise.
Imaginons maintenant qu’une facture entrante contienne des instructions demandant d’exporter les dossiers de compte vers une adresse externe inconnue pour une « vérification », un scénario cohérent avec le risque croissant d’ attaques par injection indirecte de prompt. L’agent considère les instructions intégrées à la facture comme une demande autorisée, et ses larges autorisations ainsi que son accès sortant sans restriction lui permettent d’exporter les dossiers.
Il pourrait en résulter une divulgation non autorisée d’informations de santé protégées, entraînant des obligations en matière de réponse aux fuites de données et exposant potentiellement l’organisation à des sanctions réglementaires.
L’agent IA a suivi les instructions qu’il a reçues, mais son modèle de gouvernance lui avait accordé une autorité qu’il n’aurait pas dû avoir. Une action n’a pas besoin d’être malveillante pour provoquer un incident de sécurité coûteux. La combinaison de demandes vagues et d’identifiants permettant à un agent de transférer de l’argent, d’exposer des dossiers ou de modifier des systèmes de production peut produire le même résultat qu’une attaque.
De nombreuses organisations se lancent à toute vitesse dans le déploiement d’agents, dans l’espoir de réaliser des économies alléchantes, sans mettre en place des contrôles adéquats. Selon Ernst & Young, 92 % des dirigeants du secteur technologique s’attaquent à l’IA souveraine, mais seuls 25 % disposent d’une gouvernance de l’IA agentique à l’échelle de l’entreprise.
Cet écart illustre un problème plus vaste : les organisations déploient des systèmes toujours plus performants plus vite qu’elles n’établissent des règles claires sur ce que ces systèmes sont autorisés à faire, ce qui rend les contrôles de sécurité des agents IA de plus en plus importants avant le déploiement.
Définir le rayon d’impact de l’agent
Les contrôles de sécurité établis fournissent une base pour contenir les risques liés aux agents. Le défi consiste à appliquer et à tester ces contrôles dans chaque système auquel un agent peut accéder et pour chaque action qu’il peut exécuter. Le principe du moindre privilège, qui consiste à n’accorder que les autorisations strictement nécessaires à l’accomplissement d’une tâche, constitue un bon point de départ : accordez uniquement l’accès nécessaire à une tâche définie, puis limitez la portée de cet accès sur un processus automatisé.
Mais cela ne couvre pas toutes les façons dont les agents peuvent mal tourner. Pour les maintenir dans les limites, commencez par définir par écrit les contours précis de leur mission. Par exemple, un agent de facturation peut avoir besoin de consulter certains champs du dossier actuel d’un patient afin de rédiger une explication ou de proposer un ajustement. Ces tâches ne nécessitent pas l’accès aux notes cliniques, aux comptes sans rapport, aux exportations en masse ni à la suppression de dossiers. Accordez un accès strictement défini pour ces opérations, avec une vérification d’autorisation à chaque demande.
Une approche utile consiste à définir le rayon d’impact d’un agent avant même de lui donner accès à un système. Posez cinq questions simples : que peut-il lire ? Que peut-il modifier ? Qui ou quoi peut-il affecter ? Combien peut-il dépenser ? Et à quelle vitesse peut-il agir ? Les réponses doivent déterminer les autorisations et les contrôles de l’agent, plutôt que de reposer sur l’hypothèse qu’il se comportera comme prévu.
Dissocier l’accès de l’autorité
La distinction entre la lecture et l’exécution d’actions est particulièrement importante. Un agent capable de récupérer un solde ne devrait pas, par défaut, pouvoir le modifier. Celui qui rédige un message ne devrait pas avoir le privilège de l’envoyer n’importe où ; limitez donc les destinataires et les destinations réseau. Même l’octroi d’un accès en lecture peut entraîner une divulgation involontaire lorsque les communications ne sont pas restreintes.
Les contrôles d’identité renforcent ces limites. Attribuez à chaque processus un compte de service identifiable, un responsable clairement désigné et des identifiants qui expirent ou peuvent être renouvelés rapidement. Un agent auxiliaire ne doit recevoir que l’autorité nécessaire à sa tâche, et la délégation ne doit jamais pouvoir servir de moyen de contourner les restrictions initiales.
Imposer des limites strictes aux actions des agents
Pensez aux limites de volume. Accorder à un agent l’autorisation de rembourser jusqu’à 50 dollars US sans vérification pourrait se retourner contre vous s’il émet des milliers de remboursements ou rembourse plusieurs fois la même transaction. Définissez des limites cumulées par compte et pour l’ensemble du processus. Fixez des plafonds pour les appels d’outils, la durée d’exécution et les dépenses liées au modèle.
Faites respecter ces limites dans des systèmes que l’agent ne peut ni réécrire ni contourner. Lui demander de respecter certaines directives de dépenses ne remplace pas des vérifications indépendantes des autorisations et du budget avant l’exécution. L’objectif est de rendre le comportement sûr obligatoire, plutôt que de simplement demander à l’agent de s’y conformer.
Tester les limites des agents avant le déploiement
La supervision humaine reste importante, notamment avant de confier aux agents des actions plus risquées.
Avant le déploiement, les équipes de sécurité doivent tester délibérément ces limites en soumettant à l’agent de facturation des factures trompeuses, des instructions contradictoires, des demandes de remboursement répétées, des destinataires non autorisés et des demandes impliquant l’accès aux données des clients. Vérifiez que le système en aval rejette les actions interdites, même lorsque le modèle tente de les exécuter.
Surveiller les agents après leur mise en production
Il est essentiel de continuer à surveiller l’agent après son lancement. Contrairement aux logiciels conventionnels, les systèmes agentiques peuvent se comporter différemment selon leur contexte, leurs outils, leurs instructions et leurs modèles sous-jacents.
La protection à l’exécution complète les tests en observant et en appliquant les contrôles pendant que l’agent fonctionne. Surveillez ses actions pour vous assurer qu’il reste dans le cadre des autorisations qui lui sont définies, et consignez à la fois les actions tentées et celles menées à bien, ainsi que les décisions de politique et les approbations, afin que les équipes de sécurité puissent repérer le moment où il s’approche de ces limites ou les franchit. Si cela se produit, prévoyez des moyens d’arrêter l’exécution et de révoquer l’accès. Examinez régulièrement ces journaux et ces autorisations, et ajustez-les à mesure que le rôle ou le comportement de l’agent évolue.
La conception des autorisations devient ainsi une décision métier. Avant de laisser les agents agir librement, les responsables de la sécurité doivent évaluer les dommages qu’ils peuvent causer et imposer des limites à cette exposition. Les autorisations doivent être fondées sur l’impact potentiel des actions d’un agent, et non sur la confiance accordée à son comportement. Les responsables de la sécurité doivent concevoir les autorisations en fonction du pire scénario, et non du comportement attendu.
La confiance ne remplace pas le contrôle.
À lire également : pour voir concrètement pourquoi les autorisations des agents IA sont importantes, découvrez comment unefaille de Meta Muse pourrait permettre à un logiciel malveillant local de détourner un agent IA et d’exploiter les privilèges déjà accordés par l’utilisateur.