Les agents IA sont désormais des non-human identities : le problème de credential sprawl de 2026

Le ratio qui devrait vous inquiéter plus que les titres sur le prompt injection

La majeure partie des discussions de 2026 sur le risque agentic AI se concentre encore sur ce qu'un prompt malveillant peut pousser un agent à faire. C'est un risque réel, et nous en avons parlé dans notre article sur les risques de sécurité MCP. Mais un chiffre plus discret, issu des recherches de cette année sur l'identity, pointe vers quelque chose de structurellement plus important : les non-human identities dépassent désormais les identities humaines dans un ratio de 144 pour 1 dans les environnements cloud-native, contre 92 pour 1 deux ans plus tôt seulement, soit un bond de 56 % du ratio en une seule année, selon des recherches 2026 compilées par la Cloud Security Alliance et relayées dans toute la communauté de la sécurité des non-human identities. Dans une entreprise type, les bots, les service accounts et les agents IA dépassent désormais les utilisateurs humains dans un ratio d'environ 100 pour 1.

Les agents IA constituent la part de cette population qui croît le plus vite, et c'est aussi la moins bien gouvernée. Cette combinaison, croissance plus déficit de gouvernance, correspond exactement à la forme de toutes les breaches liées aux credentials que le secteur de la sécurité a déjà connues, simplement comprimée sur un délai plus court, parce que les agents se provisionnent et agissent plus vite qu'aucun processus d'onboarding humain ne l'a jamais fait.

Pourquoi le credential d'un agent n'est pas une clé de service account comme les autres

Il est tentant de ranger « l'identity de l'agent IA » dans la même catégorie que « la gestion des service accounts », un problème que les équipes de sécurité traitent depuis des années. La forme du credential est similaire, une clé ou un token qui authentifie un appelant non-human, mais le comportement qui se cache derrière ne l'est pas.

Un service account traditionnel appelle toujours la même poignée d'APIs selon le même pattern, jour après jour, pendant des années. Son blast radius est connu à l'avance car son comportement est statique. Un agent IA, à l'inverse, n'a rien de statique : il acquiert des permissions de façon dynamique au runtime, peut faire naître des sous-agents pour déléguer une partie d'une tâche, invoque des APIs et des outils externes qu'on ne lui a pas explicitement demandé d'appeler à l'avance, écrit et exécute du code, et enchaîne des actions à travers de nombreux systèmes au sein d'une même session. Chacun de ces comportements élargit ce qu'un seul credential compromis ou trop largement scopé peut atteindre, bien au-delà de ce qu'un service account statique aurait jamais pu faire avec les mêmes permissions nominales.

Les données de gouvernance 2026 reflètent exactement cet écart. Une analyse de la Cloud Security Alliance sur le token sprawl révèle que plus de 16 % des organisations ne suivent absolument pas la création des identities liées à l'IA, ce qui signifie qu'un agent peut naître, détenir un credential et agir sans qu'aucune entrée d'inventaire n'existe nulle part. Près d'un quart des organisations mettent plus de 24 heures à faire la rotation ou à révoquer un credential potentiellement exposé, et 30 % mettent plus d'une journée entière rien que pour trier une fuite de sévérité critique. Dans le même temps, la plupart des organisations indiquent que des agents tournent déjà en production, sur du cloud public, on-premises et en environnement hybride. L'usage en production est arrivé avant la discipline de lifecycle.

Ce qu'implique réellement le fait de traiter les agents comme des identities

Dans beaucoup d'organisations, le réflexe est de donner à un agent le token personnel d'un développeur, ou un credential de service partagé que tout le monde a déjà sous la main, parce que c'est plus rapide à shipper. Ce raccourci est précisément ce que décrit le chiffre de 22 % évoqué plus haut : seule environ une organisation sur cinq traite aujourd'hui les agents comme des identities indépendantes dotées de leur propre lifecycle. Bien le faire suppose quatre choses, aucune exotique, mais toutes fréquemment sacrifiées sous la pression des délais.

Émettre un credential scopé par agent, jamais un credential partagé. Les virtual API keys d'Odock peuvent être scopées à une organisation, une équipe ou un user principal, de sorte que le trafic d'un agent soit attribuable à une chaîne précise plutôt qu'à « la clé du développeur qui était sous la main ». Voir scope et principals pour comprendre comment cette chaîne est construite.

Accorder l'accès explicitement, model par model et tool par tool. Un agent ne devrait pas hériter d'un accès global simplement parce que c'est pratique. Les access grants sur les models et le MCP existent précisément pour que la portée d'un agent corresponde à l'intersection de ce dont il a besoin, et non à l'union de tout ce que l'organisation a jamais connecté. La sécurité MCP couvre les allow lists et block lists au niveau des tools, précisément pour cette raison.

