Un agent logiciel autonome agit au nom d'un utilisateur, mais sans lui à chaque étape. Cela brise l'hypothèse fondatrice de la plupart des dispositifs d'authentification : qu'une action tracée correspond à une décision humaine prise à ce moment-là. Le problème n'est pas que l'agent soit malveillant ; c'est que la chaîne « identité → action → consentement » se rompt silencieusement.
Trois natures d'identité à ne pas confondre
| Type | Exemple | Ce qui l'authentifie | Ce qui manque |
|---|---|---|---|
| Identité humaine | un collaborateur qui se connecte | facteurs de connaissance, possession, inhérence | rien, si le parcours est sain |
| Identité de service | un traitement nocturne, une API interne | secret ou certificat, périmètre fixe | aucune intention à prouver, comportement prévisible |
| Identité d'agent | un assistant qui lit des messages et déclenche des actions | souvent un jeton délégué par un humain | le consentement à chaque action |
L'identité de service est un problème connu et globalement maîtrisé : périmètre restreint, comportement stable, rotation de secrets. L'identité d'agent est différente sur trois points :
- son périmètre est large, parce qu'on l'a conçu pour être utile ;
- son comportement est variable, puisqu'il dépend d'entrées non maîtrisées ;
- il hérite des droits d'une personne, ce qui rend l'imputabilité ambiguë.
Le problème central : le consentement se dilue
Lorsqu'un utilisateur autorise un agent, il accorde en réalité trois choses en une seule fois :
- l'accès à des ressources ;
- la capacité d'agir de manière répétée ;
- la capacité d'agir sans nouvelle décision de sa part.
C'est le troisième point qui pose problème. Un consentement accordé une fois, sur un périmètre large, pour une durée longue, ressemble beaucoup à une signature en blanc. Et l'agent, lui, prend ses instructions dans son contexte d'exécution — messages, documents, pages consultées — qui n'est pas une source de confiance. Un contenu conçu pour être lu par l'agent peut contenir des instructions, ce qui transforme une donnée entrante en commande.
Autrement dit : la surface d'attaque se déplace de l'authentification vers l'autorisation et l'intégrité des instructions.
Ce que les mécanismes classiques ne couvrent pas
- Les jetons de délégation ont une durée de vie longue. Un jeton de rafraîchissement valide plusieurs semaines équivaut à un accès permanent, sans nouvelle preuve de présence humaine.
- Les périmètres sont grossiers. Un droit de lecture sur une messagerie complète ne distingue pas la boîte de réception d'un dossier confidentiel.
- La journalisation attribue à l'humain. Les traces indiquent le compte de l'utilisateur, pas la décision réelle qui a produit l'action. En analyse d'incident, cette confusion coûte cher.
- Les secrets prolifèrent. Chaque intégration ajoute une clé d'API, souvent stockée dans un fichier de configuration, rarement soumise à rotation.
- La révocation est incomplète. Désactiver un compte humain ne suspend pas nécessairement les autorisations déléguées qui en découlent.
Cinq principes de cadrage
-
Donner une identité propre à chaque agent. Un agent ne doit pas emprunter le compte d'une personne. Il lui faut une identité distincte, portant explicitement la mention de la personne au nom de laquelle il agit. C'est la condition d'une traçabilité exploitable.
-
Restreindre le périmètre et la durée. Droits minimaux, durée courte, renouvellement explicite. Un agent qui doit préparer un virement n'a pas besoin de pouvoir le valider.
-
Définir une liste d'actions irréversibles. Virement, changement de coordonnées bancaires, suppression de données, attribution de droits, envoi externe. Sur ces actions, l'agent propose, l'humain dispose. Cette liste doit être établie par le métier, pas par la technique.
-
Exiger une preuve d'intention humaine sur ces actions. Et pas une simple confirmation par bouton : un clic est trivialement automatisable et se donne machinalement. Une preuve utile suppose une opération que seul l'humain peut produire, sur un canal distinct de celui de l'agent. C'est le rôle du 4ᵉ facteur cognitif : l'utilisateur applique une méthode de résolution personnelle, jamais transmise, à un défi éphémère lié à l'opération. Un agent qui détiendrait tous les jetons resterait incapable de la produire.
-
Traiter le contexte de l'agent comme une entrée non fiable. Les instructions valides proviennent de l'utilisateur, pas des documents lus. Cette règle doit être implémentée dans l'architecture — séparation des canaux, validation des actions sensibles — et non simplement espérée.
Le lien avec le Zero Trust
L'architecture Zero Trust décrite par le NIST dans la SP 800-207 pose que l'on ne fait jamais confiance implicitement et que l'on vérifie à chaque accès. Les agents autonomes en constituent le cas limite : une entité qui agit en continu, avec des droits hérités, sur des ressources sensibles.
Trois conséquences pratiques :
- la vérification doit porter sur l'action, pas seulement sur la session initiale ;
- le score de risque contextuel doit intégrer la nature de l'appelant : humain, service ou agent ;
- l'élévation de privilèges doit être temporaire et justifiée, jamais permanente.
Cette approche recoupe les pratiques de gestion des accès à privilèges, qu'il devient logique d'étendre aux identités non humaines.
FAQ
Un agent peut-il détenir une passkey ?
Techniquement, la question se pose ; conceptuellement, elle est mal posée. Une passkey atteste la présence d'un utilisateur devant un authentificateur. La confier à un automate revient à supprimer cette propriété tout en conservant l'apparence de la garantie.
Comment tracer une action réalisée par un agent ?
En journalisant systématiquement trois éléments distincts : l'identité de l'agent, l'identité du mandant humain, et la décision qui a autorisé l'action. Sans cette séparation, l'analyse post-incident ne peut pas établir les responsabilités.
Faut-il interdire les agents sur les périmètres sensibles ?
L'interdiction générale est rarement tenable, et elle pousse à des usages non déclarés. Il est plus efficace de définir une liste d'actions à validation humaine obligatoire, et d'autoriser tout le reste dans un périmètre restreint.
Quel cadre réglementaire s'applique ?
Les obligations de gestion des risques applicables aux entités essentielles et au secteur financier couvrent déjà le contrôle d'accès, la traçabilité et la maîtrise des tiers. Un agent disposant de droits hérités entre dans ce périmètre : il doit être inventorié, autorisé et révocable.
Aller plus loin : pilier : authentification cognitive · attaques automatisées par IA · ce que l'IA change côté attaquant · choisir une solution d'authentification