Identité et autorisation d’un agent IA : déléguer sans pleins pouvoirs

Un agent IA ne devrait jamais recevoir « l’accès de l’utilisateur » comme un bloc indivisible. Il lui faut une identité propre, un propriétaire responsable, un périmètre d’action explicite et une autorisation vérifiée au moment de chaque opération. Sans cette séparation, l’organisation sait peut-être qui a lancé la conversation, mais elle ne sait plus clairement quel composant a lu une ressource, au nom de qui, avec quel droit et pour combien de temps.

La question n’est donc pas seulement de connecter un modèle à un CRM, une messagerie ou un espace documentaire. Elle consiste à construire une chaîne d’autorité : une personne demande, une application transmet, un agent propose ou agit, un outil métier contrôle, puis un journal conserve la preuve utile. Cette chaîne doit rester compréhensible même lorsque l’agent utilise une mémoire persistante, délègue une sous-tâche ou appelle plusieurs services.

Réponse en bref

Pour traiter correctement l’identité et l’autorisation d’un agent IA :

1. donnez à l’agent ou à son runtime une identité technique distincte de celle de l’utilisateur ;
2. nommez un propriétaire métier et un propriétaire technique pour chaque capacité ouverte ;
3. séparez les droits de lecture, de proposition et d’action ;
4. accordez des scopes liés à une ressource et à une opération, pas un rôle général par confort ;
5. transportez l’identité de la personne représentée avec une information on-behalf-of, sans prêter ses identifiants à l’agent ;
6. utilisez des jetons de courte durée et réévaluez l’autorisation avant l’effet externe ;
7. prévoyez la révocation, l’expiration et l’offboarding avant le pilote ;
8. journalisez la décision d’autorisation, l’acteur, la ressource, le résultat et la preuve de l’effet ;
9. testez les refus, les changements de rôle, les délégations en chaîne et les jetons expirés ;
10. refusez la production tant qu’une action ne peut pas être attribuée et expliquée sans relire toute la conversation.

La prochaine action utile est de créer un registre contenant, pour chaque capacité : identité, propriétaire, scopes, ressources, durée, révocation et preuve. Une ligne vague comme « agent commercial : accès CRM » doit être rejetée. Une ligne exploitable indique par exemple « lire les fiches du portefeuille de l’utilisateur pendant quinze minutes, sans export ni modification ».

Identité, authentification et autorisation ne sont pas synonymes

L’identité répond à la question « qui ou quoi agit ? ». Il peut s’agir d’une personne, d’une application cliente, d’un runtime d’agent, d’un service d’outils ou d’un workload éphémère. Deux exécutions du même agent peuvent partager un type de composant tout en portant des identifiants de run distincts.

L’authentification établit qu’un acteur est bien celui qu’il prétend être. Une session utilisateur, un certificat de workload ou un jeton signé peuvent contribuer à cette preuve. Ils ne disent pas automatiquement ce que l’acteur a le droit de faire.

L’autorisation décide si une opération précise est permise dans le contexte courant. Elle doit tenir compte de l’acteur, de la personne représentée, de la ressource, de l’opération, du moment, de l’organisation concernée et parfois de l’état métier. Un jeton techniquement valide ne devrait pas permettre de modifier une facture déjà clôturée si la règle métier l’interdit.

Enfin, la délégation décrit le pouvoir transmis par une personne ou un service à un agent. Elle ne doit pas créer un droit nouveau. Si une salariée peut consulter dix dossiers, l’agent qui agit pour elle ne devrait pas pouvoir en lire cent au motif que le compte technique possède un accès plus large.

Cette distinction paraît académique jusqu’au premier incident. Lorsqu’un compte de service partagé réalise toutes les opérations, le journal peut seulement dire « service-agent a modifié la ressource ». Il ne répond pas à trois questions décisives : quelle personne était représentée, quelle règle a autorisé l’action et quelle limite empêchait le même agent d’agir ailleurs.

Dessiner le flux d’autorité avant le flux de données

Un schéma d’intégration classique suit les données : demande, modèle, outil, réponse. Un schéma de sécurité doit aussi suivre l’autorité.

Personne
  -> application cliente authentifiée
  -> runtime d’agent identifié
  -> contrôle de politique
  -> outil ou API métier
  -> ressource et effet
  -> preuve d’exécution

Chaque flèche représente une frontière. La demande de la personne n’autorise pas automatiquement le runtime. La sélection d’un outil par le modèle n’autorise pas l’appel. La validation du schéma d’entrée n’autorise pas la modification métier. L’obtention d’une réponse HTTP positive ne prouve pas que l’effet attendu a réellement eu lieu.

