Identité des agents IA : ce que propose le projet IETF AIMS
Publié le 15 septembre 2026, le projet IETF AIMS propose un cadre pour identifier et autoriser les agents IA. Voici ce qui est déjà applicable, ce qui reste à l'état de projet et les contrôles à mettre en place.
Réponse en bref
Le 15 septembre 2026, le groupe WIMSE de l'IETF a publié la première version du projet AI Identity Management System (AIMS). Ce document de travail décrit comment composer des mécanismes existants pour donner une identité vérifiable à un agent, lui fournir des justificatifs à durée limitée, déléguer des droits et auditer ses actions. Ce n'est pas une norme finalisée. Les entreprises peuvent néanmoins commencer dès maintenant par séparer l'identité de l'agent de celle de la personne qui l'autorise, réduire les permissions et rendre les révocations effectives.
Ce qui vient de changer
Le projet draft-ietf-wimse-aims-00, daté du 15 septembre 2026, a été publié comme Internet-Draft actif au sein du groupe de travail WIMSE. Il rassemble un modèle de gestion de l'identité d'un agent à partir de pratiques et de standards existants, notamment les identités de workloads, OAuth 2.0 et les mécanismes de délégation. Le document précise qu'il s'agit d'un travail en cours : un Internet-Draft peut changer, être remplacé ou être retiré. Il ne faut donc pas le présenter comme un standard approuvé. Consultez la fiche de statut IETF et la version courante du projet AIMS.
Le sujet a aussi été souligné par le NIST. Dans un article publié le 27 août 2026, le National Cybersecurity Center of Excellence rappelle qu'un agent ne devrait pas recevoir le mot de passe personnel d'un utilisateur ni s'appuyer sur une clé API durable et partagée. Le NIST insiste sur des identifiants propres aux agents, des autorisations qui restent liées à l'utilisateur ou au système à l'origine de la tâche et une meilleure traçabilité des opérations. Il s'agit d'un billet d'orientation, pas d'une règle obligatoire. Voir l'analyse du NIST sur les identités et les autorisations d'agents.
L'identité est une chaîne de contrôles
Une identité d'agent ne se résume pas à un nom dans un registre. Elle relie un workload exécuté, un justificatif vérifiable, une décision d'accès et une trace d'audit. Le projet AIMS décrit plusieurs fonctions complémentaires : identifiant unique, justificatifs, provisionnement, authentification, autorisation, observabilité, règles et conformité. La figure ci-dessous en donne une lecture opérationnelle, simplifiée pour une architecture d'entreprise.
Schéma Nexxom, synthèse de l'Internet-Draft IETF AIMS et des contrôles d'identité décrits par le NIST. Il illustre un modèle, pas une implémentation imposée.
Dans le modèle, la personne ou le système demande une tâche. L'agent s'authentifie comme workload distinct. Un serveur d'autorisation vérifie qui a demandé la tâche, ce que l'agent doit faire et quelle ressource est concernée. Le service cible applique lui-même la décision. Enfin, une trace permet de reconstituer l'action et de retirer l'accès si le risque change.
Agent, utilisateur et délégation : trois notions différentes
L'agent doit avoir sa propre identité technique, mais il n'est pas automatiquement le propriétaire de tous les droits utiles à sa tâche. Il faut distinguer trois questions : qui exécute l'appel, qui a demandé l'action et quelle opération a été autorisée.
Le RFC 8693, OAuth 2.0 Token Exchange, distingue la délégation de l'usurpation d'identité. Dans une délégation, l'agent conserve sa propre identité et agit explicitement au nom d'un utilisateur. Dans une usurpation, l'appel paraît provenir de l'utilisateur lui-même. Cette différence détermine si un journal permet de savoir quel acteur logiciel a pris la décision.
| Question | Valeur à conserver | Erreur à éviter |
|---|---|---|
| Quel workload a effectué l'appel ? | Identifiant stable de l'agent ou de sa charge de travail | Un compte de service partagé entre plusieurs agents |
| Qui a demandé ou autorisé la tâche ? | Identité de l'utilisateur ou du système initiateur | Effacer le principal d'origine pendant la délégation |
| Quelle action était permise ? | Ressource, opération, portée, durée et contexte | Reprendre toutes les permissions de l'utilisateur |
| Comment expliquer le résultat ? | Décision d'accès et corrélation avec la tâche | Un journal qui ne montre que le modèle utilisé |
Cette distinction est utile même si l'agent ne sort pas du réseau de l'entreprise. Elle aide à attribuer une modification, révoquer un accès, enquêter sur un incident et limiter le rayon d'impact d'une erreur. Notre article sur la connexion sécurisée d'agents par MCP traite le protocole d'accès aux outils. Ici, le sujet est l'autorité de l'agent et la façon de la représenter dans plusieurs systèmes.
Quelles autorisations choisir ?
Le bon modèle dépend de la tâche. Un agent qui lit des documents publics pour produire un résumé n'a pas besoin du même niveau d'accès qu'un agent qui modifie des dossiers clients ou déclenche un paiement. La décision doit porter sur l'action et la ressource, pas seulement sur la catégorie générale « agent IA ».
| Situation | Principal à conserver | Autorisation conseillée | Contrôle humain |
|---|---|---|---|
| Recherche ou synthèse en lecture seule | Agent et utilisateur demandeur | Lecture des seules sources nécessaires, durée limitée à la tâche | Revue par échantillon ou à la demande |
| Mise à jour d'un dossier métier | Agent, utilisateur et dossier concerné | Écriture sur un périmètre précis, validation du schéma et journal d'événement | Approbation selon l'impact de la modification |
| Action financière, administrative ou irréversible | Agent et principal autorisant chaque opération | Portée transactionnelle, limite de valeur et expiration courte si le système les supporte | Confirmation indépendante avant exécution |
| Tâche lancée par un système planifié | Identité du job initiateur et identité propre de l'agent | Droits de service distincts, ressources explicitement autorisées | Alerte et arrêt automatique sur anomalie |
Le NIST AI RMF et son playbook de mesure peuvent aider à inscrire ces choix dans l'analyse des risques et le suivi opérationnel. Ils n'imposent pas un fournisseur d'identité ni un protocole unique.
Des justificatifs courts et ciblés
Les clés API copiées dans un prompt, un fichier de configuration partagé ou des journaux ne permettent pas toujours de savoir quel agent a agi, et elles sont difficiles à retirer sans effet collatéral. Le billet du NIST observe qu'un détenteur d'une clé ou d'un bearer token peut souvent la présenter. Le risque augmente quand des secrets durables sont propagés entre agent, outil, modèle et service.
Le projet AIMS traite le provisionnement comme un processus à l'exécution : un système vérifie le workload et son état, puis délivre un justificatif ayant une échéance. Il mentionne des identités de charge de travail, dont SPIFFE, ainsi que des certificats ou jetons signés selon l'architecture. La présentation de SPIFFE explique le principe d'identifiants et de justificatifs destinés aux workloads. Le RFC 9700, bonnes pratiques de sécurité OAuth 2.0, fournit les recommandations générales à prendre en compte lorsqu'une entreprise choisit OAuth.
Quand un agent doit appeler plusieurs services, un échange de jetons peut fournir un justificatif mieux adapté au service aval. Le RFC 8693 définit le protocole d'échange, mais ne choisit pas à lui seul les règles métier, la durée ou le périmètre de confiance. L'équipe doit vérifier que le serveur d'autorisation réduit réellement les droits et que le service cible valide audience, portée, expiration et principal. L'IETF le décrit comme un mécanisme composable, pas comme une solution automatique.
| Contrôle du justificatif | Vérification de conception |
|---|---|
| Identité | Le jeton est-il lié au workload attendu, plutôt qu'à un compte générique ? |
| Audience | Est-il accepté uniquement par le service destinataire prévu ? |
| Portée | Limite-t-il les ressources et opérations utiles à cette tâche ? |
| Durée | Expire-t-il assez vite pour réduire l'exposition après une fuite ? |
| Délégation | Le service peut-il distinguer l'agent du principal représenté ? |
| Révocation | La désactivation invalide-t-elle les sessions et caches concernés ? |
La fiche de sécurité des agents OWASP recommande également le moindre privilège, des permissions différenciées par outil et une autorisation explicite pour les opérations sensibles. Notre analyse des permissions des agents MCP complète ce contrôle en examinant les abus déclenchés par des entrées non fiables.
L'audit et la révocation doivent suivre l'action
Un journal utile permet de répondre à cinq questions : quel agent a appelé quel outil, au nom de qui, pour faire quoi, avec quelle décision d'accès et à quel moment ? Le projet AIMS ajoute la nécessité de conserver le contexte d'autorisation et de traiter les événements de risque ou de révocation. Il recommande que les systèmes concernés retirent ou réduisent l'accès lorsque l'autorisation n'est plus valable. Comme le document est un draft, ces formulations décrivent les exigences proposées par ses auteurs, et non des obligations déjà standardisées.
| Événement à tracer | Champs opérationnels utiles |
|---|---|
| Demande autorisée ou refusée | ID agent, principal initiateur, ressource, action et décision |
| Jeton émis ou échangé | Émetteur, audience, portée, expiration et identifiant de corrélation |
| Action exécutée | Outil, résultat, horodatage et référence de tâche |
| Permission changée ou révoquée | Motif, acteur, heure d'effet et état des sessions associées |
| Incident ou comportement inattendu | Signal observé, action de remédiation et état final |
Évitez de journaliser les secrets ou tout le contenu de la conversation par défaut. Un identifiant de tâche, des références de ressources et des événements d'autorisation peuvent suffire à l'enquête tout en limitant les données personnelles conservées. Définissez qui accède aux traces, pendant combien de temps et selon quelle justification.
Une mise en place pragmatique en cinq étapes
- Inventorier. Listez les agents, leurs outils, propriétaires, environnements d'exécution et identités techniques. Incluez les prototypes et les agents personnels installés sur des postes.
- Séparer. Donnez un identifiant distinct à chaque agent ou workload. Distinguez cet acteur du salarié, du job planifié et du compte de service.
- Définir l'autorité. Pour chaque tâche, écrivez qui la demande, quelles ressources l'agent peut lire ou modifier, pendant combien de temps, et quelles actions exigent une confirmation.
- Émettre et retirer. Préférez des justificatifs délivrés au runtime, à courte durée et ciblés. Testez la rotation, la révocation et le comportement en cas de panne du fournisseur d'identité.
- Auditer. Vérifiez qu'une équipe peut reconstituer une tâche de bout en bout et retirer l'accès d'un agent sans désactiver le compte d'une personne.
Pour les agents locaux, les systèmes anciens ou les fournisseurs incapables de recevoir des jetons délégués, une migration immédiate vers une identité workload peut être impossible. Commencez par isoler le secret dans un coffre, créer un compte dédié et limité, réduire sa durée de validité si possible, interdire son usage hors du runtime et documenter le plan de retrait. Ce contrôle transitoire ne remplace pas une délégation vérifiable.
Ce que l'entreprise peut décider maintenant
Le projet IETF AIMS n'impose pas de remplacer les systèmes IAM existants ni d'adopter un nouveau produit. Il aide plutôt à examiner les responsabilités manquantes entre identité de workload, autorisation métier, propagation du principal utilisateur, audit et révocation. Le périmètre exact reste à stabiliser, car la version 00 est un Internet-Draft informatif publié le 15 septembre 2026.
Pour certaines équipes, le premier chantier sera de supprimer des clés partagées et de donner une identité distincte à chaque agent. Pour d'autres, le besoin principal sera de conserver la délégation dans les journaux ou de révoquer une permission en cours de tâche. Dans tous les cas, un agent ne devrait pas recevoir plus de droits qu'une tâche définie ne l'exige.
La question pratique n'est donc pas seulement « quel modèle l'agent utilise-t-il ? », mais « quel acteur peut exécuter quelle action, pour qui, sur quelle ressource, pendant combien de temps, et comment arrêter cet accès ? ». Une revue d'identité et d'autorisation répond à cette question avant que les agents ne se multiplient dans les processus métier.
Sources vérifiées le 16 septembre 2026
- IETF, AI Identity Management System, draft-ietf-wimse-aims-00, Internet-Draft informatif, publié le 15 septembre 2026.
- NIST NCCoE, Why Agentic AI Needs a Strong Identity Foundation, publié le 27 août 2026.
- RFC 8693, OAuth 2.0 Token Exchange, distinction entre délégation et usurpation.
- RFC 9700, Best Current Practice for OAuth 2.0 Security.
- NIST, AI Risk Management Framework et Measure Playbook.
- SPIFFE, Overview.
- OWASP, AI Agent Security Cheat Sheet.
