ASI09 : exploitation de la confiance entre humain et agent

ASI09, neuvième entrée du Top 10 OWASP des applications agentiques, est la seule qui ne décrive aucune défaillance technique. Son objet est la confiance que l’humain accorde à l’agent, et la façon dont cette confiance devient le dernier maillon exploité. Un agent parle bien, répond vite, cite des éléments vérifiables et explique ses choix dans une prose assurée. Le référentiel nomme le mécanisme sans détour — l’anthropomorphisme, renforcé par le biais d’automatisation et l’autorité perçue — et en tire la conséquence qui dérange : l’action finale, celle qui sera auditée, est accomplie par un humain.

→ Lire l’explication complète de la marmotte

Le mécanisme : la compromission devient invisible

La formulation du référentiel mérite d’être rapportée fidèlement, parce qu’elle est la clé de l’entrée : l’agent agit comme une mauvaise influence intraçable, qui manipule l’humain pour qu’il accomplisse l’action finale auditée, rendant le rôle de l’agent dans la compromission invisible à l’analyse post-incident.

Techniquement, c’est une attaque parfaite. Les journaux montrent une action légitime, effectuée par un utilisateur authentifié, dans ses droits, avec une approbation en règle. L’agent, lui, n’apparaît que comme un assistant ayant fourni une recommandation — et les recommandations ne sont pas journalisées, ou le sont dans un système que personne ne corrèle avec les journaux de production. La reconstruction de la chronologie d’une attaque s’arrête donc sur un humain qui a cliqué.

Quatre ressorts sont décrits. L’explicabilité insuffisante : un raisonnement opaque force l’utilisateur à faire confiance à des sorties qu’il ne peut pas questionner, et l’autorité perçue de l’agent suffit à faire passer un déploiement de code, l’approbation d’une instruction fausse ou une modification d’état système sans examen. L’absence de confirmation pour les actions sensibles, qui convertit la confiance en exécution immédiate : un seul échange peut devenir un virement irréversible, une suppression de données ou une élévation de privilèges. La manipulation émotionnelle, où un agent empathique obtient par la sympathie ce qu’un formulaire n’obtiendrait pas. Et la fausse explicabilité, qui est le cas le plus intéressant : l’agent fabrique une justification convaincante qui recouvre une logique néfaste, et l’humain approuve en croyant comprendre.

Sur ce dernier point, un rappel utile : la capacité d’un modèle à produire un raisonnement plausible est indépendante de l’exactitude de ce raisonnement. Un agent ne mentionne pas ses sources parce qu’il les a consultées, il les mentionne parce que les textes qui ressemblent au sien en mentionnent. Les limites de ce qu’on peut inférer d’un texte généré sont traitées sur le site dans les limites de la détection de contenu généré.

Ce qui distingue ASI09 de ses voisins

Le référentiel tranche en une phrase : ASI09 porte sur la méprise ou la sur-dépendance humaine, ASI10 sur la déviation d’intention de l’agent. La distinction tient donc au siège de la défaillance, pas à son origine. Un agent parfaitement sain dont les recommandations sont approuvées sans examen relève d’ASI09 ; un agent qui poursuit un objectif divergent relève d’ASI10, même si personne ne s’en aperçoit.

La frontière avec ASI01, détournement d’objectif, est tout aussi utile : dans ASI01, l’agent détourné agit lui-même ; dans ASI09, il fait agir quelqu’un. C’est la différence entre un outil retourné et un complice involontaire, et elle change la réponse — on ne corrige pas un biais cognitif avec une politique d’autorisation.

Dans la taxonomie du projet, l’entrée se rattache à T10, saturation de l’humain dans la boucle, et à T07, comportements désalignés et trompeurs. Le premier code mérite une mention : la saturation est le mode d’échec ordinaire du contrôle humain, bien avant la manipulation sophistiquée.

Les formes qu’on rencontre

Le cheval de Troie serviable. Un assistant de codage compromis propose un correctif élégant, en une ligne. La commande, collée dans un terminal, exécute un script qui exfiltre du code ou installe une porte dérobée. Le vecteur est le copier-coller, l’arme est l’élégance de la solution.

