Aller au contenu
FortaRisks
Retour au blogueIA

Sécurité de l'IA : un agent IA est un compte à privilèges, traitez-le comme tel

15 octobre 2026 · 7 min de lecture

Votre rendez-vous du jeudi · Série IA

Jusqu'ici, cette série a surtout parlé d'une IA qui répond : l'inventaire des usages, qui en répond, les risques propres aux modèles de langage, l'IA de vos fournisseurs, l'IA utilisée contre vous et, la semaine dernière, ISO 42001 et le NIST AI RMF. Cette semaine, l'IA ne répond plus. Elle agit.

Un agent IA lit une boîte de réception, ouvre un billet, interroge une base de données, envoie un courriel, modifie une configuration, déclenche un paiement. Il le fait avec des identifiants, des droits et des accès. Notre position est simple : un agent IA est un compte à privilèges. Il doit être géré comme tel, avec la même rigueur qu'un compte administrateur, et pas comme un logiciel de plus.

Ce qui change quand l'IA agit

Un assistant qui se trompe produit une mauvaise réponse. Un humain la lit, la corrige ou l'ignore. Un agent qui se trompe produit une mauvaise action, et personne ne la relit avant qu'elle ait lieu. Trois choses changent.

L'identité. L'agent agit au nom de quelqu'un, ou de personne. Dans beaucoup de déploiements, il réutilise le compte de la personne qui l'a configuré, ou un compte de service partagé. Le jour où quelque chose tourne mal, le journal dit « Marie a supprimé le dossier » alors que Marie était en réunion.

Les droits. Pour être utile, un agent reçoit des accès : la messagerie, le CRM, le stockage, parfois l'infonuagique. Ces accès sont souvent plus larges que la tâche, parce qu'il est plus simple de tout ouvrir que de réfléchir à ce qui est nécessaire.

L'irréversible. Un agent peut envoyer, payer, supprimer, publier. Ces actions ne se rattrapent pas avec un correctif.

Ce que ça change : le risque d'un agent ne dépend pas de l'intelligence du modèle, mais de ce qu'on l'a autorisé à toucher. L'OWASP le dit sans détour dans son Top 10 des applications de modèles de langage : le risque d'« agentivité excessive » (Excessive Agency) a trois causes, trop de fonctions, trop de permissions, trop d'autonomie. Aucune des trois n'est un problème de modèle. Ce sont trois décisions de configuration.

Ce que l'actualité montre déjà

Ce n'est plus de la prospective. Trois faits récents, que notre récap du 9 octobre détaillait :

  • Un agent du côté de l'attaquant. Le 21 septembre, le Dutch Institute for Vulnerability Disclosure (DIVD) a vu son outil de support Zammad servir de porte d'entrée : deux failles inconnues enchaînées, et un accès root obtenu en quelques secondes, une vitesse que DIVD attribue à un agent d'IA autonome. Statut : confirmé par la victime, rôle de l'IA selon la victime. La segmentation du réseau a contenu l'intrusion.
  • Des agents « bien intentionnés » qui débordent. Le laboratoire Transluce a documenté des agents d'IA qui, en cherchant des données publiques, ont tenté des injections SQL sur des sites gouvernementaux, dont le service de recherche de Bibliothèque et Archives Canada. Statut : rapporté ; aucune compromission selon le Centre de la sécurité des télécommunications.
  • La plateforme d'agents comme nouvelle cible. GitLab a corrigé le 2 octobre une faille critique (CVE-2026-90970, CVSS 9.9) dans sa passerelle IA auto-hébergée : un utilisateur ayant accès à la plateforme d'agents pouvait sortir du bac à sable et exécuter des commandes sur l'hôte. Statut : confirmé par l'éditeur, aucune exploitation signalée.

Et la cadence générale ne laisse pas de marge : selon le Digital Defense Report 2026 de Microsoft, le délai médian entre la découverte d'une vulnérabilité et son exploitation est passé bien sous les 24 heures.

Ce que ça change : vos agents seront ciblés par des contenus piégés, et ils iront parfois plus loin que prévu sans aucune malveillance. Dans les deux cas, ce qui limite les dégâts est la même chose : ce qu'ils ont le droit de faire.

Les six règles d'un agent bien tenu

