Les entreprises ne font plus la différence entre leurs agents IA et leurs employés

La plupart des équipes de sécurité en entreprise ont construit leurs défenses sur un postulat simple : une connexion représente une personne. Ce postulat a volé en éclats quelque part ces deux dernières années, et la majorité des organisations n'ont pas encore rattrapé le coup. Aujourd'hui, les agents d'IA s'authentifient auprès des services internes, appellent des API, extraient des données sensibles et enchaînent des workflows multi-étapes sans qu'un humain ait à cliquer « approuver » à chaque étape. La couche d'identité que l'architecture Zero Trust était censée protéger ne correspond plus proprement à qui — ou quoi — agit réellement.

Les chiffres rendent concrets l'ampleur du basculement. Dans les environnements d'entreprise classiques, les identités machine surpassent déjà les utilisateurs humains dans un rapport d'environ 50 pour 1. Dans les architectures lourdes en microservices — la norme pour toute entreprise utilisant une infrastructure cloud moderne — ce ratio monte jusqu'à 500 pour 1, selon des recherches compilées par la Cloud Security Alliance. Chacune de ces identités machine est un identifiant, un compte de service ou une clé API qui peut être compromise, mal utilisée ou tout simplement oubliée.

L'épidémie de sur-permissionnement

Le problème profond n'est pas le nombre pur d'identités machine, c'est ce qu'elles sont autorisées à faire. Environ 99 % des identités non humaines détiennent des permissions bien au-delà de ce que leurs workloads réels exigent, selon les conclusions de la Cloud Security Alliance. La plupart de ce sur-provisionnement arrive pour des raisons banales : un développeur accorde un accès large pour débloquer un déploiement, personne ne revoit la concession, et l'identifiant reste là indéfiniment avec des privilèges permanents dont il n'a jamais eu besoin.

Les agents d'IA héritent de ce même schéma, à la différence que les enjeux sont plus élevés parce que les agents agissent avec une autorité déléguée à l'intérieur de workflows conçus pour paraître anodins. DTEX Systems a mené des simulations contrôlées montrant à quelle vitesse un agent sur-permissionné peut agir : dans un test, un agent est passé d'un accès Salesforce légitime à la rédaction d'un e-mail dans Outlook en 24 minutes. Dans un autre, l'accès à des fichiers locaux s'est transformé en transfert de données archivées via un assistant de codage en 10 minutes. Aucune action n'a déclenché d'alerte, car aucune ne violait une règle d'accès explicite — l'agent faisait exactement ce que ses identifiants lui permettaient.

68% ne peuvent pas dire qui a fait quoi

C'est là que la crise d'identité se double d'une crise d'audit. Quand les équipes de sécurité enquêtent sur un incident, la première question est toujours "qui a fait ça ?". Avec les agents d'IA intégrés aux opérations quotidiennes, une part croissante des organisations ne peut plus répondre proprement à cette question à partir de leurs logs. Distinguer une action humaine légitime d'une action d'un agent autonome agissant sous les mêmes identifiants délégués de cet humain nécessite une télémétrie comportementale que la plupart des entreprises n'ont jamais construite : motifs de frappe, mouvements de souris, séquences de navigation, et rythme des appels API, plutôt qu'un nom d'utilisateur statique dans un journal d'accès.

Le propre framework Zero Trust d'Anthropic pour les agents d'IA en entreprise — publié comme guide interne et repris dans toute l'industrie cette année — reformule la question de sécurité fondamentale. Ce n'est plus "est-ce que cet outil est autorisé à s'exécuter ?". Cette question a toujours été répondue par une politique statique. La question plus difficile est de savoir si une organisation peut reconstituer la chaîne complète depuis l'intention humaine, en passant par l'action de l'agent, jusqu'au mouvement des données et au résultat. La plupart des entreprises n'y parviennent actuellement pas.

Ce qui résout vraiment le problème

La solution ne consiste pas à ajouter davantage de listes de contrôle d'accès. Il s'agit plutôt d'un virage vers quatre pratiques spécifiques qui traitent chaque identité d'agent comme éphémère plutôt que permanente :

Identifiants éphémères et limités à la tâche. Des frameworks comme SPIFFE (Secure Production Identity Framework for Everyone) délivrent des identités qui expirent après une seule transaction plutôt que de persister indéfiniment. Cela réduit le rayon d'impact de "tout ce que cet agent pourrait théoriquement faire" à "cette action spécifique, pour cette tâche spécifique".
Inventaire automatisé des identités non humaines. La plupart des entreprises n'ont pas de liste complète de chaque clé API, compte de service et identité d'agent présents dans leur cloud et leurs systèmes sur site. La découverte doit être continue, pas un audit trimestriel.
Vérification comportementale continue. Les plateformes Identity Threat Detection and Response (ITDR) qui surveillent les schémas anormaux en cours de session — pas seulement à la connexion — attrapent l'agent qui commence à faire quelque chose que sa tâche n'a jamais exigé.
Approvisionnement d'accès juste-à-temps. Les permissions permanentes sont la cause racine du problème de sur-provisionnement à 99 %. Une autorisation contextuelle et limitée dans le temps qui expire lorsque la tâche se termine comble cet écart par conception plutôt que par une application de politique après coup.

Aucune de ces mesures n'est exotique. L'architecture Zero Trust supposait déjà une absence de confiance implicite pour tout acteur — le problème des agents d'IA est en réalité un test pour savoir si les organisations ont réellement implémenté ce principe ou si elles en ont seulement adopté le vocabulaire. Les équipes de sécurité qui traitent chaque identifiant d'agent comme une identité permanente et de confiance utilisent la même architecture qui a fait tomber les entreprises avant l'existence du Zero Trust. Les agents se contentent de bouger plus vite que les humains qui commettaient cette erreur auparavant.

Que faire ce trimestre

Si votre organisation déploie des agents d'IA dans des workflows de production — et c'est le cas de la plupart, que la sécurité en ait la visibilité ou non — commencez par le problème d'inventaire. Vous ne pouvez pas sécuriser ce que vous ne voyez pas. Réalisez une passe de découverte des identités non humaines à travers votre IAM cloud, vos comptes de service, et chaque assistant de codage ou outil d'automatisation disposant d'un accès API. Ensuite, passez en priorité les identifiants d'agents les plus privilégiés vers des jetons éphémères et limités à la tâche. Ce seul changement ferme le plus large rayon d'impact avec le moins de perturbation architecturale, et il vous donne le temps de mettre en place une surveillance comportementale avant que le prochain incident ne force la question.