Jacob Ideskog, CTO du vendeur d'identité Curity, a publié un texte cette semaine soutenant que les stacks IAM que la plupart des entreprises roulent ont été conçus autour d'un modèle — un humain se connecte, obtient un token de session, prend des actions dans cette session — que la génération actuelle d'agents IA brise. La statistique vedette qu'il cite, c'est que les identités non humaines représentent maintenant plus de 90 % de toutes les authentifications dans les systèmes d'entreprise modernes. Que tu fasses confiance ou non au chiffre exact de Curity, la revendication directionnelle est cohérente avec ce que toute équipe de sécurité cloud dit depuis un an : les comptes de service, les pipelines CI/CD, les runners d'automatisation pis maintenant les agents pilotés par LLM font la majeure partie du trafic d'auth, pis les contrôles autour d'eux sont en aval d'hypothèses de design centrées sur l'humain qui correspondent plus à la charge.

Les modes d'échec architecturaux spécifiques qu'Ideskog catalogue sont réels. L'IAM actuel suppose une porte d'authentification unique au début d'une session. Les agents fonctionnent pas comme ça ; ils enchaînent des appels API multi-étapes à travers des services, souvent sur des minutes ou des heures, sans humain dans la boucle entre les étapes. Ils héritent des permissions de qui a lancé l'agent, ce qui veut dire qu'un seul token d'agent compromis donne à un attaquant l'ensemble large de permissions de l'utilisateur qui a lancé l'agent plutôt que l'ensemble étroit de permissions de n'importe quelle action individuelle que l'agent était censé prendre. Les tokens d'accès permanents qui marchaient bien pour un employé connecté deviennent un risque quand un agent prend des décisions tout seul sur quelles API appeler. Pis le problème de double identité — l'agent a sa propre identité ET il agit au nom d'un utilisateur — a pas de primitive propre dans la plupart des stacks IAM existants.

Le pattern recommandé est réellement sensé pis pas vraiment propriétaire à Curity. Autorisation centrée sur l'application plutôt que centrée sur l'utilisateur. Credentials juste-à-temps, à moindre privilège, scopés à des actions spécifiques pis à des fenêtres temporelles plutôt que des tokens permanents. Autorisation continue à l'exécution à chaque appel API au lieu d'une porte unique au début de session. Tokens qui transportent du contexte : identité de l'acteur, utilisateur représenté, action visée, niveau de confiance actuel. Les primitives techniques pour tout ça existent dans OAuth 2.0 aujourd'hui — token exchange (RFC 8693) pour la double identité, dynamic client registration (RFC 7591) pour les credentials d'agent éphémères, pis rich authorization requests (RAR, RFC 9396) pour les tokens scopés par action. Le trou, c'est pas les standards. C'est que la plupart des déploiements IAM en entreprise soit implémentent pas ces endpoints, soit les implémentent comme des bascules que personne n'utilise.

Pour les développeurs qui travaillent sur des plateformes d'agents, la lecture pratique, c'est que le travail de contrôle d'accès, c'est de la vraie ingénierie pis pas un détail de conformité. Les agents que ta plateforme roule ont probablement besoin de leurs propres identités (pas empruntées de l'utilisateur), de credentials scopés à courte durée émis par tâche (pas longueur de session), pis d'une couche d'autorisation à l'exécution qui peut refuser une action même après que le token ait été émis (parce que les signaux de confiance peuvent changer en milieu de session). Curity vend des produits qui font ça ; Okta aussi avec leur travail Workload Identity, AWS avec IAM Identity Center pis Verified Permissions, pis plusieurs joueurs plus petits comme Aembit pis Astrix. Le pitch de vendeur dans le texte d'Ideskog est pas faux sur l'architecture, mais les développeurs devraient évaluer les primitives OAuth 2.0 directement pis choisir un chemin de déploiement plutôt que de traiter l'IAM d'agents comme une catégorie à fournisseur unique. Le chiffre 90 % non humain, c'est la partie qui devrait faire que toute équipe de sécurité révise ce qu'elle roule, peu importe quel vendeur elle achète au final.