Le plan d'action d'entreprise pour l'identité agentique : attestation des charges de travail et gouvernance du cycle de vie
Le secteur de l'identité ne part pas de zéro. Les cadres de référence existants offrent des solutions robustes et immédiatement applicables pour sécuriser les agents d'aujourd'hui. Les bonnes pratiques consistant à séparer les préoccupations, à appliquer le principe du privilège minimal et à garantir des pistes d'audit claires constituent les fondements sur lesquels doit reposer la prochaine génération de systèmes agentiques.
20 avril 2026
Directeur technique
Gestion des identités pour l'IA agentique, Fondation OpenID (octobre 2025)
Le livre blanc de l’OpenID Foundation sur la gestion des identités pour l’IA agentique s’ouvre sur une observation d’une simplicité trompeuse : les agents d’IA sont fondamentalement différents des logiciels traditionnels. Ils agissent de manière autonome, s’adaptent en temps réel et fonctionnent à travers des séquences d’appels à des outils externes, autant d’éléments qui n’avaient pas été anticipés lorsque le secteur a conçu son infrastructure d’identité autour des identifiants humains et des comptes de service statiques.
Cette constatation soulève un défi auquel les équipes chargées de la sécurité et des plateformes commencent tout juste à être confrontées : le modèle d'identité dont nous avons hérité de l'ère des applications web n'est pas adapté à un monde d'agents autonomes. Les agents ont besoin d'identités certifiées cryptographiquement, à durée de vie limitée, régies par l'entreprise et dont le cycle de vie est géré au même titre que celui des utilisateurs humains, et non pas ajoutées après coup.
Cet article décrit une preuve de concept qui met précisément en œuvre ce système. Il intègre l'attestation de charge de travail SPIFFE/SPIRE, l'enregistrement dynamique des clients OAuth 2.1, l'échange de jetons RFC 8693, la politique de portée d'entreprise et une API de cycle de vie SCIM 2.0 au sein d'une architecture d'identité unique et cohérente destinée aux serveurs du protocole Model Context Protocol. Chaque choix de conception correspond à une recommandation spécifique issue des travaux de recherche fondamentaux ou comble une lacune que les auteurs ont identifiée comme critique.
Le problème n'est pas nouveau. Ce sont les enjeux qui le sont.
Tout ingénieur de plateforme ayant déjà déployé un microservice a été confronté à une variante de ce problème : comment une machine peut-elle prouver son identité ? La réponse traditionnelle a toujours été un secret partagé : une clé API, un secret client, un jeton à longue durée de vie stocké dans une variable d'environnement ou un gestionnaire de secrets. Cette solution a toujours été peu satisfaisante, mais pour les services sans état au comportement prévisible et limité, le risque restait gérable.
Les agents IA changent la donne de trois façons à la fois :
-
Les agents agissent de manière autonomeContrairement à un microservice qui exécute une fonction déterministe, un agent interprète des données d'entrée non structurées et décide des actions à entreprendre au moment de l'inférence. Une simple instruction de l'utilisateur peut générer des dizaines d'appels d'API sur plusieurs systèmes en aval. L'ampleur des répercussions d'une compromission de l'identité d'un agent n'est pas limitée par le code du service ; elle n'est limitée que par les autorisations dont dispose l'agent.
-
Les agents agissent pour le compte des utilisateursUn agent qui accède au CRM d’une entreprise au nom d’un commercial dispose à la fois de ses propres autorisations et d’un sous-ensemble délégué des droits de cet utilisateur. Lorsque les requêtes de cet agent sont impossibles à distinguer des requêtes directes de l’utilisateur dans les journaux d’audit (ce qui est le cas dans la plupart des implémentations actuelles), la traçabilité disparaît complètement. Pour le dire clairement : les agents agissent souvent de manière impossible à distinguer des utilisateurs, ce qui crée des lacunes en matière de responsabilité et des risques de sécurité qui exigent le passage à une délégation explicite des pouvoirs.
-
Les agents ont un cycle de vieIls sont créés, leurs droits évoluent au gré des changements de rôles au sein de l'organisation, et ils doivent être désactivés, souvent de toute urgence, en cas d'incident de sécurité. Aucun des outils existants destinés aux comptes de service ne gère ce cycle de vie avec la même rigueur que celle dont font preuve les entreprises pour les identités humaines.
Il s'agit là des défis les plus urgents à court terme, ce qui conduit à une recommandation fondamentale claire : intégrer les agents dans la même infrastructure d'identité normalisée qui régit les utilisateurs humains, plutôt que de mettre en place des solutions sur mesure et propriétaires qui fragmentent l'écosystème.
Niveau 1 : Attestation cryptographique des charges de travail avec SPIFFE/SPIRE
La question fondamentale qui se pose dans toute architecture d'identité est la suivante : que signifie « faire confiance » à l'identité revendiquée par un client ? Pour les utilisateurs humains, la confiance s'établit par l'authentification : un mot de passe, une clé matérielle, une donnée biométrique. Pour les charges de travail, le mécanisme analogue est l'attestation : prouver, à travers les propriétés de l'environnement d'exécution lui-même, qu'un processus est bien ce qu'il prétend être.
Les recommandations du secteur désignent explicitement SPIFFE (Secure Production Identity Framework for Everyone) et son environnement d'exécution SPIRE comme modèle d'identité des charges de travail pour les agents d'IA :
« Grâce à l'intégration avec SPIRE, un agent IA pourrait se voir attribuer une identité à durée de vie limitée et renouvelée automatiquement, qu'il pourrait utiliser pour s'authentifier mutuellement auprès d'autres services, établissant ainsi une relation de confiance sans avoir recours à des secrets statiques et partagés, tels que des clés API. »
Notre implémentation met en œuvre ce modèle de bout en bout. Chaque conteneur d'application exécute un agent SPIRE intégré qui s'authentifie auprès du serveur SPIRE à l'aide du protocole x509pop (X.509 Proof of Possession) : l'agent présente un certificat TLS signé par une autorité de certification interne, et le serveur SPIRE le valide par rapport à la chaîne de certificats enregistrée pour ce nœud. Il n'y a pas de jetons de connexion. Il n'y a pas de secrets statiques. Le certificat de l'autorité de certification est la seule racine de confiance, et il est établi une seule fois lors de la configuration de l'infrastructure, et non pour chaque charge de travail.
Une fois qu'un agent de nœud dispose de son identité, les charges de travail reçoivent des SVID (SPIFFE Verifiable Identity Documents) via l'API SPIFFE Workload par le biais d'un gRPC. Les clés privées sont transmises directement à la mémoire du processus et ne sont jamais enregistrées sur le disque ni transmises via des variables d'environnement. Chaque charge de travail du système (le client MCP, le serveur MCP, l'API de gestion et le serveur SCIM) reçoit un identifiant SPIFFE suivant une convention de nommage cohérente :
- spiffe://spire.indigolabs.ca/workload/mcp-client
- spiffe://spire.indigolabs.ca/workload/mcp-server
- spiffe://spire.indigolabs.ca/workload/management
- spiffe://spire.indigolabs.ca/workload/scim-server
Le serveur SPIRE est configuré avec une durée de vie (TTL) de 1 heure pour les SVID X.509 et de 5 minutes pour les SVID JWT. Ces durées de vie courtes constituent le mécanisme permettant de limiter l'ampleur des conséquences d'une fuite : un SVID X.509 divulgué expire au plus tard au bout de 60 minutes ; un JWT divulgué expire au plus tard au bout de 5 minutes. SPIRE renouvelle automatiquement le SVID X.509 à environ 80 % de sa durée de vie (~48 minutes), et la couche applicative propage ce renouvellement au serveur d'autorisation sans redémarrage, ce qui est une propriété essentielle pour les environnements de production.
Il s'agit du modèle de compte de service amélioré, considéré comme le modèle d'entreprise le plus viable à court terme pour les charges de travail agentiques : un agent doté d'un jeton d'identité enrichi de métadonnées spécifiques à la charge de travail (dans ce cas, un identifiant SPIFFE codant le nom du service, le domaine de confiance et le chemin d'accès), émis via un mécanisme d'attestation conforme aux normes, et non via un processus de provisionnement impliquant une intervention humaine.
Deuxième niveau : combler les lacunes en matière d'anonymat du DCR
La RFC 7591 (OAuth 2.0 Dynamic Client Registration) est le mécanisme par lequel les clients s'enregistrent auprès d'un serveur d'autorisation lors de l'exécution. C'est exactement le type d'intégration autonome et en libre-service dont les architectures d'agents ont besoin. La spécification MCP impose le DCR comme mécanisme d'enregistrement pour les clients MCP.
Mais une préoccupation majeure se fait jour : les terminaux DCR non authentifiés génèrent des clients anonymes, c'est-à-dire des entités disposant d'identifiants OAuth mais sans lien vérifiable avec une charge de travail, une organisation ou une entité responsable réelles. L'enregistrement massif d'utilisateurs anonymes constitue un vecteur d'attaque par déni de service, et un système non certifié client_id constitue une base fragile pour un modèle de sécurité d'entreprise.
La solution mise en œuvre ici établit un lien direct entre DCR et SPIRE : le champ « software statement » de la requête DCR contient un JWT-SVID (un JWT émis par SPIRE, signé avec la clé privée EC P-256 du domaine de confiance SPIRE, et contenant l'identifiant SPIFFE de la charge de travail en tant que sub revendication). Le serveur d'autorisation (PingAM) valide cette déclaration logicielle en récupérant le point de terminaison JWKS du fournisseur SPIRE OIDC via HTTPS (https://spire-oidc.docker.internal/keys) et en vérifiant la signature du JWT.
Il en résulte que chaque requête DCR est cryptographiquement liée à une charge de travail spécifique et certifiée. PingAM enregistre le client auprès de private_key_jwt l'authentification, en utilisant la clé publique EC extraite du SVID X.509 de la charge de travail comme JWKS du client enregistré. Le client peut désormais s'authentifier auprès de PingAM en signant des JWT avec sa clé privée émise par SPIRE. Cette clé n'a jamais été enregistrée sur le disque, n'a jamais été transmise sous forme de variable d'environnement et expire au bout de 60 minutes.
Il s'agit d'une mise en œuvre directe du modèle recommandé pour un DCR robuste : des clients liés à un émetteur d'identité vérifiable, plutôt que des inscriptions anonymes sans chaîne de responsabilité.
Troisième niveau : la rotation des clés sans interruption de service, une réalité opérationnelle
L'une des caractéristiques souvent négligées des identifiants à durée de vie limitée est que leur niveau de sécurité dépend entièrement du mécanisme de rotation. Si la rotation des clés nécessite l'intervention d'un opérateur humain, un pipeline de déploiement ou un redémarrage du service, les entreprises auront tendance à prolonger les délais d'expiration (TTL) afin d'alléger la charge opérationnelle, ce qui annule tout l'effet de réduction de l'ampleur des incidents.
Cette implémentation répond directement à ce problème. Après le DCR, chaque charge de travail lance une boucle d'interrogation SVID qui vérifie l'empreinte du certificat toutes les 30 secondes. Lorsque SPIRE émet un nouveau SVID (au bout d'environ 48 minutes pour un TTL d'une heure), l'empreinte change. L'application détecte le changement, extrait la nouvelle clé publique EC du SVID X.509 actualisé, récupère un nouveau JWT-SVID à utiliser comme déclaration logicielle renouvelée, et envoie une requête PUT RFC 7592 au registration_client_uri, le tout sans redémarrer le processus ni interrompre les requêtes en cours.
Il ne s'agit pas d'une capacité théorique. Elle a fonctionné sans interruption tout au long du développement de ce prototype, en renouvelant les clés des dizaines de fois sans qu'une seule requête n'ait échoué.
Les propriétés qui en découlent rejoignent directement les débats sur le cycle de vie des identifiants dans les systèmes agentiques :
-
Aucune intervention de l'opérateurLa rotation est entièrement autonome.
-
Les secrets ne restent jamais cachésLes données relatives aux clés privées ne sont conservées en mémoire que pendant la durée de vie du processus SVID.
-
Rayon d'action court et limitéUne clé compromise expire dans les limites de la durée de vie (TTL) du SVID ; la boucle d'interrogation transmet la révocation au serveur d'autorisation dans les 30 secondes suivant l'émission de la clé de remplacement par SPIRE.
Quatrième couche : politique d'entreprise au niveau de la couche d'autorisation
Il convient d'accorder une attention particulière au principe du privilège minimal, qui revêt une importance cruciale lors du déploiement d'agents d'IA, compte tenu de leur nature non déterministe. Le risque est évident : un agent disposant de droits plus étendus que ne l'exige la tâche amplifie les conséquences de toute utilisation abusive ou compromission.
Le mécanisme standard permettant de définir les droits d'accès d'un agent repose sur les champs d'application OAuth 2.0. Cependant, ces champs d'application n'ont de sens que dans la mesure où la politique régissant leur attribution est bien définie. Un agent capable de demander et d'obtenir des champs d'application arbitraires n'est soumis à aucune contrainte effective en la matière.
Cette implémentation applique la politique de portée au niveau du serveur d'autorisation, et non au niveau du client ou du serveur de ressources. PingAM exécute un script de modification des jetons d'accès qui se déclenche à chaque émission de jeton. Ce script interroge PingDS (l'annuaire LDAP) pour connaître les appartenances à des groupes de l'utilisateur et supprime toute portée MCP non justifiée par ces appartenances avant de renvoyer le jeton.
La mise en correspondance est explicite et vérifiable :
| Groupe LDAP | Portée du MCP approuvée |
|---|---|
| Ingénierie | mcp.engineering |
| Ventes | mcp.sales |
| Direction | mcp.leadership |
| RH | mcp.hr |
Un utilisateur du groupe « Ventes » qui demande mcp.engineering reçoit un jeton dont cette portée a été supprimée. Le client ne peut pas contourner cette mesure, car le filtrage s'effectue côté serveur, au sein du serveur d'autorisation, avant l'émission du jeton. Il s'agit là de la séparation entre le point d'application des politiques (point de terminaison du jeton PingAM) et la logique métier, recommandée par les experts du secteur, qui se réfèrent à la norme NIST SP 800-162 comme modèle architectural.
Le serveur MCP valide ensuite les champs d'application de chaque requête entrante, constituant ainsi une deuxième ligne de défense. La validation des champs d'application au niveau du serveur d'autorisation garantit que le jeton ne peut pas comporter de champs d'application non autorisés ; la validation au niveau du serveur de ressources garantit que la ressource ne peut pas être consultée sans le champ d'application approprié, même si, d'une manière ou d'une autre, un jeton arrivait avec des revendications inattendues.
Cinquième couche : la délégation véritable plutôt que l'usurpation d'identité
L'un des choix architecturaux les plus déterminants dans tout système d'agent réside dans la manière dont l'agent représente son autorité lorsqu'il agit au nom d'un utilisateur. La mise en œuvre la plus simple consiste à se faire passer pour l'utilisateur : l'agent détient le jeton d'accès de l'utilisateur et le présente directement aux systèmes en aval. C'est ce que les analystes appellent le « déficit de responsabilité », car le service en aval ne peut pas distinguer les actions de l'agent de celles de l'utilisateur.
L'autre solution consiste en une délégation explicite, et la spécification MCP ext-auth fournit le mécanisme protocolaire nécessaire à cet effet. Cela est présenté comme un tournant décisif du point de vue de la posture de sécurité :
« Une véritable délégation nécessite des flux explicites de type « au nom de », dans lesquels les agents justifient de l'étendue des pouvoirs qui leur ont été délégués tout en restant identifiables comme distincts de l'utilisateur qu'ils représentent. »
Le flux d'authentification externe mis en place y parvient grâce à une chaîne d'échange de jetons en deux étapes conforme à la norme RFC 8693 :
-
Étape 1 : Liaison d'identité.Le client MCP transmet le jeton d'identité OIDC de l'utilisateur au point de terminaison des jetons de PingAM et demande un ID-JAG (Intermediate Agent Grant). Il est essentiel de noter que cette requête est authentifiée à l'aide d'un JWT à clé privée signé à l'aide du SPIRE SVID, l'identité cryptographique de la charge de travail de l'agent. L'ID-JAG ainsi obtenu contient l'identité de l'utilisateur, mais est délivré à un client qui a prouvé, par le biais d'une attestation SPIRE, qu'il s'agit bien de la charge de travail spécifique autorisée à effectuer cet échange. -
Étape 2 : Jeton d'accès filtré par domaine.Le client MCP présente l'ID-JAG pour demander un jeton d'accès MCP définitif. À ce stade, le script de modification des jetons d'accès de PingAM se déclenche, filtrant les champs d'application demandés en fonction de l'appartenance de l'utilisateur à des groupes LDAP. Le jeton renvoyé contient à la fois l'identité de l'utilisateur et l'ensemble des champs d'application filtrés. Le client ne peut étendre aucun de ces deux éléments.
-
Étape 3 : Appel de l'outil certifié.Le serveur MCP reçoit le jeton d'accès sous forme d'identifiant « Bearer », le valide auprès du point de terminaison JWKS de PingAM et applique un contrôle d'accès basé sur les périmètres avant d'exécuter un outil.
Ce qui distingue cette délégation d'une simple usurpation d'identité, c'est la piste d'audit intégrée au jeton lui-même. Le loi La revendication figurant dans le jeton d'accès final désigne l'agent comme partie agissante, tandis que le sub La revendication identifie l'utilisateur qui a délégué l'autorisation. Tout système en aval qui consigne les revendications du jeton dispose ainsi d'un enregistrement sans ambiguïté indiquant qui a autorisé l'action et quelle instance d'agent l'a exécutée, comblant ainsi le manque de traçabilité identifié comme endémique dans les déploiements actuels d'agents.
Remarque pratique concernant la mise en œuvre : la spécification ext-auth prescrit une autorisation JWT Bearer conforme à la RFC 7523 pour l'étape 2. PingAM ne prend pas en charge la RFC 8693 public paramètre lors de l'échange de jetons d'identification ; il définit aud=client_id conformément aux conventions de l'OIDC plutôt que aud=token_endpoint_url comme l'exige le validateur JWT Bearer. Nous contournons cette contrainte en recourant à un deuxième échange de jetons plutôt qu'à un accord jwt-bearer. Il s'agit d'une contrainte propre à PingAM ; un fournisseur d'identité (IdP) qui implémente correctement le public Ce paramètre permettrait d'activer le flux défini par la spécification sans modifier le code client.
Sixième couche : SCIM en tant que couche de gouvernance d'entreprise pour les identités agentiques
Il convient d'accorder une attention particulière à l'authentification unique (SSO) et à la gestion des accès, ce qui nous amène à la conclusion suivante :
« Le protocole SCIM (System for Cross-domain Identity Management) est la norme en matière d'automatisation de la gestion du cycle de vie des utilisateurs. Cette même gestion du cycle de vie est tout aussi essentielle pour les agents eux-mêmes, qui nécessitent des processus formels pour leur création, l'octroi d'autorisations et, le cas échéant, leur mise hors service. »
Le projet expérimental de schéma d'identité des agents SCIM revêt une grande importance en tant que mécanisme permettant d'intégrer les agents dans le même modèle de provisionnement que les utilisateurs humains. Notre implémentation consiste en un serveur SCIM 2.0 de type production qui met concrètement en œuvre ce modèle.
Le agenticIdentity Le type de ressource utilise l'URN du schéma urn:ietf:params:scim:schemas:core:2.0:AgenticIdentity. Ses fonctionnalités sont spécialement conçues pour répondre aux besoins spécifiques en matière de gouvernance des identités des charges de travail :
| Attribut | Objectif |
|---|---|
| displayName | Identifiant lisible par l'homme pour l'agent |
| spiffeId | Lien SPIFFE URI reliant l'enregistrement SCIM à l'entrée de charge de travail SPIRE |
| spireEntryId | UUID interne d'entrée SPIRE, utilisé pour la désactivation |
| oAuthClientIdentifiers | Ensemble des enregistrements de clients OAuth2 associés à cette identité |
| entitlements | Définir les autorisations ou les balises d'autorisation régissant l'accès de l'agent |
| owners | Les personnes responsables du comportement de cet agent |
| active | L'agent est-il actuellement autorisé à exercer ses activités ? |
Le serveur SCIM met en œuvre l'ensemble de l'interface du protocole RFC 7644 pour agenticIdentity ressources (liste, récupération, création, modification et suppression) et transmet également les opérations standard relatives aux utilisateurs et aux groupes vers l'annuaire LDAP. Les administrateurs d'entreprise disposent ainsi d'un point de terminaison SCIM unique pour gérer à la fois les identités humaines et non humaines, en utilisant les mêmes outils et les mêmes processus de gouvernance.
Provisionnement : un seul appel API pour créer une identité de charge de travail
Lorsqu'un POST /scim/v2/AgenticIdentities Lorsqu'une requête arrive, le serveur SCIM ne se contente pas d'enregistrer les données. Il appelle directement l'API gRPC du serveur SPIRE en utilisant le BatchCreateEntry méthode permettant d'enregistrer une entrée de charge de travail avec un identifiant SPIFFE déterministe dérivé de l'UUID de l'enregistrement SCIM :
spiffe://spire.indigolabs.ca/workload/agentic/{uuid}
La réponse envoyée à l'appelant de l'API comprend l'identifiant attribué spiffeId et confirme que la charge de travail est désormais autorisée à recevoir des SVID de SPIRE. En un seul appel API, un opérateur a provisionné une identité cryptographique pour la charge de travail. Il n'y a pas de commandes CLI SPIRE manuelles, pas de génération de clés par l'opérateur, ni de secrets statiques à distribuer.
Il s'agit de l'intégration considérée comme essentielle pour une gestion évolutive des identités des agents : SCIM sert de déclencheur pour l'approvisionnement, et les systèmes d'identité en aval (SPIRE, le fournisseur OAuth2, l'annuaire LDAP) sont mis à jour automatiquement.
Désactivation : la cascade qui fait toute la différence
La désactivation des comptes n'est pas une simple formalité ; c'est un pilier fondamental de la sécurité :
« Une identité d'agent compromise qui est simplement « révoquée » peut conserver son enregistrement sous-jacent et ses relations de confiance, ce qui représente une menace latente mais persistante. La suppression des droits d'accès constitue la réponse ultime à une compromission ou à la fin de vie d'un agent. »
Le DELETE /scim/v2/AgenticIdentities/:id Le terminal met en œuvre une procédure de désactivation en cinq étapes :
-
L'entrée SPIRE a été supprimée via la fonction gRPC BatchDeleteEntry, ce qui signifie que la charge de travail ne peut plus certifier et ne peut pas recevoir de nouveau SVID.
-
Les appartenances à des groupes LDAP ont été supprimées de PingDS, de sorte que les droits de portée découlant de ces appartenances sont immédiatement révoqués.
-
Les clients OAuth2 ont été supprimés de PingAM via le point de terminaison d'enregistrement DCR, ce qui a rendu invalides les identifiants client_id existants.
-
Enregistrement marqué comme « tombstone » dans SQLite (marqué « deprovisioned=1 » avec un horodatage ; jamais supprimé définitivement afin de préserver la piste d'audit).
-
Journal d'audit contenant la liste complète des actions effectuées et, le cas échéant, une brève description.
Cette cascade déclenchée par une simple commande SCIM DELETE garantit que la désactivation d'une identité d'agent est complète, irréversible et vérifiable. La charge de travail SPIRE ne peut plus certifier. Le client OAuth2 ne peut plus s'authentifier. Les droits d'accès ont disparu. Chaque action est enregistrée. Il s'agit du signal officiel de désactivation qui doit se propager à tous les systèmes intégrés lorsqu'un agent est mis hors service.
Niveau 7 : Infrastructure déterministe sans échappatoire opérationnelle
Un argument de leadership éclairé sur l'architecture d'identité n'est crédible que si le système fonctionne réellement sans recourir à des raccourcis humains. L'un des modes de défaillance les plus courants dans les déploiements « zero-trust » est la présence de « failles de sécurité », telles que l'injection manuelle de certificats, des identifiants de démarrage codés en dur ou des scripts de configuration à usage unique qui ne sont jamais supprimés.
L'ensemble du système fonctionne à partir d'un seul docker compose up commande, sans orchestration externe, sans intervention manuelle et sans secrets fournis par l'opérateur. L'ordre de démarrage est garanti par depends_on des contrôles de santé qui sont déterministes et ne dépendent pas du temps. Le cert-init le conteneur génère tous les certificats TLS ; spire-init enregistre toutes les entrées relatives aux nœuds et aux charges de travail ; les conteneurs d'application ne démarrent qu'une fois que ces deux opérations ont été menées à bien. Le certs-data Le volume Docker constitue la seule source de confiance.
Cela va bien au-delà de la simple commodité opérationnelle. Une architecture qui oblige un utilisateur à « lancer rapidement ce script » dans un ordre précis repose sur un modèle de sécurité qui dépend du respect systématique de cette séquence. Le modèle Docker Compose rend la chaîne de confiance explicite, reproductible et vérifiable. C'est précisément ce que l'on entend par automatiser la gestion du cycle de vie des agents plutôt que de la lier étroitement au flux de travail humain.
Au démarrage, le serveur SCIM crée également des enregistrements SCIM pour les quatre charges de travail préconfigurées déjà connues de SPIRE : le client MCP, le serveur MCP, l'API de gestion et le serveur SCIM lui-même. Cela signifie que la vue de gestion des identités de l'interface utilisateur de gestion est exacte dès la première requête, et n'est pas renseignée à la demande. L'état opérationnel est cohérent dès le démarrage.
Ce que cela montre et où se situe la frontière
Il existe une distinction claire entre ce que les normes existantes permettent de résoudre efficacement et ce qui reste véritablement sans solution. Il est essentiel de déterminer où se situe cette mise en œuvre par rapport à cette distinction pour en évaluer la pertinence.
Ce que ce POC démontre aujourd'hui
-
Démarrage autonome sans secrets gérés manuellement.De l'initialisation de l'infrastructure jusqu'à l'appel d'un outil MCP entièrement authentifié, aucun intervenant humain ne communique de clé secrète à un agent. La chaîne d'attestation SPIFFE/SPIRE est la seule autorité compétente.
-
La conformité à OAuth 2.1 comme norme minimaleChaque opération liée aux jetons respecte les meilleures pratiques actuelles : PKCE, authentification client via `private_key_jwt`, échange de jetons selon la norme RFC 8693 et métadonnées de ressources protégées selon la norme RFC 9728. Le recours à des frameworks ouverts tels qu'OAuth 2.1 pour l'authentification, plutôt qu'à des mécanismes personnalisés, constitue la norme de base et non un simple objectif.
-
Une véritable délégation grâce à une chaîne d'identité vérifiableLe processus d'authentification externe génère des jetons dans lesquels l'agent et l'utilisateur sont des entités distinctes et identifiables, ce qui permet la mise en place d'une piste d'audit, élément fondamental pour des systèmes autonomes fiables.
-
Cycle de vie géré par SCIM avec suppression des droits en cascadeLe cycle de vie de l'identité agentique est régi par le même protocole de provisionnement que celui des utilisateurs humains, avec une cascade de déprovisionnement qui se propage à travers SPIRE, le fournisseur OAuth2 et l'annuaire LDAP en un seul appel API.
-
Le principe du privilège minimal est appliqué au niveau du serveur d'autorisation.Les droits d'accès découlent de l'appartenance à un groupe LDAP et sont filtrés côté serveur à chaque émission de jeton ; ils ne font pas l'objet d'une négociation entre le client et la ressource.
Les domaines où la recherche met en évidence des problèmes non résolus
Les cadres actuels, y compris cette mise en œuvre, ne résolvent pas encore tous les problèmes :
-
Atténuation de portée dans les chaînes de délégation récursivesLorsque des agents créent des sous-agents dans différents domaines de confiance, le mécanisme d'échange de jetons OAuth 2.0 offre un moyen centralisé de restreindre les autorisations. Pour les réseaux d'agents véritablement décentralisés et dynamiques, les formats de jetons basés sur les capacités, tels que les « Biscuits » et les « Macaroons » — qui permettent une atténuation hors ligne sans avoir à contacter un serveur d'autorisation central —, constituent un domaine de recherche actif.
-
Fédération interdomaines.SPIFFE/SPIRE fonctionne au sein d'une infrastructure contrôlée. Le modèle SPIFFE/SPIRE repose essentiellement sur la connaissance et la maîtrise de cette infrastructure. Lorsque les agents doivent opérer au-delà des frontières organisationnelles, là où il n'existe aucune infrastructure partagée, un autre cadre de confiance est nécessaire, tel que la fédération OpenID, les identifiants vérifiables ou les propositions émergentes relatives à l'OIDC pour les agents.
-
Gouvernance humaine évolutive et lassitude face au consentementUn problème se profile à l'horizon : les utilisateurs risquent d'être confrontés à des milliers de demandes d'autorisation à mesure que le nombre d'agents augmente. La solution proposée (« policy-as-code » pour l'autorisation des agents, autorisation dynamique basée sur les risques, CIBA pour l'approbation hors bande) n'est pas mise en œuvre dans cette démonstration de faisabilité. Elle constitue la prochaine étape logique après ce que nous avons déjà mis en place.
-
Identité du comportement de l'agentL'identité de l'agent doit à terme être enrichie de métadonnées concernant le modèle sous-jacent, la version et les capacités afin de permettre un contrôle d'accès fondé sur les risques ; il ne s'agit pas seulement de savoir en quoi consiste la charge de travail, mais aussi comment elle se comporte. Cela dépasse l'état actuel de toute norme.
S'appuyer sur les normes, et non les contourner
Les recommandations actuelles se terminent par un appel à l'action destiné à deux groupes. À l'intention des développeurs et des architectes : s'appuyer sur les bases solides des normes existantes tout en concevant des systèmes suffisamment flexibles pour intégrer les nouveaux modèles de délégation de pouvoirs. À l'intention des entreprises : commencer à considérer les agents comme des éléments à part entière de l'infrastructure IAM et mettre en place une gestion rigoureuse de leur cycle de vie.
Cette implémentation répond à ces deux enjeux. Elle démontre que les normes existantes (SPIFFE/SPIRE, RFC 7591 DCR, gestion des clients RFC 7592, échange de jetons RFC 8693, SCIM RFC 7644) suffisent aujourd’hui pour mettre en place une architecture d’identité de niveau production destinée aux agents d’IA, au sein d’un seul domaine de confiance, sans aucune extension propriétaire ni dépendance vis-à-vis d’un fournisseur.
Le système est entièrement composé de composants open source et respecte les normes IETF/W3C. SPIRE a obtenu son diplôme de la CNCF. PingAM et PingDS peuvent être remplacés par n'importe quel serveur d'autorisation compatible OAuth 2.0/OIDC et n'importe quel annuaire LDAP. Le serveur SCIM est une implémentation personnalisée, mais il utilise un protocole standard déjà pris en charge par tous les principaux fournisseurs de solutions IAM.
L'entreprise qui commence dès aujourd'hui à mettre en place une infrastructure d'identité des agents sur la base de ces normes réalise un investissement durable. Celle qui s'appuie sur un modèle de comptes de service propriétaires, ou qui ne met rien en place du tout, laissant les agents fonctionner avec des clés API codées en dur, accumule une dette d'identité qui s'alourdira à chaque nouvel agent déployé.
La fragmentation des identités d'agents constitue un risque majeur à éviter : « Les fournisseurs pourraient développer des systèmes d'identité d'agents propriétaires, ce qui ralentirait le rythme de développement en imposant des intégrations ponctuelles répétées et compromettrait la sécurité en créant de multiples modèles de sécurité. » L'alternative consistant à s'aligner sur l'attestation des charges de travail, OAuth 2.1 pour l'autorisation et SCIM pour la gestion du cycle de vie n'est pas une simple aspiration pour l'avenir. Il s'agit d'une architecture qui fonctionne dès aujourd'hui.
Résumé de l'architecture
Le tableau suivant met en correspondance chaque composant du système avec la norme qu'il met en œuvre et la recommandation à laquelle il répond :
| Component | Standard | Recommandation |
|---|---|---|
| Attestation de charge de travail SPIRE | SPIFFE / x509pop | Modèle de compte de service amélioré (§3.1) |
| Déclaration relative au logiciel JWT-SVID dans le DCR | RFC 7591 | Combler les lacunes en matière d'anonymat dans le DCR (§2.5) |
| private_key_jwt client auth | RFC 7523 | Authentifier toutes les interactions des agents (§2.14) |
| Rotation automatique des clés SVID | RFC 7592 | Identifiants à durée de vie limitée, rotation automatique (§2.8) |
| Déroulement de l'autorisation PKCE | RFC 7636 | Bonnes pratiques OAuth 2.1 (§2.4) |
| ID d'identification → ID-JAG → Jeton d'accès MCP | RFC 8693 | La délégation véritable par opposition à l'usurpation d'identité (§3.2) |
| Filtrage par groupe lors de la création | OAuth 2.1 scopes | Application du principe du privilège minimal (§2.6) |
| réclamer un jeton délégué | RFC 8693 §4.4 | Combler le déficit en matière de traçabilité (§2.11) |
| Métadonnées des ressources protégées | RFC 9728 | Externalisation de l'autorisation vers un AS dédié (§2.4) |
| Cycle de vie de l'identité agentique SCIM | RFC 7644 | SCIM pour la mise en place et la gestion des agents (§2.9) |
| Cascade de suppression des droits d'accès (SPIRE + LDAP + OAuth2) | RFC 7644 DELETE | Signal formel de déprovisionnement (§3.2) |
| Fiche de contrôle avec journal des actions | Bonnes pratiques en matière d'IGA | Tenir à jour des pistes d'audit claires (§2.14) |
Pour en savoir plus
- Gestion des identités pour l'IA agentique : Fondation OpenID, octobre 2025
- Documentation SPIFFE/SPIRE
- Profilage d'interopérabilité pour une identité sécurisée en entreprise (IPSIE)
- RFC 7591 : Protocole d'enregistrement dynamique des clients OAuth 2.0
- RFC 7592 : Protocole de gestion de l'enregistrement dynamique des clients OAuth 2.0
- RFC 7523 : Profil JWT pour l'authentification des clients OAuth 2.0 et les autorisations
- RFC 8693 : Échange de jetons OAuth 2.0
- RFC 7644 : Système de gestion des identités interdomaines : protocole
- RFC 9728 : Métadonnées des ressources protégées OAuth 2.0
- EXT-Auth : Extension d'autorisation MCP