Donnez une identité à vos agents !

L’essor des systèmes agentiques fait apparaître une nouvelle question d’architecture : il ne suffit plus de savoir qui agit. Il faut désormais savoir au nom de qui, avec quelle autorité, dans quel contexte et pour combien de temps.

Il y a quelques semaines, nous utilisions dans ces pages l’image d’un bâtiment.

Avec eBPF, nous nous étions intéressés au tourniquet : cet endroit très concret où une règle de sécurité cesse d’être une intention pour devenir un contrôle réellement appliqué. Un registre peut parfaitement indiquer qu’une porte doit rester fermée ; encore faut-il qu’un mécanisme soit effectivement capable d’en empêcher l’ouverture.

Puis, avec SPIFFE, nous nous étions intéressés au badge. Dans un système distribué où les Pods disparaissent, où les instances changent de machine et où les adresses IP ne constituent plus une identité fiable, reconnaître un service suppose de dissocier ce qu’il est de l’endroit où il s’exécute. L’identité du workload doit survivre aux transformations de son environnement.

Ces deux questions restent entières avec l’arrivée des agents d’intelligence artificielle.

Mais une troisième vient désormais s’y ajouter.

Que se passe-t-il lorsque celui qui présente le badge n’est plus seulement un programme exécutant une logique prédéterminée, mais un système capable de choisir lui-même une partie des actions nécessaires à l’accomplissement d’une mission ?

La nuance peut sembler ténue. Elle change pourtant profondément le problème.

Un service de paiement possède une identité parce qu’il constitue un composant du système d’information. Un agent possède lui aussi une identité technique, mais il peut également recevoir une mission d’un utilisateur, sélectionner des outils, interroger plusieurs sources de données, appeler d’autres agents et composer une séquence d’actions qui n’avait pas nécessairement été déterminée au moment de son déploiement.

La question n’est donc plus seulement :

Quel workload appelle cette API ?

Elle devient progressivement :

Quel agent agit ? Au nom de qui ? Pour quelle tâche ? Avec quelle autorité ? Jusqu’à quand ? Et quelle part de cette autorité peut-il à son tour déléguer ?

C’est autour de ces questions qu’une architecture de confiance propre aux systèmes agentiques commence aujourd’hui à se dessiner.

Une instruction donnée au modèle n’est pas une frontière de sécurité

Tant que les agents restent cantonnés à des démonstrateurs ou à la génération de texte, cette question peut paraître théorique.

Elle cesse immédiatement de l’être lorsqu’on leur ouvre les portes du système d’information.

Messagerie, SharePoint, CRM, référentiels documentaires, GitHub, ERP, bases de données ou infrastructures cloud : à mesure que l’agent acquiert des outils, ses erreurs potentielles changent de nature. Une mauvaise réponse n’est plus seulement un texte inexact. Elle peut devenir une action.

La recherche sur la sécurité des agents a déjà mis en évidence cette différence.

Le benchmark AgentDojo, présenté à NeurIPS 2024, étudie des agents capables d’utiliser des outils dans des scénarios proches d’usages réels. Il montre notamment qu’une information consultée par l’agent — un courriel, une page ou la sortie d’un outil — peut elle-même contenir une instruction hostile et infléchir son comportement.

Agent Security Bench, publié à ICLR 2025, élargit cette analyse à différents environnements, outils et vecteurs d’attaque. Là encore, les vulnérabilités ne se concentrent pas uniquement dans le modèle : elles apparaissent dans la manière dont l’agent traite le contexte, utilise ses outils ou conserve des informations.

Ces travaux ne démontrent pas que les agents seraient, par nature, incontrôlables.

Ils rappellent quelque chose de beaucoup plus utile pour l’architecte :

une décision produite par un modèle n’est pas une décision d’autorisation.

Un agent peut raisonnablement conclure :

« Pour accomplir cette tâche, je dois modifier cette ressource. »

Cela ne signifie pas pour autant :

« Je suis autorisé à modifier cette ressource. »

Cette distinction, simple en apparence, devrait devenir l’un des principes fondateurs des systèmes agentiques.

Nous retrouvons d’ailleurs ici le problème que nous avions abordé dans notre article consacré à eBPF : définir une règle et disposer d’un mécanisme capable de la faire respecter sont deux choses différentes.

Avec les agents, il faut désormais ajouter une étape intermédiaire : décider si l’action proposée doit effectivement être autorisée.

Le NIST commence à formaliser le problème

