Agents IA autonomes (agentic AI) : sécuriser les IA qui agissent, pas seulement celles qui répondent

D’une IA qui répond à une IA qui agit

Les établissements financiers se sont d’abord familiarisés avec des assistants conversationnels : copilotes bureautiques, outils de synthèse, assistants documentaires. Ces systèmes produisent du texte. Leur risque principal reste celui d’une réponse inexacte, d’une fuite d’information ou d’une manipulation par injection de requête.

Une seconde vague est en cours : celle des agents IA autonomes. Ces systèmes ne se contentent plus de répondre. Ils planifient, enchaînent des étapes, utilisent des outils, interrogent des API, écrivent et exécutent du code, déclenchent des opérations et, parfois, délèguent des tâches à d’autres agents. Ils disposent également d’une mémoire persistante leur permettant de conserver un contexte entre les exécutions.

Ce changement de nature déplace le problème de sécurité. Avec un assistant, une manipulation réussie produit une mauvaise réponse. Avec un agent, elle peut produire une mauvaise action : une requête exécutée, une donnée modifiée, un paiement initié, un accès accordé. Cet article propose une cartographie des risques propres aux agents autonomes en environnement financier, puis des principes de sécurité à intégrer dès la conception. Il complète l’article consacré aux assistants IA internes, en traitant cette fois les IA qui agissent.

Un référentiel de référence désormais disponible

Le sujet n’est plus émergent au point de manquer de repères. L’OWASP a lancé fin 2024 son Agentic Security Initiative (ASI), au sein du GenAI Security Project, pour traiter spécifiquement la sécurité des systèmes autonomes. Cette initiative a produit une taxonomie de menaces (Agentic AI – Threats and Mitigations, publiée en février 2025), puis, en décembre 2025, l’OWASP Top 10 for Agentic Applications 2026, un cadre relu par des pairs identifiant dix risques critiques (ASI01 à ASI10), élaboré avec plus d’une centaine de contributeurs et évalué par un comité d’experts comprenant notamment des représentants du NIST, de l’Alan Turing Institute et d’équipes de red teaming IA.

Ce cadre marque une distinction importante. Le Top 10 pour les applications LLM traite des vulnérabilités au niveau du modèle : injection de requête, empoisonnement des données d’entraînement, mauvaise gestion des sorties. Les systèmes agentiques héritent de ces risques et en ajoutent d’autres, propres à l’autonomie, à l’usage d’outils, à la coordination entre agents et à la persistance de l’état. La taxonomie OWASP structure d’ailleurs ces menaces selon plusieurs dimensions : conception de l’agent, mémoire, planification et autonomie, usage d’outils, déploiement et exploitation.

D’autres travaux complètent ce socle : le cadre de gestion des risques liés à l’IA du NIST (AI Risk Management Framework, et son profil dédié à l’IA générative) pour la gouvernance, ainsi que les guides OWASP consacrés à la sécurisation des serveurs Model Context Protocol (MCP), devenus un point de connexion courant entre agents et systèmes externes.

Les risques propres aux agents autonomes

Les dix risques identifiés par l’OWASP couvrent le détournement d’objectif, l’abus d’outils, l’abus d’identité et de privilèges, les vulnérabilités de chaîne d’approvisionnement, l’exécution de code inattendue, l’empoisonnement de mémoire, les communications inter-agents non sécurisées, les défaillances en cascade, l’exploitation de la confiance entre humain et agent, et les agents devenus incontrôlés. On peut les regrouper en quelques familles directement parlantes pour un établissement financier.

Le détournement d’objectif. Les objectifs et la logique de décision d’un agent peuvent être silencieusement réorientés par une injection de requête, un contenu empoisonné, un courriel malveillant ou un document piégé. C’est la version agentique de l’injection indirecte : l’agent lit un contenu, y trouve des instructions, et les exécute. Un agent qui traite des courriels, des tickets ou des documents fournisseurs est exposé par construction, puisqu’il ne distingue pas de façon fiable une instruction légitime d’une instruction insérée dans les données qu’il traite.

L’abus d’outils et l’exécution de code. Un agent tire sa puissance de ses outils : requêtes de base de données, appels d’API, envoi de messages, exécution de scripts. Ce sont aussi ses vecteurs d’abus. Un agent manipulé peut employer un outil légitime à des fins illégitimes, ou exécuter du code non prévu.

L’abus d’identité et de privilèges. C’est le prolongement direct du problème des identités machine. Un agent dispose d’identifiants et de droits ; s’ils sont excessifs, l’impact d’une manipulation l’est aussi. Le Top 10 pour les applications LLM désignait déjà ce risque sous le terme d’« agence excessive » (excessive agency), causée par un excès de fonctionnalités, de permissions ou d’autonomie.

L’empoisonnement de mémoire. La mémoire persistante est ce qui distingue un agent d’un assistant sans état. Elle est aussi une surface d’attaque : un contenu malveillant inséré dans la mémoire peut influencer durablement les décisions futures de l’agent, bien après l’interaction initiale.

