Vos agents IA n’ont pas d’identité, ils ont vos clés

En arrêtant de lui en donner une. Un agent utile n’agit pas en son nom propre, il agit pour le compte de la personne qui demande, avec les droits de cette personne, et pour cette tâche seulement. La quasi-totalité des déploiements font l’inverse, en attribuant à l’agent un compte de service aux droits larges, ce qui revient à créer un chemin qui contourne toutes vos habilitations.

L’ampleur du sujet se mesure déjà. Les identités non humaines dépassent les humaines dans un rapport d’environ 45 pour 1 dans une entreprise moyenne, le parc de ces identités étant passé d’environ 50 000 en 2021 à 250 000 en 2025, et 92 % des organisations déclarent que leurs outils de gestion des accès ne savent pas traiter celles des agents. Le chiffre qui devrait retenir l’attention n’est pas le premier mais le dernier.

Pourquoi un compte de service est la mauvaise réponse

Parce qu’il exprime des droits fixes, et qu’un agent n’a pas de droits fixes.

Un compte de service a été inventé pour un programme qui fait toujours la même chose : une sauvegarde nocturne accède aux mêmes dossiers, à la même heure, pour la même raison. Sa portée est connue à l’avance, elle se déclare une fois, et elle ne dépend de personne. Cette forme est parfaitement adaptée à ce qu’elle décrit.

Un agent est l’exact opposé. La même instance sert un commercial le matin et un dirigeant l’après-midi, sur des dossiers auxquels ces deux personnes n’ont pas le même accès, parfois dans des chaînes où l’agent en appelle un autre qui appelle un outil. La portée légitime change à chaque demande, et elle dépend de qui parle. Aucun compte de service ne sait exprimer cela, ce qui explique que la solution retenue soit presque toujours de prendre le maximum et de compter sur la consigne pour restreindre le reste.

C’est précisément le raisonnement que nous refusons partout ailleurs. Une restriction écrite en langue naturelle se contourne par une autre phrase en langue naturelle, et seule une limite inscrite dans le produit tient. Un agent sur-habilité à qui l’on demande poliment de ne pas dépasser reste un agent sur-habilité.

Le test des deux utilisateurs

Il tient en une manipulation de cinq minutes et il ne demande aucun accès technique, ce qui en fait le meilleur outil de vérification que je connaisse sur ce sujet.

Faites poser exactement la même demande par deux personnes dont les droits diffèrent franchement, un commercial junior et un membre du comité de direction par exemple. Demandez quelque chose que l’une a le droit de voir et l’autre non : les marges d’un compte, les rémunérations d’une équipe, un dossier client sensible.

Si les deux reçoivent la même réponse, l’agent n’a pas délégué. Il a lu avec ses propres droits, et vous venez de découvrir que votre modèle d’habilitation comporte une porte dérobée que personne n’a décidé d’ouvrir. Si les réponses diffèrent, et surtout si la personne aux droits restreints se voit dire qu’elle n’a pas accès plutôt que de recevoir une réponse vide, l’agent délègue correctement.

Ce test a une vertu supplémentaire, qui est de se faire devant l’éditeur pendant une évaluation. Contrairement à la plupart des questions de sécurité, celle-ci s’observe à l’écran et ne se laisse pas régler par une réponse rassurante, ce qui la place dans la courte liste des choses qu’une démonstration peut réellement établir.

Ce que le sujet a de nouveau, et ce qu’il n’a pas

Rien de tout cela n’est une découverte de 2026, et il faut le reconnaître avant de crier à la crise. Les comptes de service trop larges, les clés qui traînent dans des variables d’environnement et les secrets jamais révoqués sont des problèmes d’exploitation vieux de vingt ans, documentés, avec des remèdes connus.

Ce qui est nouveau tient en deux points. Le premier est le volume : un parc d’identités qui quintuple en quatre ans dépasse la capacité d’une équipe à le tenir à jour, et une analyse de 2026 relève que plus de 16 % des organisations ne tracent même pas la création des identités liées à l’IA. Le second est la vitesse de l’exploitation, puisque les mesures de la même période situent à environ dix-sept minutes le délai moyen entre l’exposition d’une clé et son utilisation par un tiers, quand près d’un quart des organisations mettent plus de vingt-quatre heures à la révoquer. Un écart de cet ordre transforme une négligence en incident certain.