Cette évolution n’est plus uniquement discutée dans les laboratoires ou chez les éditeurs.

En février 2026, le National Cybersecurity Center of Excellence du NIST a ouvert une consultation consacrée à l’identité et à l’autorisation des logiciels et agents d’intelligence artificielle. Plus de 600 contributions ont été reçues de l’industrie, du secteur public et du monde académique.

La synthèse des commentaires, annoncée le 29 septembre 2026, est particulièrement intéressante parce qu’elle ne dessine pas un nouveau produit IAM. Elle révèle au contraire une certaine continuité avec les architectures existantes.

Les contributeurs privilégient largement la réutilisation des mécanismes déjà éprouvés : identité de workload, OAuth, politiques d’autorisation, Zero Trust, credentials courts et décisions contextuelles.

Autrement dit, l’arrivée des agents ne rend pas caducs les investissements déjà réalisés dans l’IAM.

Elle les met à l’épreuve.

C’est une différence importante pour les entreprises.

Le sujet n’est pas nécessairement de créer un « annuaire des agents » isolé du reste du système d’information. Il s’agit plutôt de permettre aux infrastructures d’identité existantes de représenter des relations qu’elles modélisaient jusqu’ici imparfaitement : la délégation, le contexte d’une mission, la durée d’une autorisation ou encore la chaîne reliant un utilisateur à l’action finalement exécutée.

Cette synthèse restitue des contributions et prépare un projet de démonstration ; elle ne constitue pas une norme finale.

Cette évolution prolonge directement le mouvement Zero Trust.

Dans ses travaux sur les architectures cloud-native — SP 800-207A, le NIST recommandait déjà de déplacer la confiance de la localisation réseau vers l’identité du service ou du workload. C’était précisément le sujet que nous avions exploré avec SPIFFE : ne plus considérer l’adresse IP ou le nœud d’exécution comme une preuve d’identité suffisante.

L’agent ajoute aujourd’hui une nouvelle dimension.

Il ne suffit plus de connaître son identité.

Il faut connaître l’autorité qu’il transporte.

Du badge à la lettre de mission

C’est probablement la meilleure façon de prolonger l’image utilisée dans notre précédent article sur SPIFFE.

SPIFFE fournit au workload quelque chose qui ressemble à un badge vérifiable.

Il répond à la question :

Qui es-tu ?

Mais lorsqu’un agent arrive devant une application métier, cette information ne suffit plus toujours.

Il faut également pouvoir répondre à :

Pourquoi es-tu là ?

Pour qui agis-tu ?

Qu’as-tu le droit de faire dans le cadre de cette mission précise ?

Le badge doit désormais s’accompagner d’une lettre de mission.

Cette évolution apparaît d’ailleurs dans la roadmap de SPIFFE du 18 août 2026. Le projet travaille notamment sur des mécanismes permettant de transporter du contexte tout au long d’une transaction : l’origine d’une requête, le principal pour lequel une opération est réalisée ou encore sa finalité.

Ce n’est pas anodin.

SPIFFE avait initialement contribué à répondre à une difficulté des architectures distribuées :

comment reconnaître durablement un workload dans une infrastructure où tout est éphémère ?

Les architectures agentiques posent désormais une question complémentaire :

comment conserver l’histoire de l’autorité lorsque l’action traverse plusieurs workloads et plusieurs agents ?

C’est le passage de l’identité à l’autorité déléguée.

Alice, son agent et l’ERP

Prenons un exemple beaucoup plus concret.

Alice travaille à la direction des achats. L’entreprise met à sa disposition un agent capable d’analyser les devis validés, de vérifier certaines informations puis de préparer les commandes correspondantes dans l’ERP.

Alice lui demande :

« Prépare les commandes correspondant aux devis validés aujourd’hui. »

La solution techniquement la plus simple consisterait à permettre à l’agent d’utiliser directement l’identité ou les credentials d’Alice.

Le système fonctionnerait.

Mais une information fondamentale aurait disparu.

Lorsque l’ERP recevrait la requête, il verrait Alice.

Il ne saurait plus distinguer une opération qu’elle a effectuée elle-même d’une opération choisie et exécutée par un logiciel agissant pour son compte.

Or ces deux situations ne sont pas équivalentes.

L’architecture devrait pouvoir conserver plusieurs niveaux d’identité :

Alice
   │
   │ confie une mission
   ▼
Agent Achats
   │
   │ s'exécute sous
   ▼
Workload agent-achats-prod
   │
   │ reçoit une autorité temporaire
   ▼