Les chaînes d’agents et les défaillances en cascade. Lorsque plusieurs agents se délèguent des tâches, une erreur ou une compromission peut se propager. Des communications inter-agents non authentifiées aggravent le phénomène, et une défaillance locale peut se transformer en défaillance systémique du dispositif.

La confiance humain-agent et les agents incontrôlés. Les utilisateurs tendent à accorder à un agent une confiance excessive, notamment lorsqu’il présente ses actions de façon assurée. À l’inverse, un agent peut dériver de sa tâche, sonder, escalader ou agir hors de son périmètre — un comportement observable même lorsque l’architecture de l’agent échappe à l’organisation qui en subit les effets.

Pourquoi l’enjeu est particulièrement fort dans la finance

Ces risques prennent un relief particulier dans les banques et les assurances, pour trois raisons.

D’abord, la nature des actions. Un agent connecté à des systèmes financiers peut potentiellement consulter des données clients, modifier des enregistrements, initier ou valider des opérations, accorder des accès. Les conséquences d’une action erronée ou détournée ne sont pas seulement informationnelles ; elles sont financières, réglementaires et parfois irréversibles.

Ensuite, l’exposition aux contenus externes. Les processus financiers reposent largement sur le traitement de documents et de messages provenant de l’extérieur : courriels, pièces justificatives, formulaires, échanges avec des prestataires. Ce sont autant de vecteurs d’injection indirecte pour un agent qui les traite automatiquement.

Enfin, la dimension réglementaire. Les exigences de traçabilité, de contrôle des accès, de gestion du risque et de supervision — portées notamment par DORA — s’appliquent aux processus soutenus par des agents comme aux autres. Un agent dont les actions ne sont pas journalisées, dont les droits ne sont pas maîtrisés ou dont les décisions ne sont pas explicables constitue un point faible autant opérationnel que documentaire.

Principe 1 : périmètre d’action limité et moindre privilège

Le premier principe consiste à traiter l’agent comme une identité à part entière, dotée de privilèges strictement délimités. Cela suppose de définir explicitement ce que l’agent peut faire — quels outils, quelles données, quels systèmes, quelles opérations — et de refuser tout le reste par défaut.

Concrètement, il s’agit d’appliquer aux agents les contrôles d’accès granulaires déjà attendus pour les identités machine : périmètre limité, droits minimaux, identifiants dédiés, absence de comptes partagés, et distinction claire entre lecture et action. Un agent qui ne peut techniquement pas déclencher un virement ne pourra pas être manipulé pour le faire.

Principe 2 : validation humaine des actions sensibles

Toutes les actions ne se valent pas. Les actions à fort impact — mouvements de fonds, modifications de données critiques, attribution d’accès, communications externes engageantes, suppressions — doivent rester soumises à une validation humaine explicite.

Cette supervision ne doit pas être une formalité. Pour être efficace, elle suppose que l’humain dispose d’une information suffisante pour décider : quelle action, sur quel système, avec quel effet, sur la base de quelles données. À défaut, la validation devient un clic automatique, et le contrôle perd sa valeur — un phénomène que l’exploitation de la confiance humain-agent illustre précisément.

Principe 3 : isolation, bac à sable et garde-fous

L’exécution de code et l’usage d’outils doivent être isolés. Le confinement (sandboxing) de toute exécution de code, la séparation des environnements et la limitation des accès réseau réduisent l’impact d’une action détournée.

Des garde-fous d’exécution complètent le dispositif : limites de volume et de fréquence d’actions, plafonds sur les opérations sensibles, listes d’outils autorisés, validation des entrées et des sorties, et mécanismes d’interruption. Dans les architectures multi-agents, des disjoncteurs (circuit breakers) permettent d’arrêter une chaîne avant qu’une défaillance ne se propage.

Principe 4 : maîtriser la mémoire et les sources de contexte

Puisque la mémoire persistante peut être empoisonnée, elle doit être traitée comme une donnée sensible : contrôle de ce qui y entre, séparation entre mémoire de travail et mémoire durable, possibilité de purge, et traçabilité des éléments qui ont influencé une décision.

Le même raisonnement s’applique aux sources de contexte. Un contenu externe traité par un agent doit être considéré comme non fiable par défaut. La distinction entre instructions (venant de l’organisation) et données (venant de l’extérieur) doit être portée par l’architecture, et non laissée à l’appréciation du modèle.

Principe 5 : authentifier les agents et sécuriser leurs échanges

Dans une architecture multi-agents ou connectée à des services externes, les échanges doivent être authentifiés et protégés. Cela vaut pour les communications entre agents comme pour les connexions aux outils et serveurs externes, notamment via le Model Context Protocol, dont la sécurisation fait l’objet de guides dédiés.

L’enjeu est double : empêcher qu’un agent malveillant ou usurpé s’insère dans une chaîne, et éviter qu’un serveur d’outils compromis n’injecte des instructions ou n’exfiltre des données. La chaîne d’approvisionnement des agents — modèles, outils, connecteurs, bibliothèques — doit être inventoriée et évaluée comme n’importe quelle dépendance logicielle.