Le troisième point, qui n’est pas dans les études, est celui qui me préoccupe le plus. Un agent lit du contenu qu’il n’a pas produit, et ce contenu peut porter des instructions, exactement comme un CV peut en contenir. Un agent sur-habilité transforme donc chaque texte qu’il ingère en levier potentiel sur l’ensemble de vos systèmes, ce qui n’était pas vrai d’un compte de service faisant tourner une sauvegarde.

Ce que nous avons choisi, et ce que ça nous a coûté

Nous avons pris le parti que la portée soit résolue au bord, à l’entrée, une seule fois, et que la question « pour le compte de qui » soit répondue à un seul endroit du code plutôt que dans chaque fonction qui interroge une base.

Ce choix a un coût réel que je préfère décrire, parce qu’il est la raison pour laquelle beaucoup d’équipes prennent l’autre chemin. Il oblige à propager le contexte du demandeur partout, y compris dans les tâches asynchrones et les traitements programmés où il n’y a plus personne devant l’écran, et il rend plus lent l’ajout de toute nouvelle source de données. Une intégration qui prendrait une journée avec une clé unique en prend trois.

Ce qu’il rend possible en échange justifie largement l’écart. Une révocation côté système d’origine prive immédiatement l’agent de l’accès correspondant, sans qu’aucune action ne soit nécessaire de notre côté. Le journal indique pour le compte de qui chaque action a été faite, ce qui rend une enquête possible. Et surtout, aucune fuite ne peut dépasser les droits de la personne qui a formulé la demande, ce qui borne le pire des cas à quelque chose de connu.

Et quand personne n’a rien demandé ?

Voici le cas que le modèle de la délégation ne couvre pas, et je n’ai pas de réponse entièrement satisfaisante à proposer. Un agent proactif se réveille à huit heures le lundi pour préparer un point, ou remarque qu’une mission se termine dans trois semaines. À cet instant, il n’agit pour le compte de personne, puisque personne n’a rien demandé.

La solution paresseuse consiste à faire tourner ces tâches avec un compte technique aux droits larges, ce qui réintroduit exactement le problème par la porte de derrière, et au pire moment puisque personne ne regarde. La solution que nous avons retenue est de rattacher toute exécution programmée à la personne qui l’a mise en place, dont les droits au moment de l’exécution font foi. Un point hebdomadaire configuré par un directeur d’agence s’exécute avec les droits de ce directeur, et il cesse de fonctionner le jour où il quitte l’entreprise.

Cette dernière conséquence est désagréable et je la considère comme une fonctionnalité. Une tâche automatique qui survit au départ de son commanditaire est une tâche que plus personne ne possède, et l’expérience montre qu’elle continue de tourner des années en produisant des résultats que personne ne lit. La faire tomber oblige quelqu’un à la reprendre explicitement, donc à savoir qu’elle existe.

Reste un angle mort que j’assume : une personne qui part avec des tâches programmées bien configurées emporte du service avec elle, et l’équipe le découvre le lundi suivant plutôt que lors de son départ. Nous prévenons avant, ce qui est une rustine plutôt qu’une solution.

Ce qu’il faut exiger d’un éditeur

Trois exigences, toutes vérifiables, et aucune ne demande de faire confiance à une déclaration.

Que l’agent agisse avec les droits du demandeur plutôt qu’avec les siens, ce que le test des deux utilisateurs établit en cinq minutes. Que chaque action soit journalisée avec le nom de la personne pour le compte de qui elle a été faite, et non seulement l’horodatage et l’outil appelé. Que la révocation d’un accès dans le système d’origine se propage immédiatement, ce qui se vérifie en coupant un accès et en reposant la question.

Ces trois points forment aussi le bon niveau de granularité pour une politique de gouvernance, puisqu’ils décrivent l’étendue des accès plutôt que la capacité d’agir, et c’est la confusion entre ces deux notions que Gartner désigne comme la première cause de retrait d’agents en production.

Reste le cas où l’agent n’appelle pas directement vos systèmes mais passe par un serveur tiers, qui détient alors ses propres identifiants et devient un maillon de plus dans la chaîne. C’est une autre discipline, et elle relève de l’achat autant que de la technique : un serveur MCP est un fournisseur.