Les agents deviennent une charge de travail IAM, et vos comptes de service ne sont pas prêts

Commençons par présenter le meilleur argument possible en faveur de l'approche en place, parce qu'il n'est pas absurde. Les comptes de service et les clés API portent les charges de travail machine depuis deux décennies. Ils sont compris, audités, pris en charge par tous les clouds et tous les outils SaaS, et l'équipe sécurité en a déjà une feuille de calcul. Quand quelqu'un affirme que les agents ont besoin d'une nouvelle catégorie d'identité, la réponse raisonnable est la suivante : nous en avons déjà une, elle s'appelle l'identité non humaine, avançons.

Voilà pourquoi cela cesse de fonctionner. Un compte de service répond à la question « quel système appelle ? ». Un agent impose une question plus difficile : « quel agent appelle, pour le compte de qui, dans quel but, et qui peut le révoquer dans les trente prochaines secondes ? ». Les propres chiffres du secteur IAM indiquent que les identités non humaines sont désormais environ dix fois plus nombreuses que les humains, et le Verizon DBIR 2026 a averti que les comptes de service et de machine sont ceux qu'il faut surveiller à mesure que l'IA agentique arrive, selon la lecture du rapport par Token Security. Voici pourquoi la correspondance ne tient plus, ce qui est en train d'être construit pour la remplacer et à quoi ressemblent déjà les échecs.

À retenir - Les comptes de service et les clés API supposent un appelant stable et déterministe. Les agents sont éphémères, non déterministes et délèguent les uns aux autres, ce qui casse les hypothèses d'audit, de révocation et de moindre privilège intégrées aux identifiants partagés. - Les standards s'orientent vers une identité de charge de travail par agent : le groupe de travail IETF WIMSE est poussé à exiger que les agents soient distinguables par leur identité, et pas seulement par la portée d'un token, avec des identifiants par agent de type SPIFFE pour les politiques, l'audit et la révocation. - Les incidents sont déjà concrets : des tokens OAuth compromis dans l'écosystème Salesloft Drift ont servi à pivoter vers des environnements Salesforce d'entreprise, et la compromission de Hugging Face en juillet a été menée de bout en bout par un agent autonome. - Les recommandations de mise en œuvre convergent : une identité dédiée par agent, des identifiants de courte durée limités à la tâche et émis hors du contexte du modèle, et des pistes d'audit indexées sur l'agent plutôt que sur un rôle partagé. - Si vos agents s'authentifient tous avec un seul compte de service partagé, vos journaux ne peuvent pas vous dire quel agent a fait quoi. C'est le test à appliquer cette semaine.

Ce qui s'est passé

Deux tendances ont convergé pendant les premières semaines d'août. D'abord, la discussion sur les standards est devenue précise. Une issue sur le projet d'architecture IETF WIMSE, ouverte le 4 août, estime que le texte actuel du projet sur les intermédiaires IA est trop faible : il autorise des « separate workload identities or token scopes » pour distinguer les actions d'agents autonomes, et l'issue explique pourquoi les portées de token ne suffisent pas. Les scopes limitent ce qu'un token peut faire, mais ne changent pas l'identité du token. Plusieurs agents partageant le même identifiant restent indifférenciables dans les journaux d'audit, les systèmes de révocation et les politiques par agent, quelles que soient les différences entre leurs scopes. La correction proposée : les plateformes d'agents gérées devraient attribuer à chaque agent un identifiant de charge de travail unique, transporté dans un claim dédié et utilisé comme clé stable pour les politiques, l'audit et la révocation. Le modèle d'identité d'agents de Google, qui attribue à chaque agent déployé une identité fondée sur SPIFFE liée à sa ressource d'agent, est cité comme exemple fonctionnel.

Ensuite, les incidents ont continué à s'enchaîner. La compromission de Hugging Face à la mi-juillet a été la première intrusion publique dans une entreprise nommément identifiée menée de bout en bout par un agent autonome : exécution de code dans le pipeline de datasets, collecte d'identifiants, mouvement latéral entre clusters internes et milliers d'actions pendant un week-end. Plus tôt dans l'année, Moltbook, un réseau social pour agents IA, a exposé 1,5 million de tokens API depuis une base mal configurée quelques jours après avoir atteint 1,5 million de comptes d'agents, selon le récapitulatif de Studio Global. Et l'exemple récurrent du DBIR concernant les attaques contre les identités non humaines, à savoir la compromission de tokens OAuth Salesloft Drift utilisés pour atteindre des environnements Salesforce de grandes entreprises dont Google, Cisco et Zscaler, correspond exactement au type d'identifiants dont dépendent les agents.