Ce dessin complète le choix technique expliqué dans MCP ou API pour connecter un agent IA. MCP peut standardiser la présentation d’une capacité et son flux d’autorisation HTTP. Une API peut exposer la règle métier. Aucun protocole ne dispense le serveur qui possède la ressource de vérifier le droit réel.

Ajoutez au schéma quatre identifiants différents : user_id pour la personne, client_id pour l’application, agent_id pour le composant autonome et run_id pour l’exécution. Un delegation_id relie la décision humaine ou organisationnelle à l’autorité transmise. Cette séparation permet de changer un composant sans perdre la responsabilité et de couper un run sans désactiver tout le service.

Trois niveaux : lire, proposer, agir

La plupart des pilotes donnent trop de droits parce qu’ils décrivent une finalité générale, comme « assister l’équipe », au lieu de décrire des opérations. Une première réduction consiste à distinguer trois niveaux de délégation.

Niveau	Capacité	Exemple	Contrôle minimal	Preuve attendue
lecture	consulter sans modifier	lire un statut de commande	périmètre de ressource, filtre d’organisation, durée	ressource référencée et réponse autorisée
proposition	préparer sans déclencher	rédiger une réponse ou un changement	données minimales, destination visible, version	proposition horodatée, non exécutée
action	produire un effet externe	envoyer, publier, modifier, supprimer	nouvelle autorisation, règle métier, confirmation selon le risque	reçu métier, identifiant d’effet, statut final

Un agent qui doit résumer un dossier n’a pas besoin d’un droit d’écriture. Un agent qui prépare un email n’a pas besoin de l’envoyer. Un agent qui propose un changement de statut n’a pas besoin de modifier le CRM avant validation. La conception la plus robuste commence donc au niveau le plus bas et n’ajoute une capacité que lorsqu’un scénario de test prouve sa nécessité.

Le passage de proposition à action constitue une nouvelle décision. Il doit déclencher une vérification d’autorisation fraîche. Pour une action importante, le protocole human in the loop permet de présenter à la personne le destinataire, les données, l’effet et la version qu’elle approuve. L’approbation ne doit pas être un simple bouton « continuer » détaché de l’opération réelle.

Le registre d’autorité en sept champs

Le registre est la source de vérité opérationnelle du pilote. Il ne remplace ni l’annuaire d’entreprise ni la configuration du fournisseur d’identité. Il relie une capacité agentique aux décisions que l’organisation doit pouvoir revoir.

Champ	Question à trancher	Exemple de valeur acceptable
identité	quel composant agit, dans quel environnement ?	agent-support-prod, workload signé, run traçable
propriétaire	qui accepte le risque et qui maintient le contrôle ?	responsable support et équipe plateforme
scopes	quelles opérations unitaires sont permises ?	tickets:read, puis drafts:create
ressources	sur quelles données et quel périmètre ?	tickets de l’organisation et file attribuée
durée	quand le droit commence-t-il et expire-t-il ?	jeton de 15 minutes, délégation de 30 jours
révocation	qui coupe quoi, par quel mécanisme et sous quel délai ?	désactivation du client, retrait du scope, invalidation des sessions
preuve	que conserve-t-on pour attribuer la décision et l’effet ?	delegation_id, règle, reçu métier et résultat

Ajoutez une ligne par combinaison significative de capacité et de niveau. Ne regroupez pas read, create, update et delete dans « gérer les tickets ». La granularité doit permettre de retirer l’écriture sans casser la lecture.

Le registre doit aussi indiquer les dépendances. Si l’agent appelle un serveur d’outils qui utilise ensuite un compte d’intégration, notez cette deuxième identité. Sinon, le premier maillon est correctement gouverné mais le dernier possède encore des pleins pouvoirs invisibles.

Enfin, versionnez chaque ligne. Un scope ajouté après le pilote ne doit pas hériter silencieusement d’une validation ancienne. La date, l’auteur de la décision, le motif et les tests associés transforment le registre en contrôle révisable plutôt qu’en inventaire décoratif.

Agir au nom d’une personne sans emprunter son identité

Le modèle on-behalf-of sépare l’acteur technique de la personne représentée. Le runtime s’authentifie avec sa propre identité. Il transmet ensuite une assertion bornée indiquant pour qui il agit et selon quelle délégation. Le service métier contrôle les deux dimensions.

Une décision d’autorisation peut être formulée ainsi :

autoriser si
  agent_id = agent-support-prod
  et user_id = utilisateur authentifié
  et delegation_id est active
  et scope = tickets:read
  et ticket.organization_id = user.organization_id
  et délégation non expirée

Ce modèle évite deux échecs opposés. Le premier est l’usurpation pratique : l’agent réutilise directement le jeton de la personne et devient difficile à distinguer d’elle. Le second est le super-compte : l’agent possède un compte global et le service lui fait confiance pour appliquer lui-même les restrictions.

