Ceci est le quatrième article d’une série en sept parties sur la sécurité des identités en tant que sécurité de l’IA.
Résumé : les chaînes de délégation deviennent des cibles de choix dans les systèmes autonomes. Chaque transfert d’agent multiplie les accès, et étant donné que presque toutes (97 %) les identités non humaines disposent déjà de privilèges excessifs, les risques s’aggravent à chaque étape. Dans une vulnérabilité baptisée détournement de session agentique (novembre 2025), un sous-agent intègre une transaction boursière silencieuse dans une réponse de routine. L’agent parent l’exécute ensuite sans invite ni visibilité. Dans une autre vulnérabilité connue sous le nom d’élévation de privilèges entre agents (sept. 2025), un agent réécrit la configuration d’un autre en cours de tâche, ce qui peut déclencher une boucle de contrôle auto-renforcée. La délégation n’est pas intrinsèquement risquée, mais sans autorisations délimitées et traçabilité cryptographique, elle peut devenir un canal direct de déplacement latéral.
Détournement de session agentique : quand la délégation devient exploitation
La délégation d’agent à agent favorise l’évolutivité dès la conception : les agents principaux délèguent les tâches complexes à des sous-agents spécialisés pour une exécution ciblée.
En théorie, chaque étape réduit les autorisations et maintient l’alignement avec l’intention d’origine. Mais en pratique, c’est souvent le contraire qui se produit.
Dans une démonstration de faisabilité (PoC) utilisée dans le cadre du scénario de détournement de session, un agent financier a demandé des informations sur le marché à un agent de recherche. Le sous-agent a renvoyé un résumé propre, ainsi qu’une commande de transaction boursière cachée. Aucune alerte n’a été déclenchée et la transaction a été exécutée de manière invisible.
Chaque couche faisait confiance à la suivante sans vérifier l’alignement. Unit 42 a expliqué comment l’ensemble du parcours d’exploit pouvait fonctionner :
- Un assistant financier demande des nouvelles du marché à un agent de recherche.
- L’assistant de recherche est malveillant et injecte des instructions cachées dans sa réponse.
- L’assistant financier a exécuté une transaction non autorisée de 10 actions.
- L’utilisateur n’a vu que le résumé des nouvelles du marché ; l’appel buy_stock était invisible.
Comme Unit 42 l’a observé :
« Un agent compromis constitue un adversaire de taille. Grâce à des modèles d’IA, il peut générer de manière autonome des stratégies adaptatives, exploiter l’état de la session et étendre son influence à tous les agents clients connectés. »
Dans un exemple décrivant comment le scénario d’élévation de privilèges pouvait se dérouler, un agent compromis pouvait modifier l’environnement d’exécution d’un agent frère. Cet agent, désormais mal configuré, transmet des tâches d’une manière qui peut étendre la portée de l’attaquant. Si la chaîne n’est pas rompue, il peut revenir en arrière et approfondir une intrusion.
Plus les agents s’intègrent profondément dans les finances, les opérations et l’infrastructure, plus la délégation incontrôlée devient dangereuse. Chaque transfert de tâche non vérifié peut se transformer une brèche.
Trois systèmes, même schéma de défaillance
ServiceNow Now Assist (octobre 2025)
AppOmni a révélé que des agents à faibles privilèges dans Now Assist de ServiceNow pouvaient être utilisés pour exploiter la découverte d’agents afin d’enrôler des pairs à privilèges plus élevés et d’exfiltrer des données.
Élévation de privilèges entre agents (septembre 2025)
Johann Rehberger a identifié la vulnérabilité Élévation de privilèges entre agents et a expliqué comment un agent compromis pouvait en reconfigurer d’autres en réécrivant sa configuration. Dans les environnements où plusieurs agents (Copilot, Claude, Gemini, etc.) partagent une base de code, un copilote à injection d’invites peut modifier le fichier .mcp.json de Claude.
Lors de la prochaine utilisation, Claude exécuterait alors du code arbitraire et pourrait reconfigurer Copilot. Comme Johann Rehberger l’a observé :
« Ce qui commence comme une simple injection indirecte d’invites peut rapidement dégénérer en une compromission multi-agent. »
EchoLeak dans Microsoft 365 Copilot (juin 2025)
Aim Security a découvert « EchoLeak » (CVE-2025-32711, CVSS 9.3), un exploit sans clic où des invites cachées dans des e-mails déclenchaient une exfiltration silencieuse de données depuis SharePoint, Teams et OneDrive.
Le même schéma de vulnérabilité apparaît dans les frameworks d’orchestration de LLM, où les chaînes de modèles et d’outils manquent généralement d’application automatique de la portée, laissant aux développeurs le soin de gérer l’atténuation manuellement.
Délégation récursive : le problème des poupées russes
Les systèmes multi-agents sont conçus pour la décomposition des tâches. Un agent principal divise les requêtes complexes en sous-tâches et les délègue à des spécialistes. Ces sous-agents peuvent déléguer davantage. Chaque étape de délégation franchit une limite de confiance et hérite de l’autorité d’origine.
Les conseils de l’OpenID Foundation sur l’IA agentique nomment cela l’avantage et le danger principal des écosystèmes d’agents : « La véritable puissance d’un écosystème d’agents émane de la délégation récursive : la capacité d’un agent à décomposer une tâche complexe en déléguant des sous-tâches à d’autres agents plus spécialisés. »
Mais cette puissance s’accompagne d’un avertissement : « Les défis se multiplient de façon exponentielle avec la délégation récursive, l’atténuation de la portée sur les chaînes de délégation, les véritables flux au nom des utilisateurs qui maintiennent la responsabilité et le cauchemar d’interopérabilité des différents systèmes d’identité d’agents qui tentent de communiquer. »
En d’autres termes, ce qui rend l’IA agentique puissante la rend également fragile, à moins que l’architecture n’impose un contrôle à chaque transfert.
Portée, provenance et contexte = trois failles structurelles qui engendrent des risques
1. Absence d’atténuation de la portée à chaque étape de délégation. Chaque agent d’une chaîne de délégation doit avoir des autorisations plus restreintes que celui qui le précède, mais ce principe du moindre privilège échoue souvent dans la pratique. Dans le scénario de détournement de session agentique, un agent de recherche a hérité de l’accès à l’outil buy_stock d’un assistant financier, ce qui lui a permis d’exécuter une transaction cachée intégrée dans un résumé des nouvelles du marché. Les tokens OAuth traditionnels ne peuvent pas être restreints après leur émission sans recontacter le serveur d’authentification, ce qui pose problème dans les systèmes décentralisés. La délégation sécurisée nécessite des formats de tokens qui prennent en charge l’atténuation hors ligne, afin que les agents puissent limiter l’accès de manière indépendante.
2. Absence de preuve cryptographique de la traçabilité de la délégation. Les tokens OAuth valident la structure et l’état, mais manquent de traçabilité historique. À la troisième étape de délégation, il n’y a aucun lien cryptographique avec l’agent ou l’utilisateur initiateur. Aembit affirme : « Sans preuve cryptographique, les agents malveillants peuvent falsifier les demandes de délégation et accéder à des ressources qu’ils ne devraient pas atteindre. »
3. Absence d’ancrage contextuel entre les sessions. Les interactions multiples avec des agents exigent un alignement constant avec la tâche d’origine. Sans cela, les agents dérivent, élargissant progressivement leur comportement au-delà de l’intention. Unit 42 recommande de mettre en place un « ancrage contextuel », c’est-à-dire de créer un point d’ancrage de tâche au début de la session et de vérifier constamment l’alignement sémantique.
Atténuation de la portée : les autorisations doivent être réduites, pas étendues
Les formats de tokens émergents tels que Macaroons, Biscuits et Wafers reflètent l’architecture que les chaînes de délégation exigent pour être sécurisées. Chaque token intègre des attributs essentiels : identité, expiration et racine cryptographique. Les détenteurs peuvent ajouter des couches qui ne font que réduire les autorisations. Les tokens restent vérifiables hors ligne, préservant ainsi l’intégrité tout en empêchant l’élévation des privilèges.
Bien que la syntaxe varie selon le format, le modèle de base est le même : les tokens peuvent être atténués localement, jamais étendus :
Chaque sous-agent ajoute une réserve signée, en mode append-only, qui réduit la portée du token, formant une chaîne vérifiable. Lorsqu’il est utilisé, l’émetteur peut retracer le parcours de délégation complet. Si un agent de recherche essaie buy_stock, la requête échoue, de manière traçable, avec la preuve de qui a restreint quoi, et où.
Bien qu’aucun fournisseur d’identité majeur ne prenne actuellement en charge nativement les formats Macaroons et Biscuits, leurs principes fondamentaux (atténuation hors ligne, délégation cryptographique et contraintes append-only) peuvent être appliqués aujourd’hui à l’aide de l’infrastructure OAuth existante.
Défense contre les attaques de délégation récursive
Ces vulnérabilités liées à la délégation aux agents d’IA suggèrent quatre exigences défensives :
1. Confirmation hors bande : les actions sensibles nécessitent une approbation humaine via des canaux auxquels les agents ne peuvent pas accéder : notifications push ou interface utilisateur distincte, pas de chat.
2. Ancrage contextuel : ancrez les sessions à la tâche d’origine ; signalez toute dérive sémantique avant l’exécution.
3. Identité et capacités vérifiées : les agents doivent présenter des identifiants signés (par exemple, des AgentCards cryptographiques).
4. Visibilité de l’utilisateur : les instructions introduites clandestinement réussissent lorsqu’elles sont cachées. Analysez les appels et les logs des outils.
Comment Okta et Auth0 gèrent la délégation récursive
L’implémentation indépendante de ces contrôles peut créer des zones d’ombre. Okta et Auth0 aident à gérer la délégation récursive grâce à une couche d’identité unifiée :
Cross App Access (XAA). XAA, disponible sur Okta et Auth0, transfère le consentement au fournisseur d’identité, désormais intégré à MCP (depuis novembre 2025) sous « Autorisation gérée par l’entreprise ». Basé sur ID-JAG, il suit et révoque la traçabilité de la délégation, afin que les actions des agents soient consignées et révocables.
Token Vault. Auth0 Token Vault résout le problème de « confused deputy » dans l’accès aux identifiants des agents. Les API naïves permettent aux développeurs de transmettre des paramètres userId, exposant les systèmes à des bugs ou à l’injection d’invites qui pourraient extraire les identifiants d’un autre utilisateur. Token Vault élimine ce problème en exigeant une preuve cryptographique de la session utilisateur actuelle, jamais un simple identifiant. Les agents utilisent OAuth 2.0 Token Exchange (RFC 8693) pour convertir les tokens de session en identifiants à court terme et à portée limitée, réalisant ainsi une atténuation précise de la portée grâce à des protocoles standard.
Async Auth. Auth0 Async Auth permet une approbation hors bande par le biais de notifications push ou d’e-mails, traitant directement la vulnérabilité de détournement de session agentique en exigeant une confirmation humaine par le biais de canaux que le LLM ne peut pas manipuler.
Fine-Grained Authorization. Auth0 FGA, basé sur le modèle Zanzibar de Google, applique un accès basé sur les relations à chaque appel. Les agents valident et mettent à jour l’état de délégation à chaque étape, réduisant progressivement les autorisations. Ce contexte dynamique se trouve dans FGA, et non dans le token, ce qui permet une atténuation des capacités sans nécessiter de nouveaux formats de tokens.
Identity Governance. Okta Identity Governance étend la gestion du cycle de vie aux agents, contribuant à garantir que les autorisations déléguées sont examinées et révoquées à mesure que les rôles, les projets ou les contextes de sécurité évoluent. Ce qui était approprié au moment du déploiement peut rapidement devenir excessif. La gouvernance permet un ajustement continu et approprié de l’autorité des agents.
La voie à suivre : une délégation qui fait ses preuves
Les systèmes multi-agents offrent des capacités supérieures à celles des agents uniques, mais exposent également des failles que l’IAM traditionnel ne couvre pas. Chaque vulnérabilité abordée ici présente le même schéma : des agents acquérant plus d’autorité que prévu, fonctionnant sans visibilité de l’utilisateur et ne laissant aucune piste d’audit.
La sécurisation de la délégation nécessite quatre fondements : l’atténuation de la portée à chaque étape, la vérification de la traçabilité au niveau des tokens, un alignement constant du contexte et une approbation humaine hors bande pour les actions sensibles.
Ces mesures ne sont plus optionnelles. En vertu de la loi de l’UE sur l’IA, la traçabilité et la supervision sont des obligations légales pour les systèmes à haut risque. L’article 14 exige que les humains comprennent pleinement et surveillent le fonctionnement de l’IA.
Sans chaînes de délégation vérifiables, ce niveau de supervision s’effondre. Votre infrastructure permet un contrôle auditable ou devient un risque pour la conformité.
Dans le cinquième article : que se passe-t-il lorsque des agents d’IA passent de workflows numériques à des systèmes physiques, où un seul faux pas peut déclencher des dommages réels, et que l’identité devient la dernière ligne de défense ?