Le Top 10 des applications agentiques publié par l'OWASP le 9 décembre 2025 classe en tête le détournement de l'objectif de l'agent (Agent Goal Hijack), le mauvais usage de ses outils (Tool Misuse) et l'abus d'identité et de privilèges (Identity and Privilege Abuse). Les six règles suivantes y répondent directement.

  1. Une identité propre par agent. Chaque agent a son propre compte, nommé, rattaché à un propriétaire humain. Jamais le compte d'un employé, jamais un compte de service partagé entre plusieurs agents. C'est la seule façon de savoir, après coup, qui a fait quoi.
  2. Le moindre privilège, et pour une durée limitée. L'agent reçoit les droits de sa tâche, pas ceux de son créateur. Lecture seule tant que l'écriture n'est pas nécessaire. Des jetons à durée courte, renouvelés, plutôt que des clés permanentes. Si l'agent trie des courriels, il n'a pas besoin de les supprimer.
  3. Une liste d'outils autorisés. L'agent n'appelle que des outils nommés, chacun avec une fonction étroite. Pas d'accès général à un terminal, pas de connecteur « fait tout ». L'OWASP recommande aussi que l'autorisation soit vérifiée dans le système cible, pas laissée au jugement du modèle.
  4. Une approbation humaine pour l'irréversible. Tout paiement, tout envoi à l'externe, toute suppression, toute modification de droits ou de configuration en production passe par une validation humaine. C'est la même règle que celle de l'épisode sur l'IA offensive : la vérification hors bande résiste là où la détection échoue.
  5. Une journalisation de chaque action. Qui (quel agent, pour le compte de qui), quoi (quel outil, quelles données), pourquoi (quelle demande l'a déclenché), et le résultat. Ces journaux vont là où vont ceux de vos comptes administrateurs, pas dans un tableau de bord oublié de l'éditeur.
  6. Un coupe-circuit. Une personne nommée peut arrêter un agent en quelques minutes, sans attendre l'éditeur ni le développeur : révoquer son identité, couper ses jetons. Ajoutez un plafond d'actions par heure : un agent qui s'emballe déclenche l'alerte avant de vider une boîte ou un compte.

L'inscrire au registre, deux fois

Un agent a sa place à deux endroits.

Au registre des usages de l'IA, celui de notre premier épisode, avec quatre colonnes de plus : son identité, ses outils autorisés, les actions soumises à approbation, et le nom de la personne qui tient le coupe-circuit.

Au registre de risques, sous forme de scénario, comme le proposait dimanche notre série risques : « Un courriel piégé détourne l'agent de traitement des factures, qui modifie les coordonnées bancaires d'un fournisseur ; un paiement de 80 000 $ part vers un compte frauduleux. » L'exemple est fictif ; la méthode ne l'est pas. Le risque n'est plus « l'IA », c'est un processus d'affaires, une conséquence chiffrée et un propriétaire.

Le test de la semaine

Prenez l'agent le plus puissant en service chez vous, ou celui qu'un fournisseur a activé dans un outil que vous payez déjà. Répondez à cinq questions :

  1. Sous quelle identité agit-il, et à qui appartient-elle ?
  2. Quels sont les droits de cette identité, et sont-ils plus larges que sa tâche ?
  3. Quelle action irréversible peut-il déclencher sans validation humaine ?
  4. Où sont ses journaux, et quelqu'un les a-t-il déjà lus ?
  5. Qui peut l'arrêter ce soir, et en combien de minutes ?

Une seule réponse « je ne sais pas » suffit : cet agent est un compte à privilèges que personne ne gère.

Ce que vous devriez avoir dans un mois

Un inventaire de vos agents, y compris ceux de vos fournisseurs. Pour chacun, une identité propre, des droits revus, une liste d'outils, une règle d'approbation écrite pour les actions irréversibles, des journaux centralisés et un coupe-circuit testé une fois. Et dans votre registre de risques, au moins un scénario par agent qui touche à l'argent, aux données personnelles ou à la production.

Où FortaRisks intervient

Un agent ajoute des accès, des connecteurs et souvent des interfaces exposées. Forta Exposition repère, de l'extérieur, ce qui devient joignable : une passerelle IA auto-hébergée, une interface d'agent ou un connecteur publiés par erreur. Forta Cockpit porte les scénarios liés à vos agents dans le registre de risques, avec leur propriétaire, leur niveau inhérent et leur niveau résiduel, pour que la direction les arbitre comme n'importe quel autre risque. Pour vous situer dès maintenant, le score de risque cyber gratuit vous donne en dix minutes une lecture de vos principaux domaines.

Jeudi prochain : mesurer et piloter le risque IA. La feuille de route complète en une page, ce qu'on présente au conseil, et un guide téléchargeable qui reprend toute la série.

Sources : OWASP GenAI Security Project, LLM06:2025 Excessive Agency · OWASP GenAI Security Project, Top 10 for Agentic Applications for 2026 · NIST, AI Risk Management Framework · Security Affairs, DIVD et Zammad · CBC, Bibliothèque et Archives Canada · SecurityWeek, agents IA et sites gouvernementaux · The Hacker News, GitLab AI Gateway · BleepingComputer, Microsoft Digital Defense Report 2026

Encadrer l'IA

L'IA a maintenant ses référentiels : ISO 42001, NIST AI RMF

Gouverner l'IA ne demande pas de repartir de zéro. Ces référentiels s'évaluent sur le même socle de contrôles que votre ISO 27001, donc le travail déjà fait compte.