Faire la rotation sans casser toute la chaîne en aval. Si la rotation prend souvent des jours dans la pratique, c'est généralement parce que faire tourner un credential oblige à rebrancher chaque intégration qui en dépend. Le lifecycle et la rotation des clés d'Odock effectuent la rotation en place : le key id reste constant, l'accès aux models, les budgets, les quotas et l'attribution d'usage restent rattachés, seul le secret change. C'est ce qui transforme « la rotation devrait se faire en moins d'une heure » d'une aspiration en une réalité opérationnelle.

Rendre chaque action attribuable a posteriori. Un credential révoqué ou ayant subi une rotation répond à la question « que peut faire cet agent maintenant ? ». Un usage record répond à « qu'est-ce que cet agent a déjà fait ? », la question qui compte vraiment lors d'une revue d'incident.

La prochaine complication : le trafic agent-to-agent

Le problème d'identity se complique à mesure que les agents commencent à parler à d'autres agents, et non plus seulement à des tools. Des protocoles comme Agent2Agent, sous la responsabilité de la Linux Foundation depuis que Google l'a introduit en 2025, permettent aux agents d'annoncer leurs capacités et de négocier des tâches via un AgentCard lisible par machine, qui peut déclarer les schémas d'authentification supportés tels qu'OAuth 2.0, OpenID Connect, API keys ou mutual TLS. C'est une réelle avancée pour l'interopérabilité, et le protocole est explicite sur ce qu'il ne résout pas : il ne provisionne pas les credentials et ne décide pas de l'autorisation à votre place. Les chercheurs qui analysent la surface d'attaque d'A2A pointent la fausse annonce d'agents, l'enregistrement non autorisé et les boucles de délégation récursive comme des risques propres au protocole, précisément parce que l'identity et l'autorisation sont laissées à la charge de qui opère le déploiement.

C'est exactement cet écart qui explique pourquoi l'identity ne peut pas être une réflexion après coup, greffée sur des frameworks d'agents. Quel que soit le protocole que vos agents utilisent pour se parler, il faut toujours répondre à la question « de quel credential s'agit-il, à quoi a-t-il le droit de toucher, et puis-je le révoquer en quelques secondes », et cette réponse doit vivre au niveau de la couche que chaque requête traverse réellement, pas dans le code d'authentification propre à chaque framework.

Les limites à connaître

Une identity émise par la gateway règle la partie infrastructurelle du problème : le scoping, la rotation, la révocation et l'attribution. Elle ne règle pas le cas d'un agent trompé par une entrée malveillante et amené à détourner l'accès qu'il détient légitimement ; c'est un problème qui se situe au niveau du prompt et du contenu, couvert par des outils comme le moteur SafetySec d'Odock, et non par la seule gestion des identities. Les deux couches sont complémentaires, pas substituables. Un agent doté d'une identity étroitement scopée et rotatable, mais sans inspection de contenu, peut toujours être manipulé pour détourner ce qu'il est autorisé à toucher. Un agent doté d'une excellente inspection de contenu, mais d'un credential partagé, non scopé et non rotatable, n'est qu'à un secret divulgué d'un blast radius illimité. Il faut les deux, et la plupart des données 2026 sur les breaches suggèrent que la majorité des organisations n'ont aujourd'hui ni l'un ni l'autre à un niveau mature.

Là où Odock.ai intervient

J'ai conçu le système de virtual API keys d'Odock en ayant précisément cet écart en tête, donc lisez ce qui suit comme le point de vue d'une partie prenante non neutre. Chaque application, équipe, utilisateur et agent qui passe par Odock reçoit sa propre virtual key scopée, avec des access grants explicites sur les models et le MCP, des budgets, des quotas et une rotation en place, ainsi qu'un usage record sur chaque appel. Cela signifie qu'un agent n'est jamais un secret partagé se faisant passer pour une identity : c'est une véritable identity, dotée d'un vrai lifecycle, de l'émission jusqu'à la révocation.

Si votre organisation a déjà des agents en production et fait partie des quelque 78 % qui les traitent encore comme des credentials statiques plutôt que comme des identities gouvernées, la solution n'est pas un tableur plus volumineux recensant qui détient quelle clé. C'est de placer le trafic de vos agents derrière une gateway conçue pour émettre, scoper, faire tourner et révoquer des identities comme une opération de premier ordre. Demandez une démo ou commencez par la gouvernance MCP chez Odock et donnez à vos agents un lifecycle d'identity avant qu'un incident ne vous force à en construire un sous pression.

Sources

• The Non-Human Identity Governance Vacuum, Cloud Security Alliance
• Token Sprawl in the Age of AI, Cloud Security Alliance
• The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI, Token Security
• Non-human identity sprawl is agentic AI's real risk, InformationWeek
• Clés API virtuelles Odock
• Sécurité MCP Odock