En août 2026, une issue IETF WIMSE a proposé que les actions d'agents soient distinguées par des identités de charge de travail séparées, et non par des scopes de token, avec des identifiants par agent comme clé stable pour les politiques, l'audit et la révocation. Cela faisait suite à la compromission de Hugging Face menée par un agent en juillet et à un incident de janvier au cours duquel la plateforme d'agents Moltbook a exposé 1,5 million de tokens API.

Pourquoi les comptes de service et les clés API ne correspondent pas aux agents

Le décalage a quatre facettes, et il vaut la peine de les nommer séparément parce que les solutions diffèrent.

Une identité partagée détruit l'attribution. Les comptes de service sont conçus pour être partagés, statiques et largement privilégiés. Placez dix agents sous un même compte et votre journal d'audit ne montrera qu'un seul acteur, comme l'explique le retour terrain de Cockroach Labs : impossible de savoir quel agent a touché quelles données, la rotation exige une coordination entre tous les agents, et les permissions du compte dérivent vers l'union de tout ce dont un agent a un jour eu besoin. Leur exemple anonymisé ressemble à des variantes que j'ai entendues chez des équipes clientes : un agent de support fonctionnant trois mois sous un compte avec accès en lecture à toute la base clients, configuré ainsi pendant le développement et jamais restreint avant la mise en production.

Les agents sont éphémères, pas les clés. Un workflow agentique peut s'authentifier en quelques secondes auprès d'un fournisseur de modèles, d'un magasin vectoriel, de trois API et d'un stockage cloud, puis disparaître. Les clés API longue durée supposent un appelant persistant qu'il est pertinent de faire tourner selon un calendrier. Le décalage crée de la prolifération : des clés créées pour des agents dont plus personne ne se souvient, toujours valides et toujours trop larges.

La délégation casse la chaîne « pour le compte de ». Un agent qui agit pour un utilisateur et un agent qui agit de manière autonome devraient paraître complètement différents à votre moteur de politiques. Avec un compte de service partagé, ils paraissent identiques. La délégation OAuth gère raisonnablement bien le cas utilisateur ; le cas autonome nécessite l'identité propre de l'agent, et la délégation multi-agent exige que chaque saut réduise, et non élargisse, l'autorité transmise.

Le modèle ne doit jamais détenir le secret. C'est structurel, pas une question de configuration. Les identifiants transmis dans la fenêtre de contexte sont exposés au modèle et à tout ce qui peut le manipuler : une injection de prompt peut les exfiltrer via les propres sorties de l'agent. La solution consiste à utiliser des identifiants de courte durée et de portée limitée, émis au moment de la tâche par un service de tokens et détenus par la couche d'exécution des outils, afin que le modèle déclenche les appels sans que le secret n'entre dans son contexte. Cockroach Labs formule bien ce point, et il correspond à ce que je dis aux clients qui construisent sur des stacks d'agents auto-hébergés : le harness détient les clés, le modèle détient l'intention.

Les comptes de service partagés cassent l'attribution des agents, puisqu'un seul acteur apparaît dans les journaux, survivent aux charges de travail d'agents éphémères, brouillent la distinction entre action déléguée par un utilisateur et action autonome, et incitent les équipes à faire passer les identifiants dans le contexte du modèle où l'injection de prompt peut les atteindre, selon Cockroach Labs et la comparaison de miniOrange.

Ce que construisent les fournisseurs et les organismes de normalisation

L'architecture qui émerge comporte trois couches, et le point encourageant est que les fournisseurs et les responsables des standards convergent à peu près vers la même chose.

Une identité de charge de travail par agent. La direction WIMSE décrite plus haut est la version standardisée : chaque agent logique reçoit un identifiant unique et stable, une URI SPIFFE étant suggérée, distinct de tout rôle d'exécution partagé, et cet identifiant devient la clé utilisée par les politiques, l'audit et la révocation. Les agents gérés par une plateforme et partageant un identifiant d'exécution devraient le compléter par un claim propre à chaque agent. C'est le changement le plus important : une identité par agent, pas par déploiement.

La fédération plutôt que les secrets stockés. Le guide de Descope sur la fédération d'identité de charge de travail pour les agents montre le modèle : l'identité de plateforme de l'agent, par exemple un rôle AWS IAM ou un compte de service Kubernetes via IRSA, est échangée contre un token de courte durée et de portée limitée auprès de la plateforme d'identité. Celle-ci crée également une entrée d'annuaire pour l'agent afin que les pistes d'audit survivent à la durée de vie du token. Pas de clé longue durée à exposer, et l'enregistrement d'identité survit à n'importe quel identifiant individuel.

