ASI03 : abus d’identité et de privilèges par un agent

ASI03, troisième entrée du Top 10 OWASP des applications agentiques, traite d’un problème que les systèmes d’identité n’avaient pas prévu : un acteur qui n’est ni un humain ni un programme déterministe, et qui agit au nom de quelqu’un sans que personne sache dire au nom de qui, ni jusqu’où. Le référentiel nomme cette zone l’écart d’attribution — privé d’une identité propre et gouvernée, l’agent opère dans un angle mort où le moindre privilège devient littéralement incalculable, puisqu’on ne sait pas qui est le sujet des droits.

→ Lire l’explication complète de la marmotte

Le mécanisme : une identité qui n’est pas la sienne

Le référentiel définit l’identité d’un agent sur deux plans : la persona qui lui est assignée — son rôle déclaré, ce qu’il prétend être auprès des autres — et le matériel d’authentification qui le représente, c’est-à-dire des clés d’API, des jetons OAuth ou des sessions utilisateur déléguées. L’abus porte tantôt sur l’un, tantôt sur l’autre, et le plus souvent sur leur dissociation : le rôle déclaré est étroit, le jeton employé est large.

La cause racine est un décalage d’architecture. Les systèmes de gestion des identités ont été conçus pour des utilisateurs qui se connectent et pour des comptes de service qui exécutent toujours la même chose. Un agent est entre les deux : il agit pour un humain, mais prend ses décisions seul, à une cadence et avec une variété que son mandant n’a pas validées. Le site consacre une page entière à cette question, gouverner les identités des agents logiciels autonomes, dont la thèse rejoint exactement celle du référentiel : l’identité doit porter l’origine de la délégation et ses limites, faute de quoi il n’y a plus de responsable.

Quatre formes reviennent dans le document, et elles se distinguent moins par la technique que par le moment où la confiance se perd.

La délégation qui transporte tout. Un agent coordonnateur, doté de larges accès, confie une sous-tâche à un agent spécialisé et lui passe son contexte d’accès complet — par commodité, ou parce que le cadre d’orchestration ne sait pas faire autrement. L’agent étroit se retrouve avec les droits du large. Le référentiel signale que les plateformes sans code sont particulièrement exposées, leurs agents héritant de privilèges par défaut, accès Internet non restreint compris.

Les identifiants en cache. L’agent conserve en mémoire des secrets et des données récupérés, pour les réutiliser. Si cette mémoire n’est ni segmentée ni purgée entre deux tâches ou deux utilisateurs, un secret obtenu dans une session privilégiée ressort dans une session qui ne l’était pas. Le document donne l’exemple d’un agent d’administration ayant mis en cache des identifiants SSH pendant une opération de correctif, puis sollicité plus tard, dans la même session, par un utilisateur sans droits.

Le député confus. En multi-agents, les requêtes internes sont crues par défaut, parce qu’elles viennent de l’intérieur. Un agent peu privilégié compromis adresse à un agent très privilégié une demande parfaitement formée, qui l’exécute sans revérifier l’intention de l’utilisateur d’origine. Le référentiel en donne un scénario complet : un courriel se présentant comme venant du service informatique, un agent de tri qui le relaie, un agent financier qui exécute le paiement en faisant confiance à un pair interne. C’est un défaut d’autorisation classique, redécouvert dans un décor neuf ; les aspects d’orchestration sont traités dans sécuriser une orchestration multi-agents.

La dérive d’autorisation. Les droits sont vérifiés au début du flux, l’exécution a lieu des heures plus tard. Entre-temps, la limite de dépense a été abaissée, le rôle retiré, la mission terminée. L’agent continue avec un jeton valide pour une autorisation qui ne l’est plus. Le problème n’est pas nouveau — c’est celui du cycle de vie des jetons — mais la durée des tâches agentiques le rend systématique au lieu d’exceptionnel.

Ce qui distingue ASI03 de ses voisins

La frontière avec ASI02, détournement et exploitation des outils, est la seule qui demande un peu d’attention, et le référentiel la formule ainsi : ASI02 décrit un principal qui mésuse ses propres outils dans les droits qu’il détient déjà ; ASI03 décrit un principal qui obtient ou emploie des droits qui ne sont pas les siens. Le résumeur de courriels qui supprime un message relève d’ASI02 ; le même résumeur agissant avec le jeton de l’administrateur relève d’ASI03.

Le vecteur d’entrée est souvent une injection de prompt — l’entrée LLM01 du Top 10 LLM — mais l’impact dépasse la divulgation d’information de LLM02 : avec des outils branchés et plusieurs agents en jeu, c’est la confidentialité, l’intégrité et la disponibilité de tout ce que l’agent peut atteindre qui sont en cause. Dans la taxonomie du projet, l’entrée correspond exactement à T3, compromission de privilège, et au second risque du barème AIVSS, la violation de contrôle d’accès par un agent.

Réduire : borner dans le temps, dans la portée, et par action

Les mesures du référentiel sont celles de la gestion d’identité moderne, appliquées à un sujet qui improvise. Rien d’exotique, et c’est plutôt rassurant.