La mention on-behalf-of ne doit jamais être acceptée parce qu’elle apparaît dans un champ envoyé par le modèle. Elle doit provenir d’une couche contrôlée, être liée à la session authentifiée et être vérifiable. Le modèle peut demander une opération, mais il ne choisit ni son identité technique ni la personne dont il prétend détenir l’autorité.

Pour une délégation entre agents, conservez l’origine. L’agent A ne doit pas transmettre à l’agent B plus de droits qu’il n’en possède. La chaîne peut inclure parent_agent_id, delegation_id, scopes reçus, scopes réduits et expiration. Une sous-tâche de lecture n’a pas à recevoir le droit d’action du coordinateur.

Scopes étroits et jetons courts

Un scope utile combine un domaine et une opération. crm:access est trop large. contacts:read est meilleur, mais peut rester insuffisant si toutes les organisations partagent le même service. Le contrôle de ressource doit compléter le scope : organisation, portefeuille, file, région ou identifiant explicitement autorisé.

La spécification d’autorisation MCP du 28 juillet 2026 s’appuie sur OAuth pour les transports HTTP. Elle prévoit notamment la découverte des serveurs d’autorisation, l’identification de la ressource cible, les challenges de scopes et une stratégie d’élévation progressive des droits. Elle rappelle ainsi une règle importante : demander d’abord le minimum, puis obtenir un scope supplémentaire lorsque l’opération réelle le nécessite.

Cette spécification ne transforme pas MCP en politique métier universelle. Un serveur protégé reste responsable de la validation du jeton, de son audience, de l’émetteur attendu et de la ressource. La configuration précise évolue avec les versions du protocole et doit être vérifiée dans la documentation et les SDK réellement déployés.

Les jetons de courte durée réduisent la fenêtre d’utilisation après une fuite, un changement de rôle ou l’arrêt d’un run. Leur durée doit correspondre au travail, pas à la commodité du développeur. Un appel de lecture interactif peut utiliser quelques minutes. Une tâche longue peut renouveler son droit depuis une couche contrôlée, sans stocker un jeton durable dans la mémoire de l’agent.

Évitez d’exposer un jeton au modèle, au prompt, au journal ou au résultat d’outil. Le runtime le conserve hors du contexte génératif et l’attache à la requête après validation. Un secret lu par le modèle ne devient pas sûr parce qu’une consigne lui demande de ne pas le répéter.

Révocation et offboarding dès le premier jour

Une délégation qui ne peut pas être retirée n’est pas bornée. Avant le pilote, l’équipe doit savoir couper au moins quatre choses : une personne représentée, un agent, une capacité et une exécution.

Le départ d’un salarié ou un changement de poste doit invalider les délégations associées, pas seulement fermer l’interface de chat. La désactivation d’un agent compromis doit bloquer ses nouveaux jetons et, lorsque l’architecture le permet, ses sessions actives. Le retrait d’un scope d’écriture doit laisser fonctionner les lectures encore justifiées. L’arrêt d’un run doit empêcher la reprise différée avec une autorité devenue obsolète.

Prévoyez aussi l’expiration automatique. Une délégation accordée pour un pilote de trente jours ne doit pas devenir un droit permanent par oubli. Un propriétaire reçoit une alerte avant l’échéance et décide de renouveler, réduire ou supprimer la capacité à partir des preuves collectées.

Le test de révocation doit mesurer un délai réel. Après retrait d’un scope, combien de secondes ou de minutes faut-il pour qu’un nouvel appel soit refusé ? Que se passe-t-il avec un jeton déjà émis ? Une file contient-elle encore des actions préparées ? La réponse dépend de l’architecture, d’où la nécessité d’un exercice et non d’une simple case « révocable ».

Journaliser l’autorité, pas le secret

Le journal doit permettre d’attribuer l’opération sans recopier les contenus sensibles. Pour chaque tentative importante, conservez au minimum : run_id, agent_id, client_id, référence de la personne représentée, delegation_id, scope demandé, ressource ciblée, version de politique, décision, motif, horodatage et résultat métier.

Une décision refusée mérite une trace. Elle prouve que le contrôle fonctionne et aide à distinguer une erreur de configuration d’une tentative hors périmètre. Elle ne doit cependant pas enregistrer le jeton, un secret, le contenu complet du dossier ou le raisonnement interne du modèle.

Pour une action, ajoutez une preuve d’effet fournie par le système métier : identifiant du message, version de la fiche, numéro de commande ou reçu d’opération. Un statut tool.completed prouve seulement que l’appel s’est terminé. Il ne garantit ni l’état final ni l’absence de doublon.