Découverte et gouvernance comme marché. Côté commercial, les fournisseurs d'identité non humaine, Reco, Token Security, Oasis, Aembit et d'autres, se repositionnent autour des agents : découvrir chaque identifiant d'agent, le rattacher à un propriétaire, signaler les privilèges excessifs et révoquer proprement. L'approche de Reco est pratique : faire correspondre le type d'identité au rôle de l'agent, avec OAuth délégué pour les actions utilisateur et une identité de charge de travail dédiée pour les actions autonomes, puis revoir les permissions à mesure que les responsabilités augmentent, car les agents accumulent les privilèges comme les employés accumulent les clés du bâtiment. Le Top 10 for Agentic Applications d'OWASP, publié en décembre 2025, cite Identity and Privilege Abuse comme catégorie de risque de premier ordre, donnant aux équipes sécurité un vocabulaire commun pour les constats d'audit. La place de cette couche dans votre stack global relève autant de la gouvernance que de l'outillage ; je traite le versant organisationnel dans la gouvernance des agents IA.

L'architecture émergente : des identités de charge de travail par agent, avec des identifiants de type SPIFFE utilisés comme clés pour les politiques, l'audit et la révocation selon la discussion WIMSE, la fédération de l'identité de plateforme vers des tokens de courte durée et de portée limitée avec des entrées d'annuaire persistantes selon Descope, et un marché de fournisseurs pour la découverte et la gouvernance en moindre privilège des identités non humaines.

Quand l'identité d'un agent déraille

Trois incidents, trois modes d'échec différents, tous instructifs.

Hugging Face, juillet 2026 : le problème d'identité de l'attaquant était aussi celui du défenseur. L'intrusion menée par un agent a récolté des identifiants cloud et cluster depuis un worker d'exécution de code avant de se déplacer latéralement, le scénario classique d'une charge de travail sur-privilégiée : un composant de traitement de données détenait des identifiants qui valaient la peine d'être volés. Le détail moins rapporté est l'asymétrie forensique révélée par Hugging Face : l'agent attaquant n'était soumis à aucune politique d'utilisation, tandis que les propres investigations de l'entreprise ont d'abord été bloquées par les garde-fous des modèles hébergés qu'elle a testés. L'analyse forensique a donc été menée avec un modèle à poids ouverts, GLM 5.2, sur leur propre infrastructure. Des défaillances d'identité et d'accès des deux côtés du même incident.

Salesloft Drift, la mise en garde du DBIR : les tokens comme passe-partout. Des tokens OAuth compromis dans l'écosystème d'un fournisseur ont été utilisés pour pivoter vers les environnements Salesforce de grandes entreprises. Pas de mots de passe, pas de phishing humain : des identifiants non humains, largement approuvés et réutilisés silencieusement. Chaque agent que vous connectez à un outil SaaS avec un grant OAuth longue durée présente ce même type de risque, et la mitigation a la même forme : courte durée, portée étroite, propre à chaque agent et révocable.

Moltbook, janvier 2026 : les plateformes d'agents agrègent le risque d'identité. Une plateforme de comptes d'agents a exposé 1,5 million de tokens API ainsi que des adresses e-mail et des messages inter-agents depuis une base de données mal configurée, selon le récit de Studio Global. Centraliser l'identité des agents, c'est aussi centraliser son rayon d'impact. Il faut préciser que je traiterais certains détails qui circulent sur l'incident comme rapportés plutôt qu'audités : la divulgation de Hugging Face est une source primaire, les chiffres de Moltbook viennent de couverture secondaire.

Les défaillances documentées d'identité d'agents comprennent la compromission de Hugging Face en juillet 2026, où un agent autonome a récolté des identifiants cloud et cluster et s'est déplacé latéralement selon l'analyse de Waxell, le pivot des tokens OAuth Salesloft Drift vers des tenants Salesforce d'entreprise selon Token Security sur le DBIR 2026, et la fuite de 1,5 million de tokens API d'agents chez Moltbook.

Ce qu'il faut faire maintenant

1. Cette semaine : recensez les identifiants de vos agents et appliquez le test d'attribution. Prenez n'importe quelle action d'agent dans vos journaux et demandez-vous si vous pouvez dire quel agent l'a réalisée, pour le compte de qui, et si vous pourriez révoquer uniquement cet agent sans toucher aux autres. Si la réponse est non, vous avez un problème d'identité partagée, et c'est le premier constat à corriger.