ERP

Alice reste le principal à l’origine de la demande.

L’Agent Achats est l’acteur auquel une mission a été confiée.

Le workload représente l’instance logicielle qui exécute réellement l’opération.

Enfin, le credential utilisé auprès de l’ERP matérialise l’autorité accordée pour cette action particulière.

Cette distinction est moins exotique qu’elle n’en a l’air.

OAuth dispose déjà, avec la RFC 8693 consacrée au Token Exchange, d’un moyen de distinguer le subject, au nom duquel une opération est réalisée, de l’actor, qui l’exécute réellement.

Autrement dit, une partie du vocabulaire nécessaire aux agents existe déjà.

C’est également l’idée portée par les travaux récents de l’IETF autour d’AIMS — AI Identity Management System : plutôt que construire une nouvelle pile d’identité entièrement spécifique aux agents, composer les standards existants de workload identity et de délégation.

AIMS reste à ce stade un Internet-Draft du groupe WIMSE, et non une RFC publiée.

Pour un CTO, c’est une conclusion importante.

Introduire des agents dans le système d’information ne signifie pas nécessairement reconstruire l’IAM.

Il faut surtout cesser de confondre l’utilisateur, l’agent et le workload qui exécute l’agent.

Une identité peut durer ; son pouvoir, beaucoup moins

Cette distinction conduit à un second principe.

L’identité d’un agent peut être relativement stable.

Son autorité devrait souvent être éphémère.

Un agent-achats-europe peut exister plusieurs années. L’entreprise peut lui associer un propriétaire, une finalité, une version, une politique de sécurité ou une équipe responsable.

En revanche, l’autorisation lui permettant de consulter trois devis et de préparer une commande n’a aucune raison de subsister pendant plusieurs mois.

C’est précisément l’un des points qui ressort des travaux récents du NIST : associer un ancrage d’identité durable à des credentials et des droits beaucoup plus courts.

Pour notre agent Achats, l’autorisation pourrait conceptuellement ressembler à ceci :

Agent       : achats-europe
Mandant     : Alice
Mission     : préparation des commandes du 6 octobre
Ressource   : ERP / commandes
Action      : création d'un brouillon
Plafond     : 20 000 €
Expiration  : 09:17, heure de Paris

À 9 h 18, cette autorité n’est plus valide, à condition que le point de contrôle vérifie effectivement l’expiration avant d’autoriser l’opération.

L’agent existe toujours.

Son pouvoir, lui, n’existe plus.

Cette manière de raisonner peut sembler plus complexe que le traditionnel compte de service doté d’un rôle permanent. Elle est pourtant beaucoup plus adaptée à des systèmes capables d’agir avec une certaine autonomie.

Et là encore, les primitives ne sont pas toutes nouvelles. OAuth permet déjà de restreindre un token à une ressource particulière — RFC 8707 ou d’exprimer des demandes d’autorisation plus riches qu’un simple scope générique — RFC 9396. Leur interprétation et leur application restent du ressort des serveurs d’autorisation et des applications concernées.

Les agents ne créent donc pas toujours de nouveaux mécanismes.

Ils rendent surtout beaucoup plus coûteux le fait de ne pas utiliser correctement ceux dont nous disposons déjà.

Quand les agents délèguent à d’autres agents

La difficulté augmente encore lorsqu’un agent en appelle un autre.

Nous avions récemment abordé, à travers le semantic drift, un risque différent des architectures multi-agents : deux agents peuvent chacun raisonner correctement selon leur propre représentation du problème et produire malgré tout une décision collective erronée lorsque leurs interprétations divergent progressivement.

L’identité ne résout évidemment pas cette difficulté sémantique.

Mais elle peut éviter qu’elle soit aggravée par une propagation incontrôlée des permissions.

Reprenons notre scénario.

L’Agent Achats prépare une commande, puis sollicite un Agent Finance afin de vérifier que le budget du centre de coûts est disponible.

L’Agent Finance n’a aucune raison d’hériter du droit de créer une commande.

La chaîne devrait au contraire ressembler à ceci :

Alice
   ↓
Agent Achats
Préparer une commande ≤ 20 000 €
   ↓
Agent Finance
Consulter le budget concerné
   ↓
ERP Finance
Lecture uniquement

À chaque délégation, l’autorité se réduit.

La synthèse des commentaires publiée par le NIST emploie notamment le terme attenuation pour décrire cette propriété : un sous-agent ne devrait pas recevoir mécaniquement l’ensemble des privilèges de celui qui l’appelle.