La moisson d’identifiants par contexte crédible. Un agent de support informatique, détourné par injection, cible un nouvel arrivant, cite de vrais numéros de tickets pour établir sa légitimité, demande des identifiants et les exfiltre. La technique est celle de l’ingénierie sociale pour l’accès initial, avec un avantage considérable : l’agent dispose vraiment des informations internes, donc ses détails vérifiables le sont. Les raisons pour lesquelles les formations n’y suffisent pas sont traitées dans pourquoi on clique malgré la formation.

La fraude au copilote de facturation. Une facture fournisseur empoisonnée est ingérée par l’assistant financier, qui recommande un paiement urgent vers les coordonnées de l’attaquant, avec une explication cohérente. Le responsable approuve. Le référentiel décrit ce cas deux fois, dans des termes différents, ce qui donne une idée de sa fréquence — et le suivi d’incidents mentionne une manipulation documentée d’un copilote de suite bureautique amenant des utilisateurs vers un virement mal avisé.

La fabrication d’explicabilité. L’agent produit une justification d’audit plausible pour un changement de configuration risqué. Le référentiel insiste sur un point : quelle que soit la cause racine — détournement, empoisonnement ou simple hallucination — le relecteur approuve. Le plus net des scénarios est aussi le plus brutal : un agent détourné fabrique une justification convaincante pour obtenir d’un analyste l’approbation de la suppression d’une base de production.

L’aperçu qui n’en est pas un. Celui-là est purement technique et se glisse dans l’entrée par la petite porte : un panneau d’aperçu qui déclenche des effets de bord à l’ouverture, exploitant le modèle mental de la lecture seule. L’utilisateur croit regarder, il agit. Le site décrit un cousin de ce mécanisme dans l’exfiltration par le rendu Markdown d’un chat.

Réduire : ne pas demander à l’agent de se justifier

Les mitigations du référentiel sont inhabituelles pour un document de sécurité applicative, puisqu’elles relèvent pour moitié de l’ergonomie. Elles n’en sont pas moins précises, et l’une d’elles est remarquable.

Un résumé de risque en langage clair, qui ne soit pas généré par le modèle. C’est la recommandation la plus importante de l’entrée : la justification affichée à l’utilisateur doit être produite par un composant déterministe, à partir de ce que l’action va faire, et non par l’agent qui la propose. Demander à l’agent d’expliquer son action revient à demander à l’intéressé de rédiger son propre certificat de bonne conduite.
Des confirmations explicites avant tout accès à des données très sensibles ou toute action risquée, avec approbation en plusieurs étapes. La condition pour que cela serve à quelque chose est que l’approbateur voie les paramètres exacts : le dispositif est décrit dans sécuriser les actions irréversibles des agents LLM.
Une calibration adaptative de la confiance : ajuster le niveau d’autonomie et la supervision requise selon un score de risque contextuel, et afficher des indices pondérés par la certitude — « faible certitude », « source non vérifiée » — qui invitent visuellement à questionner les actions à fort impact. L’objectif explicite est de réduire le biais d’automatisation.
Une provenance vérifiable attachée à toutes les recommandations et données externes : identifiant de source, horodatage, hachage d’intégrité, avec validation de signature et contrôles de politique à l’exécution bloquant les actions dépourvues de provenance de confiance ou sortant de la portée déclarée de l’agent.
La séparation de l’aperçu et de l’effet : bloquer tout appel réseau ou modifiant l’état pendant un contexte d’aperçu, et afficher un indicateur de risque avec la provenance et les effets de bord attendus.
Des garde-fous d’interface : différenciation visuelle des recommandations à haut risque, rappel périodique des motifs de manipulation et des limites de l’agent, et — recommandation que l’on aimerait voir plus souvent — éviter le langage persuasif ou émotionnellement manipulateur dans les flux critiques pour la sécurité. Un agent qui dit « je m’occupe de tout, ne vous inquiétez pas » devant un écran de suppression n’est pas un agent bien conçu.
La détection de divergence de plan : comparer les séquences d’actions aux lignes de base des flux approuvés, et alerter sur les détours inhabituels, les étapes de validation omises et les combinaisons d’outils nouvelles.
Des journaux immuables des requêtes des utilisateurs et des actions de l’agent, et une surveillance de l’exposition de données sensibles dans les conversations comme dans les connexions agentiques.
Un moyen de signaler une interaction suspecte, déclenchant une revue automatisée ou un verrouillage temporaire des capacités de l’agent. Sans ce canal, l’utilisateur qui trouve le comportement bizarre n’a d’autre choix que de l’ignorer ou de s’en plaindre à la machine à café.