Principe 6 : journalisation, supervision et détection de dérive

Un agent doit être observable. La journalisation doit couvrir non seulement les résultats, mais aussi les décisions : quel objectif, quel raisonnement, quels outils appelés, quelles données consultées, quelles actions effectuées, avec quel résultat.

Cette traçabilité sert la détection autant que la conformité. Le profilage comportemental et la surveillance des activités permettent de repérer des anomalies signalant une manipulation ou une dérive : sollicitation inhabituelle d’outils, tentatives d’accès hors périmètre, volumes anormaux, écart par rapport à la tâche assignée. Ces signaux doivent alimenter le dispositif de supervision au même titre que les autres sources.

Principe 7 : tester avant, et pas seulement après

Les agents doivent être testés avant leur mise en production, avec des méthodes adaptées à leur nature : tests d’injection indirecte via des documents et des contenus piégés, tentatives de détournement d’objectif, essais d’abus d’outils, vérification du respect des périmètres, et exercices de red teaming spécifiques à l’IA.

Ces tests doivent être répétés, car le comportement d’un système agentique est probabiliste et évolue avec ses outils, ses données et ses modèles. Un agent validé une fois n’est pas validé pour toujours.

Gouvernance : intégrer les agents au dispositif existant

Au-delà des contrôles techniques, les agents doivent entrer dans la gouvernance de sécurité et de risque de l’établissement. Le cadre de gestion des risques liés à l’IA du NIST fournit une structure utile pour cela, en articulant gouvernance, cartographie, mesure et gestion des risques.

En pratique, cela suppose plusieurs éléments : un inventaire des agents déployés et de leurs périmètres, un propriétaire identifié pour chacun, une classification selon la criticité des actions permises, un processus de validation avant mise en production, une revue périodique des droits, et une intégration à la gestion des incidents. Un agent doit pouvoir être suspendu rapidement, et ses actions passées reconstituées.

Cette gouvernance rejoint également la question du « shadow AI » : des agents déployés par des équipes métiers en dehors de tout cadre constituent un risque particulier, puisqu’ils combinent autonomie, accès et absence de supervision.

Perspective Forum des Compétences

Le passage des assistants aux agents autonomes n’est pas une évolution incrémentale de la sécurité de l’IA : il change la nature du risque. Une IA qui répond mal produit une erreur ; une IA qui agit mal produit une conséquence. Dans un environnement financier, cette conséquence peut être une opération, un accès ou une donnée modifiée.

La bonne nouvelle est que ce risque n’est pas inédit dans ses principes. Les réponses reprennent des fondamentaux éprouvés : moindre privilège, isolation, validation humaine des actions sensibles, journalisation, authentification des échanges, tests. Ce qui change, c’est le sujet auquel on les applique — un système non déterministe, doté d’une mémoire, capable d’utiliser des outils et d’en déléguer l’usage.

Pour les banques et les assurances, l’enjeu immédiat est de poser ce cadre avant le déploiement, et non après. Un agent doit être conçu avec un périmètre explicite, des droits minimaux, des garde-fous d’exécution et une observabilité complète. La question à se poser pour chaque agent est simple, et devrait précéder toute mise en production : quelle est la pire action que ce système peut déclencher seul, et qu’est-ce qui l’en empêche aujourd’hui ?

Sources publiques utilisées

Cet article s’appuie sur des travaux et référentiels publics reconnus en matière de sécurité des systèmes d’IA agentiques :

• OWASP GenAI Security Project, Agentic Security Initiative (lancée en décembre 2024) : Agentic AI – Threats and Mitigations (février 2025), taxonomie structurée autour de la conception de l’agent, de la mémoire, de la planification et de l’autonomie, de l’usage d’outils et du déploiement.
• OWASP, Top 10 for Agentic Applications 2026 (publié en décembre 2025), cadre relu par des pairs identifiant dix risques critiques (ASI01–ASI10) : détournement d’objectif, abus d’outils, abus d’identité et de privilèges, vulnérabilités de chaîne d’approvisionnement, exécution de code inattendue, empoisonnement de mémoire, communications inter-agents non sécurisées, défaillances en cascade, exploitation de la confiance humain-agent et agents incontrôlés.
• OWASP, Top 10 for LLM Applications, notamment le risque d’« agence excessive » (excessive agency) lié à un excès de fonctionnalités, de permissions ou d’autonomie, ainsi que les guides dédiés à la sécurisation des serveurs Model Context Protocol (MCP).
• NIST, AI Risk Management Framework et son profil relatif à l’IA générative (NIST AI 600-1), pour la structuration de la gouvernance et de la gestion des risques liés à l’IA.
• Règlement (UE) 2022/2554 (DORA), pour les exigences de gestion du risque lié aux technologies de l’information et de la communication, de contrôle des accès et de gestion des incidents applicables aux processus soutenus par des agents.