Cette règle paraît évidente.

Elle ne l’est pourtant pas dans beaucoup de systèmes actuels, où un même secret ou compte technique circule entre plusieurs composants.

L’arrivée des agents transforme alors une dette d’architecture autrefois tolérable en risque beaucoup plus visible.

Pour une entreprise qui envisage des systèmes multi-agents, une question très simple devient donc révélatrice :

Lorsqu’un agent délègue sa tâche, délègue-t-il également tous ses droits ?

Si la réponse est oui, le problème est probablement déjà architectural avant même d’être lié à l’IA.

Le modèle propose, l’architecture dispose

C’est ici que nous retrouvons le tourniquet.

Un agent peut construire un raisonnement, déterminer qu’une action semble nécessaire et appeler un outil.

Mais il ne devrait jamais être juge de sa propre autorisation.

Le modèle propose.

Une politique décide.

Un mécanisme d’enforcement applique cette décision.

Cette séparation constitue probablement l’un des patterns les plus importants des architectures agentiques.

Elle permet notamment de conserver une partie déterministe dans un système dont le raisonnement peut être probabiliste.

Imaginons qu’un agent veuille supprimer une base de données de test.

Le modèle peut expliquer pourquoi cette opération lui semble pertinente.

Mais la politique peut simplement répondre :

DELETE database
IF environment = production
THEN deny

Aucun raisonnement du modèle ne devrait pouvoir transformer cette interdiction en recommandation facultative.

C’est précisément ce qui rend intéressants les travaux récents autour de NVIDIA OpenShell.

OpenShell cherche à déplacer certains contrôles hors du processus de l’agent : accès aux fichiers, aux processus ou au réseau peuvent être limités par l’environnement d’exécution lui-même.

Le Policy Prover traite parallèlement un autre problème : vérifier certaines propriétés de la politique définie. Ses garanties se limitent aux comportements et aux fonctionnalités représentés dans son modèle ; une politique vérifiée ne prouve pas, à elle seule, que l’environnement d’exécution l’applique correctement.

Nous retrouvons ici exactement le raisonnement que nous avions commencé avec eBPF :

décrire une permission, vérifier qu’elle respecte certaines contraintes et faire effectivement respecter cette permission sont trois fonctions différentes.

Les confondre reviendrait à considérer qu’un panneau « accès interdit » et une porte verrouillée fournissent la même garantie.

Et dans un système d’information qui existe déjà ?

C’est probablement la question la plus importante pour un dirigeant.

Les architectures idéales sont relativement simples à dessiner lorsque tout est moderne : workloads cloud-native, OAuth partout, API propres, politiques centralisées.

Mais le système d’information réel ressemble rarement à cela.

Il comporte des ERP anciens, des applications SOAP, des bases de données protégées par des comptes techniques, des scripts historiques, des applications SaaS, plusieurs annuaires, des API gateways et parfois plusieurs générations successives d’architectures.

Attendre la modernisation complète de cet ensemble avant d’introduire des agents serait irréaliste.

La trajectoire la plus pragmatique consiste alors à moderniser les frontières avant de moderniser l’intégralité du patrimoine.

Prenons une application ancienne qui ne sait accepter qu’un compte technique.

L’erreur serait de transmettre ce compte directement à l’agent.

On peut au contraire introduire un intermédiaire :

Agent
   │
   │ identité + délégation
   ▼
Identity / Access Broker
   │
   │ politique
   │ traduction de credential
   ▼
Application historique

Le broker comprend l’identité moderne de l’agent et la mission qui lui a été confiée.

Il vérifie l’autorisation.

Puis il utilise, derrière cette frontière, le credential attendu par l’application historique.

L’agent n’accède jamais directement au secret legacy.

Cette approche possède une vertu considérable : l’application ancienne n’a pas besoin de devenir elle-même « compatible avec les agents ».

Elle reste ce qu’elle est.

La modernisation se concentre d’abord sur les points de passage.

Pour beaucoup d’entreprises, ce pattern pourrait constituer une trajectoire beaucoup plus réaliste que le remplacement immédiat des applications historiques.

Le problème suivant : expliquer après coup pourquoi l’action était permise

Une fois l’identité et l’autorité correctement séparées, une nouvelle difficulté apparaît.

Après un incident ou lors d’un audit, savoir que :

« l’Agent Achats a créé la commande à 9 h 12 »

ne suffira probablement plus.