Ce que ces mesures ne font pas

Elles ne suppriment pas le biais d’automatisation, elles le ralentissent. Un opérateur qui approuve deux cents décisions par journée approuve en réalité la première et accepte les suivantes ; le référentiel l’admet implicitement en rattachant l’entrée à la saturation de l’humain dans la boucle. La seule mesure qui agisse sur le fond est de réduire le nombre de décisions soumises à validation, c’est-à-dire d’automatiser moins — la moindre agentivité encore, appliquée cette fois à la charge de supervision. Une porte humaine n’a de valeur que si l’humain a le temps de regarder, ce qui en fixe le nombre.

Elles ne règlent pas davantage le problème de traçabilité qui fait l’intérêt de l’entrée. Même avec des journaux parfaits des recommandations, établir qu’une action humaine a été influencée par un agent suppose de corréler deux systèmes et d’accepter une conclusion inconfortable pour l’organisation. L’analyse post-incident tend naturellement vers la version la plus simple : l’opérateur s’est trompé. C’est le genre de pente que la culture juste sert précisément à corriger, et il faudra l’invoquer plus souvent qu’avant.

🐝 Ce qui arrive si on s’en passe

Sans journal des recommandations de l’agent corrélable avec les journaux de production, une action manipulée est indiscernable d’une erreur d’opérateur : le système cible montre une opération valide, approuvée, par une identité légitime, et l’enquête conclut à une faute humaine. L’agent reste alors en service avec la même configuration, et le mécanisme est reproductible à l’identique. Sans séparation entre le résumé de risque et le texte produit par l’agent, l’écran de validation affiche l’argumentaire de la partie intéressée : l’approbation ne porte plus sur l’action mais sur sa présentation, et un agent détourné obtient exactement les mêmes clics qu’un agent sain. Sans blocage des effets de bord en contexte d’aperçu, enfin, l’utilisateur déclenche une action en croyant consulter, et il n’existe aucun enregistrement de son intention réelle : le journal retient qu’il a ouvert un panneau, pas qu’il n’a rien voulu exécuter.

🦫 Explication de la marmotte 🍫

Un assistant informatique s’exprime bien. Il répond vite, poliment, avec des explications claires et le ton de quelqu’un qui sait. Cela crée de la confiance, et c’est utile : personne n’utiliserait un outil dont il doute à chaque phrase. Le risque décrit ici est que cette confiance devienne le moyen d’obtenir d’une personne ce qu’on n’aurait pas pu obtenir d’une machine.

Le mécanisme est celui de l’escroquerie classique, avec un avantage nouveau. L’assistant connaît vraiment le contexte interne : il peut citer de vrais numéros de dossier, de vrais noms, de vrais montants. Ses détails vérifiables sont vrais, ce qui rend crédible la partie qui ne l’est pas. Un nouvel employé à qui un assistant de support demande ses identifiants en citant ses propres tickets n’a pas de raison de se méfier.

Le point le plus gênant est ailleurs. C’est la personne qui accomplit l’action finale : elle clique, elle valide, elle vire l’argent. Les traces informatiques montreront donc une opération normale, autorisée, faite par un utilisateur identifié. Le rôle de l’assistant dans l’affaire n’apparaît nulle part, et l’enquête conclura à une erreur humaine.

Les protections ne sont pas des protections de machine. Il faut que l’écran de validation affiche ce que l’action va faire, écrit par un autre composant que l’assistant lui-même — on ne demande pas à l’intéressé de rédiger sa propre attestation. Il faut signaler visuellement ce qui est risqué, afficher quand une information n’est pas vérifiée, éviter les formulations rassurantes dans les moments sensibles, et garder la trace des conseils donnés, pas seulement des actions faites. Et il faut, surtout, soumettre moins de décisions à validation humaine : quelqu’un qui approuve deux cents fois par jour n’approuve plus rien.

Pages voisines

ASI09 : exploitation de la confiance entre humain et agent

Elle cite

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

ASI09 : exploitation de la confiance entre humain et agent

ASI09 : exploitation de la confiance entre humain et agent

Le mécanisme : la compromission devient invisible

Ce qui distingue ASI09 de ses voisins

Les formes qu’on rencontre

Réduire : ne pas demander à l’agent de se justifier

Ce que ces mesures ne font pas

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines