Pourquoi un agent IA n'est pas un compte de service

Amin Hasbini
Hasbini conseil

Hérité des années 1990, le compte de service ne convient pas aux agents IA. Quatre raisons de donner à chaque agent sa propre identité, et cinq actions à engager avec l'IAM en place.

À Toulouse, le 29 septembre 2026, lors d'une table ronde de La Mêlée Numérique retransmise en ligne, une objection a été formulée. Un agent IA ne serait qu'une identité de plus, l'outillage de gestion des identités et des accès (IAM) existe, et il ne resterait qu'à passer à l'échelle. Le RSSI d'un cloud privé rattachait l'agent au collaborateur qui le lance et qui répond de ses actions. L'outillage existe en effet, mais il a été conçu pour des comptes humains et des comptes de service, et c'est le modèle d'identité qui ne tient pas.

J'appelle ici agent un logiciel qui, à partir d'un modèle et d'instructions, choisit et enchaîne lui-même des actions sur d'autres systèmes. Le compte de service, lui, répond à une question des années 1990, celle d'un traitement planifié qui doit s'authentifier sans qu'un humain saisisse de mot de passe. Il repose encore, souvent, sur trois hypothèses rarement formulées. Le programme exécute une suite fixe d'opérations, l'identifiant vit longtemps parce que le renouveler coûte cher, et les droits restent larges puisque le programme ne fera que ce pour quoi il a été codé. Un agent ne respecte aucune des trois, pour quatre raisons.

Pourquoi le compte de service décroche

La première tient à l'acteur, dont le comportement n'est pas déterministe. Un agent choisit ses appels au moment de l'exécution, sous la conduite d'un modèle dont le raisonnement ne se reproduit pas d'une exécution à l'autre. Une politique de moindre privilège écrite d'après la liste des appels prévus perd donc son point d'appui. L'agent peut en outre survivre à sa session et servir plusieurs utilisateurs, ce qui fragilise son rattachement à un seul collaborateur.

Vient ensuite la profondeur de la chaîne de délégation. Un collaborateur sollicite un agent, qui en appelle un deuxième, qui utilise un outil, lequel interroge le service d'un tiers. Chaque maillon devrait porter une identité traçable et révocable. Ces échanges passent souvent par des protocoles entre agents et outils, comme MCP ou A2A. L'IAM en place ne voit alors que l'agent appelant et l'outil appelé, deux identités authentifiées, sans le donneur d'ordre initial ni le « au nom de qui ». Un compte partagé efface cette chaîne, et le journal d'audit s'appauvrit là où auditeurs et superviseurs attendent une piste par agent.

Troisième écart, l'injection d'instructions, qui rend les dégâts asymétriques. Une instruction cachée dans un document ou un courriel peut retourner l'agent contre la personne pour qui il agit, avec des identifiants légitimes. Le risque augmente nettement quand un agent cumule l'accès à des données privées, l'exposition à des contenus non fiables et un canal de sortie. Un identifiant d'équipe additionne alors les accès de tous. Une identité par agent borne les dégâts au périmètre d'un seul, à condition que ses droits soient eux-mêmes limités à la tâche. Le Top 10 2026 de l'OWASP consacré aux applications agentiques classe l'abus d'identité et de privilèges (ASI03) parmi ses dix risques.

Les textes, enfin, ne nomment pas les agents. Dans l'Union, le règlement DORA sur la résilience numérique du secteur financier, applicable depuis le 17 janvier 2025, et la directive NIS 2, dont la transposition française attend encore son vote, posent des exigences neutres quant à la technologie sur les systèmes de TIC, les accès et la journalisation. Pour les entités de leur champ, ces exigences peuvent donc s'appliquer aux agents. Avec un identifiant d'équipe, démontrer en cas de contrôle une journalisation par agent et une révocation ciblée devient, à mon sens, difficile. L'omnibus numérique sur l'IA, adopté en 2026, a reporté au 2 décembre 2027 l'application du règlement (UE) 2024/1689 sur l'IA aux systèmes à haut risque de son annexe III. À Singapour, l'autorité monétaire (MAS) a publié le 7 octobre 2026 ses lignes directrices sur la gestion des risques liés à l'IA, pour toutes les formes d'IA à compter d'octobre 2027. Elle annonce pour 2027 une consultation sur des orientations propres aux agents.

Les grands fournisseurs de modèles ont livré entre avril et juin 2026, selon leurs annonces, des fonctions pensées pour les agents (identifiants d'agent, sessions par instance, flux d'événements), la plupart en bêta ou réservées aux offres entreprise. Dans la documentation publique que j'ai consultée en juillet 2026, je n'ai toutefois pas trouvé d'identité cryptographique unique et non partagée par instance d'agent.

Ce qu'est une identité par agent

Chaque agent a sa propre identité cryptographique, jamais partagée, et un cycle de vie journalisé de l'enregistrement à la révocation. Ses clés sont renouvelées à une fréquence proportionnée au risque et la révocation doit prendre effet en quelques minutes plutôt qu'en jours. Son enregistrement indique son propriétaire, son niveau de risque, ses capacités déclarées et sa version. Le tout s'appuie sur un registre, une liste de référence des agents en production, éventuellement fédérée.

Cinq actions

Quatre tiennent avec l'IAM en place, la cinquième relève du programme post-quantique. La première est un inventaire de tous les agents, en production, en pilote et sur les postes des développeurs reliés à des API de production. Si la liste demande plus de deux semaines, ce délai est en soi un premier constat d'audit. La deuxième retire la clé d'API partagée au profit d'identifiants propres à chaque agent, quitte à commencer par un client OAuth par agent. La troisième confie l'identité des agents à un responsable nommé, une personne et une fonction, pas un comité. La quatrième branche ces identités sur l'IAM existant, sans pile parallèle, dans la même gouvernance et le même cycle d'arrivées, de mobilités et de départs que les collaborateurs.

La cinquième se décide maintenant. Elle inscrit les canaux entre agents dans le périmètre de la migration post-quantique, avec un échange de clés hybride, quand les données échangées doivent rester confidentielles au-delà de l'horizon de la cryptographie actuelle. Le premier geste, lui, tient en une demande écrite à la DSI et aux métiers, pour chaque agent connu, de son propriétaire, de ses accès et de la façon de le révoquer. La liste qui revient ouvre le chantier.

Sources

  • La Mêlée Numérique, Toulouse, table ronde du 29 septembre 2026, retransmise en ligne (programme et replay sur le site de l'événement).
  • OWASP, « Top 10 for Agentic Applications 2026 », risque ASI03 « Identity & Privilege Abuse ».
  • Règlement (UE) 2022/2554 (DORA), applicable depuis le 17 janvier 2025 · directive (UE) 2022/2555 (NIS 2), projet de loi français de transposition en attente d'examen (retiré de l'ordre du jour de l'Assemblée nationale des 7 et 9 octobre 2026).
  • Règlement modificatif dit « omnibus numérique sur l'IA » (2026) : application aux systèmes à haut risque de l'annexe III du règlement (UE) 2024/1689 reportée au 2 décembre 2027.
  • Monetary Authority of Singapore, « Guidelines on Artificial Intelligence Risk Management », communiqué du 7 octobre 2026 (effet 7 octobre 2027 et 7 octobre 2028, consultation 2027 annoncée sur l'IA agentique).