Le protocole de journalisation d’un agent IA décrit comment relier les événements et les références sans conserver tous les prompts. Ici, la priorité est différente mais complémentaire : prouver qui détenait l’autorité et quelle règle a été appliquée.

Le protocole de test avant production

Un test nominal ne suffit pas. Une identité et une autorisation fiables doivent résister aux changements de contexte.

Test	Variation injectée	Résultat attendu
identité inconnue	agent_id non enregistré	refus avant l’accès à la ressource
audience incorrecte	jeton destiné à un autre service	refus sans appel métier
scope absent	lecture autorisée, écriture demandée	refus de l’écriture, lecture intacte
ressource voisine	même scope, autre organisation	refus par contrôle de ressource
délégation expirée	ancien delegation_id	refus et motif traçable
rôle modifié	utilisateur muté ou désactivé	droits recalculés, pas de cache permissif
jeton expiré	tâche reprise tardivement	renouvellement contrôlé ou arrêt sûr
approbation périmée	ressource changée après validation	nouvelle validation exigée
agent délégué	sous-agent recevant trop de scopes	réduction ou refus de la délégation
révocation urgente	agent coupé pendant un run	nouveaux appels refusés et file traitée selon procédure

Ajoutez trois scénarios complets : lecture, proposition et action. Pour chacun, vérifiez le chemin autorisé, puis au moins deux refus. Une action sensible doit aussi être testée après modification de la ressource entre la proposition et l’exécution. La validation doit porter sur une version ou une empreinte, faute de quoi la personne peut approuver A et l’agent exécuter B.

Les tests de détournement restent nécessaires, mais ils répondent à une autre question. L’article sur la prompt injection d’un agent IA traite la manipulation des instructions et la réduction des privilèges. Le présent protocole vérifie l’identité, la délégation et l’application effective des droits, y compris lorsque la demande semble parfaitement légitime.

Après l’attribution des droits, la rotation des clés API d’un agent IA donne un exercice distinct : retrouver tous les consommateurs d’un accès, basculer leur version et prouver que l’ancienne a été révoquée sans interrompre le service.

Passer du registre au pilote

Commencez par une capacité en lecture sur un périmètre réduit. Créez son identité, son propriétaire et son scope. Fixez une expiration. Vérifiez que l’API filtre réellement la ressource. Ajoutez la preuve de décision et le test de révocation. Ce socle fournit plus d’informations qu’un agent doté dès le départ de dix connecteurs et d’un compte administrateur.

Ajoutez ensuite la proposition, sans effet externe. Mesurez les cas où un humain corrige ou rejette. L’action ne vient qu’après la démonstration de trois propriétés : le périmètre de ressource tient, l’autorisation est réévaluée au bon moment et la révocation fonctionne dans le délai prévu.

Pour une automatisation sur mesure, l’accompagnement en automatisation IA et Python peut relier ce registre aux contrôles du service métier, aux tests et à la journalisation. Le livrable utile n’est pas un agent « autonome » présenté en démonstration, mais une capacité bornée dont l’organisation sait expliquer l’autorité et interrompre l’exécution.

Limites

Le concept paper publié par le NCCoE du NIST en février 2026 est un document de consultation. Il identifie des problèmes d’identité, d’autorisation, d’audit et de non-répudiation pour les agents logiciels, mais il ne constitue ni une norme définitive ni une certification. L’AI Agent Standards Initiative du NIST organise des travaux plus larges dont les résultats peuvent encore évoluer.

La note de la CNIL et du Conseil de l’IA et du Numérique publiée le 20 juillet 2026 est exploratoire. Elle souligne notamment la complexité des chaînes de traitement, des mémoires persistantes et du partage des responsabilités. Elle ne remplace pas une analyse RGPD, contractuelle, sociale ou sectorielle appliquée au cas réel.

La spécification MCP évolue rapidement. Sa version datée du 28 juillet 2026 décrit un mécanisme d’autorisation HTTP et s’appuie sur plusieurs standards OAuth, mais sa présence ne prouve pas qu’un client, un serveur ou un SDK implémente correctement chaque exigence. La compatibilité doit être testée sur les versions réellement utilisées.

Enfin, aucun registre ne compense une API métier permissive, un annuaire mal tenu ou un propriétaire absent. L’identité et l’autorisation réduisent l’autorité disponible. Elles ne garantissent ni l’exactitude de la décision du modèle, ni la légalité de la finalité, ni la sécurité de tous les services connectés.

Prochaine étape

Prenez l’action la plus sensible prévue pour l’agent et remplissez une ligne complète du registre : identité, propriétaire, scopes, ressources, durée, révocation et preuve. Décomposez ensuite cette action en lecture, proposition et effet. Si vous ne pouvez pas expliquer qui autorise chaque transition et comment la couper, l’agent n’est pas prêt à recevoir ce pouvoir.