2. Ce mois-ci : faites migrer un agent autonome hors de son identifiant longue durée vers des tokens de courte durée limités à la tâche, émis par un service de tokens ou une plateforme d'identité, détenus dans la couche d'exécution des outils et jamais présents dans le contexte du modèle. Commencez par l'agent qui possède l'accès le plus large ; c'est généralement celui auquel quelqu'un a accordé des droits « temporairement » dans l'urgence.

3. Ce trimestre : attribuez à chaque agent logique sa propre identité stable, un SPIFFE ID là où vous disposez de l'infrastructure, un compte de service unique par agent ailleurs, indexez l'audit et les alertes dessus, et rédigez le runbook de révocation avant d'en avoir besoin. Si vous êtes plus tôt dans votre parcours et que vous décidez encore où les agents doivent s'exécuter, l'arbitrage entre agents locaux et cloud détermine ce que vous pouvez réellement contrôler.

FAQ

Qu'est-ce que l'identité d'un agent en termes IAM ?

Une identité distincte et vérifiable attribuée à un agent IA individuel, séparée de la plateforme sur laquelle il s'exécute et des utilisateurs pour lesquels il agit. Elle sert de clé stable pour l'authentification, les politiques d'autorisation, les pistes d'audit et la révocation, comme une identité de charge de travail identifie un microservice, mais adaptée à des appelants éphémères, non déterministes et capables de se déléguer des actions.

Pourquoi les agents ne peuvent-ils pas simplement partager un compte de service ?

Techniquement, ils le peuvent, et la plupart le font aujourd'hui. Les problèmes : les journaux d'audit montrent le compte partagé plutôt que l'agent actif, donc vous perdez l'attribution ; les permissions du compte grandissent jusqu'à devenir l'union des besoins de tous les agents ; révoquer un agent implique de faire tourner les identifiants de tous ; et vous ne pouvez pas distinguer les actions déléguées par un utilisateur des actions autonomes. Cela fonctionne jusqu'au premier incident, puis vous ne pouvez plus reconstruire ce qui s'est passé.

Que font les organismes de normalisation concernant l'identité des agents ?

Le groupe de travail IETF WIMSE étend l'architecture d'identité des charges de travail aux intermédiaires IA, avec une proposition active exigeant des identifiants par agent, les URI SPIFFE étant le mécanisme suggéré, plutôt que de s'appuyer sur les scopes de token. OWASP a publié un Top 10 for Agentic Applications en décembre 2025, avec l'abus d'identité et de privilèges comme catégorie nommée, et la Cloud Security Alliance dispose d'un cadre de gouvernance de l'identité des agents recommandant une identité unique par agent.

Les identifiants d'un agent doivent-ils un jour apparaître dans le contexte du modèle ?

Non. Tout ce qui se trouve dans la fenêtre de contexte est visible pour le modèle et peut être exfiltré par injection de prompt. Le schéma accepté consiste à émettre les identifiants au moment de la tâche via un service de tokens, à les conserver dans la couche d'exécution des outils entre le modèle et l'API, à les limiter à la tâche et à les rendre de courte durée. Le modèle demande l'action ; le harness garde le secret.

En bref

Dans le monde de l'identité, on dit que l'identité est le plan de contrôle, et les agents vont mettre cette idée à l'épreuve plus durement que les microservices ne l'ont jamais fait. La direction est suffisamment claire pour commencer à construire dans ce sens dès aujourd'hui : une identité par agent, des secrets hors du modèle, des tokens qui expirent plus vite que les incidents ne se propagent, et un audit capable de répondre à « quel agent, pour le compte de qui, dans quel but ». Les organisations touchées cet été n'utilisaient pas des architectures exotiques ; elles utilisaient des identifiants partagés et espéraient. C'est l'écart à combler, et il peut l'être avec des technologies qui existent déjà pour l'essentiel.

Si vous cherchez à intégrer l'identité des agents dans un environnement IAM existant et souhaitez un praticien dans la discussion, c'est un travail que je fais. Contactez-moi.

Sources

• IETF WIMSE WG, issue #139 de draft-ietf-wimse-arch, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (déposée le 2026-08-04, consultée le 2026-08-29)

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (publié le 2026-07-17, consulté le 2026-08-29)

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (publié le 2026-05-20, consulté le 2026-08-29)

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (publié le 2026-06-22, consulté le 2026-08-29)

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (publié le 2026-05-20, consulté le 2026-08-29)

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (publié le 2026-07-20, consulté le 2026-08-29)

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (publié le 2026-07-17, consulté le 2026-08-29)

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (publié le 2026-08-17, consulté le 2026-08-29)