Il faudra reconstruire toute l’histoire :

• qui avait initié la demande ;
• quel agent avait reçu la mission ;
• quel workload l’avait exécutée ;
• quelle autorité lui avait été déléguée ;
• quelle politique avait autorisé l’opération ;
• et dans quel contexte cette décision avait été prise.

C’est là que les problématiques d’identité rejoignent progressivement celles de provenance et d’attestation que nous avons également commencé à explorer dans nos travaux sur les chaînes CI/CD.

Nous y avions déjà rencontré une distinction comparable.

Produire une signature ou une attestation ne suffit pas si personne ne la vérifie avant l’utilisation de l’artefact. De la même façon, connaître l’identité d’un agent ne suffit pas si nous ne sommes pas capables de démontrer sous quelle autorité il a exécuté une opération.

Dans les deux cas, la confiance ne repose pas sur un objet isolé.

Elle repose sur une chaîne de preuves.

L’identité des agents rapproche ainsi progressivement des disciplines longtemps traitées séparément : IAM, workload identity, autorisation, sécurité runtime, observabilité, provenance et attestation.

Ce rapprochement mérite probablement à lui seul un prochain article.

Ce qu’un CEO ou un CTO doit réellement demander

À ce stade, un dirigeant n’a pas besoin de choisir entre SPIFFE, OAuth Token Exchange ou différents moteurs de politiques.

La technologie viendra ensuite.

La première question est beaucoup plus simple :

Si nous autorisons demain un agent à agir dans notre système d’information, savons-nous encore expliquer précisément quel pouvoir nous lui avons donné ?

Un CTO devrait pouvoir suivre une chaîne lisible :

utilisateur ou organisation → agent → workload → délégation → permission → action.

Et cette chaîne doit rester intelligible lorsque plusieurs agents interviennent.

Peut-on distinguer l’agent de l’utilisateur qu’il représente ?

Peut-on révoquer l’agent sans bloquer l’utilisateur ?

Ses droits disparaissent-ils avec la mission ?

Un sous-agent reçoit-il moins de droits que son parent ?

Une application sensible peut-elle refuser une opération malgré la décision de l’agent ?

Peut-on, après coup, expliquer pourquoi cette opération a été autorisée ?

Ces questions ne sont pas seulement utiles pour les futurs projets d’IA.

Elles constituent aussi un excellent révélateur de l’état actuel du système d’information.

Comptes techniques partagés, secrets persistants, autorisations trop larges, impossibilité d’identifier l’acteur réel derrière une API : les agents ne créent pas nécessairement ces faiblesses.

Ils les rendent beaucoup plus difficiles à accepter.

Du tourniquet à la chaîne d’autorité

Notre réflexion avait commencé par les portes.

Avec eBPF, nous cherchions le point où une politique pouvait effectivement devenir un contrôle.

Avec SPIFFE, nous avions ajouté le badge permettant de reconnaître un workload dans un environnement en perpétuel mouvement.

Les systèmes agentiques obligent désormais à ajouter une information supplémentaire à ce badge :

la mission.

Qui agit ?

Pour qui ?

Dans quel but ?

Avec quelle autorité ?

Et jusqu’à quand ?

Les travaux actuellement conduits par le NIST, l’IETF ou SPIFFE ne constituent pas encore une architecture universelle de l’identité agentique. Le domaine reste jeune, les standards évoluent et plusieurs choix techniques demeurent ouverts.

Mais une structure apparaît peu à peu :

IDENTITÉ
    ↓
DÉLÉGATION
    ↓
AUTORISATION
    ↓
ENFORCEMENT
    ↓
PREUVE

Aucune de ces briques n’est réellement nouvelle.

Workload identity, OAuth, mTLS, policy engines, gateways, attestations et contrôles runtime existaient avant les agents.

La nouveauté réside ailleurs.

Nous devons désormais les faire fonctionner comme une chaîne cohérente.

Avec le cloud-native, nous avions progressivement appris à ne plus déduire l’identité d’un système de son emplacement sur le réseau.

Les agents nous obligent aujourd’hui à franchir une étape supplémentaire :

ne plus déduire son autorité de sa seule identité.

Savoir qui agit restera indispensable.

Mais dans un système où les logiciels peuvent recevoir des missions, déléguer des tâches et prendre une partie de leurs décisions eux-mêmes, cela ne suffira plus.

Il faudra également savoir d’où vient leur pouvoir, jusqu’où il s’étend et qui est capable de l’arrêter.