Des permissions à portée de tâche et bornées dans le temps : un jeton par tâche, étroit, de courte durée, émis contre une identité propre à l’agent — certificats mTLS ou jetons scopés. Les mécanismes et leurs pièges sont décrits dans l’accès juste-à-temps.
L’isolement des identités et des contextes : un bac à sable par session, mémoire et permissions séparées, état effacé entre deux tâches. C’est le remède direct à l’escalade par identifiants en cache.
Une autorisation par action : chaque étape privilégiée est réautorisée par un moteur de politique centralisé, qui consulte les données externes au lieu de se fier à une décision prise en début de flux. C’est ce qui arrête à la fois le député confus et la dérive d’autorisation.
Une intention liée au jeton : le référentiel recommande d’attacher aux jetons OAuth une intention signée portant le sujet, l’audience, l’objet et la session, et de rejeter tout usage dont l’intention ne correspond pas à la requête courante. L’idée répond précisément aux attaques de confusion de portée que le site décrit dans la confusion de scope OAuth ; elle suppose en revanche une infrastructure que peu d’organisations ont déjà.
Pas d’héritage de privilèges entre agents sans réaffirmation de l’intention d’origine, et une révocation automatique sur inactivité ou anomalie. La question de l’héritage est traitée plus largement dans l’héritage des permissions.
Un humain dans la boucle pour toute élévation de privilège, ce qui est le filet de sécurité commun aux trois premières formes.

Le document invite aussi à évaluer les plateformes qui intègrent les agents à la gestion des identités en les traitant comme des identités non humaines gérées, avec identifiants scopés, pistes d’audit et cycle de vie — il cite Microsoft Entra, AWS Bedrock Agents, Salesforce Agentforce, le modèle de Workday et les motifs équivalents chez Google. La remarque est utile et mérite une réserve : déléguer la gouvernance des identités d’agents à la plateforme qui héberge ces agents concentre la confiance au même endroit, ce qui est exactement ce qu’on cherche à éviter ailleurs.

Détecter : surveiller les gains de droits indirects

Le signal le plus spécifique à ASI03 n’est pas un refus mais un succès : un agent qui obtient, par une chaîne de délégation, des portées qu’il n’avait pas la veille. Le référentiel demande de surveiller ces acquisitions indirectes et de signaler les cas où un agent peu privilégié hérite de portées supérieures au cours d’un flux multi-agents. En clair : instrumenter la délégation elle-même, et pas seulement les appels.

Deux autres motifs valent une alerte. Les demandes de nouvelles portées par un agent, qui dans un système bien conçu ne devraient jamais survenir à l’exécution. Et la réutilisation d’un jeton hors de son intention signée, qui est la signature des flux d’hameçonnage par code d’appareil que le document décrit entre agents : un agent navigateur suit un lien de couplage, un autre complète le code, et le locataire de la victime se retrouve lié aux portées de l’attaquant. Les contrôles d’audit côté entreprise sont ceux décrits dans SSO, SCIM et audit d’un assistant IA.

Ce que ces mesures ne font pas

Elles ne résolvent pas la question de fond : au nom de qui l’agent agit-il, et qui répond de ses actes. Un jeton étroit et horodaté dit ce qui était permis ; il ne dit pas qui a voulu l’action. Le référentiel cite un cas qui l’illustre bien : un agent obtient l’accès au nom de son créateur, puis d’autres utilisateurs se servent de ses outils et héritent implicitement de cette identité. Techniquement, tout est en règle. Le site traite ce travers depuis longtemps sous un autre nom, dans les comptes de service oubliés et les comptes partagés : un agent partagé est un compte partagé qui parle bien.

🐝 Ce qui arrive si on s’en passe

Sans identité propre à chaque agent, les appels aux systèmes cibles portent tous le même sujet : le journal du système cible enregistre une identité de service unique, et l’enquête ne peut plus relier une action à l’utilisateur qui l’a demandée, à la tâche qui l’a produite ou à l’agent qui l’a relayée. Sans réautorisation par action, une tâche longue conserve les droits du moment où elle a commencé : un retrait de rôle ou une baisse de plafond décidés entre-temps ne s’appliquent pas, et l’opération aboutit avec une autorisation périmée que le système cible n’a aucun moyen de contester. Sans effacement de l’état entre deux sessions, enfin, un secret lu lors d’une tâche privilégiée reste disponible dans le contexte de la suivante, et la seule mesure d’arrêt disponible en cas de doute est la révocation du jeton commun, qui interrompt du même coup toutes les tâches en cours, y compris celles qu’on aurait voulu examiner.

🦫 Explication de la marmotte 🍫

Pour agir, un assistant informatique a besoin de droits : lire une base, envoyer un message, payer une facture. Ces droits lui sont donnés au nom d’une personne, le plus souvent celle qui l’a installé. Le risque décrit ici est que ces droits circulent mal : trop larges, trop longs, ou employés par quelqu’un d’autre que celui pour qui ils avaient été accordés.

Cela prend quatre formes. Un assistant principal confie une tâche à un assistant secondaire et lui transmet la totalité de ses accès, au lieu du strict nécessaire. Un assistant garde en mémoire un mot de passe obtenu pour une opération précise, et s’en sert plus tard pour quelqu’un qui n’y avait pas droit. Un assistant peu autorisé demande un service à un assistant très autorisé, qui obéit parce que la demande vient de l’intérieur. Ou encore, les droits sont vérifiés au début d’une tâche qui se termine des heures plus tard, alors qu’ils ont été retirés entre-temps.

Les remèdes ressemblent à ceux qu’on applique aux humains, en plus stricts. Chaque assistant reçoit sa propre identité, pas celle d’une personne. Chaque tâche reçoit un droit limité à cette tâche, pour une durée courte. Chaque étape sensible est revérifiée au moment de l’exécution, et non une fois pour toutes au départ. La mémoire est vidée entre deux tâches, pour qu’aucun secret ne traverse.

Le point le plus important est le moins technique : il faut pouvoir dire, après coup, au nom de qui chaque action a été faite. Si tous les assistants travaillent avec le même compte, les journaux ne montreront qu’un acteur unique et personne ne pourra démêler qui a demandé quoi. C’est au moment de l’enquête qu’on s’en aperçoit, et c’est toujours trop tard.

Pages voisines

La citent

ASI03 : abus d'identité et de privilèges par un agent

Elle cite

: les deux pages se citent l’une l’autre.