Les agents à usage informatique en divulguent trop par défaut

Un agent à usage informatique à qui l’on demande de transmettre « les chiffres du T3 » à un collègue doit décider ce qui compte comme les chiffres du T3, quel fichier les contient, et si le tableur ouvert juste à côté a sa place dans le même e-mail. En juin 2026, un banc d’essai a soumis 15 agents de pointe à ce type de décision et a constaté que 11 d’entre eux divulguaient des informations privées sur plus de la moitié des scénarios testés, avec un taux de fuite moyen de 67,9 %.¹

La défaillance de confidentialité des agents à usage informatique n’est pas l’injection d’invite. Aucun adversaire ne dissimule quoi que ce soit. L’agent laisse fuiter parce qu’il cherche à se rendre utile et ne parvient pas à distinguer quelle information appartient au contexte dans lequel il agit. Un nouvel article, Capable but Careless: Do Computer-Use Agents Follow Contextual Integrity?, nomme ce mode de défaillance, construit un banc d’essai pour le mesurer et montre qu’il est répandu sur l’ensemble du front de pointe.¹

Ce résultat mérite l’attention parce qu’il isole un risque que la conversation sur la sécurité des agents a largement laissé de côté. J’ai déjà écrit au sujet des deux entrées non fiables et des défaillances induites par un attaquant chez les agents qui utilisent des outils. La divulgation excessive contextuelle a la forme inverse : le danger est interne, il tient au propre jugement de l’agent sur la divulgation appropriée, et il se manifeste même lorsque rien de malveillant n’est en jeu.

En bref

• Les agents à usage informatique (CUA) agissent au travers d’applications personnelles telles que la messagerie, les calendriers et les listes de tâches. L’accès inter-applications est utile, mais il permet à un agent d’extraire une information d’un contexte pour la verser dans un autre où elle n’a pas sa place.¹
• Capable but Careless (2026) introduit AgentCIBench, un banc d’essai qui transforme ce risque en scénarios exécutables et évalués de façon déterministe, et évalue 15 agents de pointe.¹
• Le banc d’essai cible trois modes de défaillance : la co-localisation visuelle, la divulgation excessive par ambiguïté de la tâche et le mauvais alignement du destinataire.¹
• Onze des 15 agents ont fui sur plus de 50 % des scénarios, pour une fuite moyenne de 67,9 %, et les défaillances ont persisté lorsque les agents agissaient de bout en bout pour accomplir la tâche.¹
• Le cadre retenu est celui de l’intégrité contextuelle, l’idée d’Helen Nissenbaum selon laquelle la confidentialité porte sur la circulation appropriée de l’information au regard de son contexte, et non sur le secret.² Les agents sont compétents ; ce qui leur manque, c’est le sens de l’endroit où l’information a le droit d’aller.

Une défaillance différente de l’injection d’invite

La plupart des travaux sur la sécurité des agents, y compris les miens, partent d’un adversaire. Quelqu’un dissimule une instruction dans une page web, une description d’outil ou un document, et l’agent y obéit. La défense consiste à se méfier des entrées et à restreindre ce que l’agent peut en faire.

La divulgation excessive contextuelle n’a pas d’adversaire. L’utilisateur formule une demande raisonnable, l’agent cherche à la satisfaire et, ce faisant, divulgue quelque chose qui relevait d’un autre contexte. L’article aborde cela à travers l’intégrité contextuelle, la théorie de la confidentialité d’Helen Nissenbaum, qui soutient que les flux d’information portent des normes liées au contexte dans lequel ils se produisent.² Que votre thérapeute connaisse votre diagnostic est approprié. Que votre thérapeute le transmette à votre employeur viole la norme, même si aucun secret n’a techniquement été rompu, parce que l’information a franchi une frontière contextuelle qu’elle n’était pas censée franchir.

Un agent à usage informatique opère simultanément au travers de nombreux contextes de ce genre. Il peut voir votre calendrier pendant qu’il rédige un e-mail, votre liste de contacts complète pendant qu’il envoie un message à une seule personne, votre liste de tâches entière pendant qu’il répond à une question sur un seul élément. Chacune de ces adjacences est une occasion d’extraire ce qui est approprié à un endroit pour le placer là où il ne l’est pas. L’agent n’est pas compromis. Il est excessivement serviable, et la serviabilité excessive dans un environnement multi-contextes ressemble à une fuite de confidentialité.

Les trois façons dont les agents laissent fuiter

AgentCIBench opérationnalise ce risque sous la forme de scénarios évalués de façon déterministe selon trois modes de défaillance, et c’est la partie de l’article qu’il vaut la peine d’assimiler, car chacun correspond à une interface réelle que l’agent touche.¹

Co-localisation visuelle. L’agent extrait des éléments interdits qui se trouvent à côté de la cible de la tâche dans l’interface. À qui l’on demande de joindre une seule facture, il attrape aussi celle d’à côté, parce que les deux étaient à l’écran et que la proximité s’est lue comme une pertinence. C’est la disposition de l’interface, et non la tâche, qui a provoqué la divulgation.

Divulgation excessive par ambiguïté de la tâche. Face à une invite sous-spécifiée, l’agent déverse un état personnel dense plutôt que de demander des précisions ou de restreindre sa réponse. « Dites-leur sur quoi je travaille » devient la liste de tâches entière, y compris les éléments que le destinataire ne devrait jamais voir. L’ambiguïté se résout vers davantage de divulgation, et non vers moins.

Mauvais alignement du destinataire. L’agent envoie un contenu à un destinataire pour qui il est inapproprié. La bonne information parvient à la mauvaise personne, un réflexe de réponse à tous appliqué à des données qui relevaient d’une seule relation.

Ces trois modes partagent une cause profonde. L’agent assimile l’accès à une permission. Parce qu’il peut voir la facture adjacente, la liste de tâches complète, le bassin de destinataires plus large, il se comporte comme s’il était approprié d’utiliser cet accès. L’intégrité contextuelle est précisément le jugement selon lequel l’accès et le caractère approprié sont deux choses différentes, et le banc d’essai montre que les agents actuels ne font pas cette distinction de façon fiable.

À quel point est-ce grave, et pourquoi cela persiste

Les chiffres marquants ne sont pas marginaux. Sur 15 agents de pointe, 11 ont fui sur plus de la moitié des scénarios, et la fuite moyenne a atteint 67,9 %.¹ Un mode de défaillance qui se manifeste deux fois sur trois chez la plupart des acteurs n’est pas un cas limite. C’est un comportement par défaut.

Le détail qui compte le plus pour quiconque met des agents en production, c’est que les défaillances ont persisté lorsque les agents agissaient de bout en bout dans l’environnement pour accomplir la tâche, et pas seulement lors de sondages isolés.¹ Une fuite qui n’apparaîtrait que dans des conditions artificielles serait facile à écarter. Une fuite qui survit à l’agent en train de faire un vrai travail est une propriété de sa façon d’opérer, et l’article présente pour cette raison précise le test de divulgation contextuelle comme un contrôle de sûreté préalable au déploiement.¹

La raison pour laquelle la défaillance persiste, c’est que rien dans l’objectif normal de l’agent ne s’y oppose. L’agent est récompensé pour l’accomplissement de la tâche. Divulguer trop bloque rarement cet accomplissement, de sorte que la divulgation excessive n’entraîne aucun coût dans la boucle qui façonne le comportement. Sans un signal explicite indiquant qu’une partie de l’information accessible est hors limites dans ce contexte, le chemin serviable et le chemin qui fuit sont un seul et même chemin.

Que faire à ce sujet

Le correctif ne consiste pas à rendre les agents moins compétents. Il consiste à faire du caractère approprié une contrainte que l’agent vérifie, plutôt qu’une norme qu’on suppose qu’il déduira. Le schéma fait écho à ce que j’ai défendu au sujet des invites d’approbation : on ne devrait pas faire confiance à l’agent pour décider en silence de ce qui franchit une frontière.

Conditionnez la divulgation au destinataire et au contexte, pas à l’accès. Avant qu’un agent envoie, joigne ou partage, la question pertinente n’est pas « l’agent peut-il voir ceci » mais « ceci a-t-il sa place dans ce flux, à destination de ce destinataire ». L’accès est un mauvais indicateur de la permission, et les trois modes de défaillance sont autant de cas où on l’emploie comme tel.

Traitez l’ambiguïté comme un arrêt, pas comme une autorisation. Une demande sous-spécifiée est l’entrée la plus risquée, parce que l’agent la résout vers la divulgation. Un agent qui restreint sa réponse ou demande des précisions lorsqu’une requête est vague laisse fuiter moins d’informations qu’un agent qui comble le vide avec tout ce qu’il peut voir.

Testez la fuite avant le déploiement. L’apport de l’article est en partie une méthode : des scénarios évalués de façon déterministe qui transforment l’intégrité contextuelle en quelque chose de mesurable. Traiter la divulgation contextuelle comme un contrôle préalable au déploiement, aux côtés des contrôles d’observabilité et de mise en bac à sable qui détectent les défaillances induites par un attaquant, comble une lacune que ces contrôles ne couvrent pas.

Le point plus général, c’est que la sûreté des agents comporte deux moitiés. L’une est adversariale : entrées non fiables, injection, empoisonnement d’outils, les défaillances qu’un attaquant provoque. L’autre est dispositionnelle : ce que l’agent fait d’un accès légitime quand personne ne l’attaque. Les agents à usage informatique sont suffisamment compétents pour agir au travers de chaque contexte que vous possédez. La question de savoir s’ils devraient le faire est une question à laquelle ils répondent aujourd’hui de travers deux fois sur trois.

Points clés à retenir

Pour les personnes qui déploient des agents à usage informatique : - Ajoutez le test de divulgation contextuelle à vos contrôles préalables au déploiement. Les évaluations centrées sur l’attaquant ne détectent pas la divulgation excessive. - Conditionnez les actions de partage au caractère approprié du destinataire et du contexte, et non à la capacité de l’agent à accéder aux données. - Traitez les requêtes vagues comme le cas le plus risqué, car les agents résolvent l’ambiguïté vers davantage de divulgation.

Pour les concepteurs d’agents et de produits : - Les trois modes de défaillance (co-localisation visuelle, divulgation excessive par ambiguïté de la tâche, mauvais alignement du destinataire) correspondent à des surfaces d’interface concrètes. Concevez chaque surface en partant du principe que la proximité sera lue comme une pertinence. - La récompense liée à l’accomplissement de la tâche ne donne aucun signal contre la divulgation excessive. Si le caractère approprié compte, faites-en une contrainte explicite.

Pour les évaluateurs de sécurité et de confidentialité : - L’intégrité contextuelle fournit un cadre exploitable : évaluez les flux d’information au regard des normes du contexte, et non au regard d’un binaire secret/non-secret. - Un taux de fuite moyen de 67,9 % sur l’ensemble des agents de pointe signifie que les valeurs par défaut actuelles ne sont pas sûres pour une action autonome multi-contextes en l’absence de contrôles de divulgation.

FAQ

Qu’est-ce que l’intégrité contextuelle ?

L’intégrité contextuelle est une théorie de la confidentialité d’Helen Nissenbaum selon laquelle les flux d’information portent des normes liées au contexte dans lequel ils se produisent. La confidentialité est préservée lorsque l’information circule de manières appropriées à son contexte, et violée lorsqu’elle franchit la frontière vers un contexte dont les normes en vigueur n’autorisent pas cette circulation, même si rien n’était techniquement secret.

En quoi est-ce différent de l’injection d’invite ?

L’injection d’invite est adversariale : un attaquant dissimule des instructions qui détournent l’agent. La divulgation excessive contextuelle n’a pas d’attaquant. L’utilisateur formule une demande légitime et l’agent, cherchant à aider, divulgue une information qui relevait d’un autre contexte. Les deux exigent des défenses différentes, et les tests centrés sur l’attaquant ne détectent pas la divulgation excessive.

Qu’est-ce qu’AgentCIBench ?

AgentCIBench est le banc d’essai introduit dans Capable but Careless qui transforme la fuite entre contextes en scénarios exécutables et évalués de façon déterministe. Il teste trois modes de défaillance (co-localisation visuelle, divulgation excessive par ambiguïté de la tâche et mauvais alignement du destinataire) et a servi à évaluer 15 agents à usage informatique de pointe.

Combien d’agents ont échoué ?

Sur 15 agents de pointe testés, 11 ont divulgué des informations privées sur plus de 50 % des scénarios, avec un taux de fuite moyen de 67,9 %. Les défaillances ont persisté lorsque les agents agissaient de bout en bout pour accomplir les tâches, et pas seulement lors de sondages isolés.

Puis-je corriger cela par une meilleure rédaction d’invites ?

La rédaction d’invites peut aider, mais le cadre de l’article suggère que le correctif durable est structurel : conditionner les actions de divulgation au caractère approprié du destinataire et du contexte plutôt qu’à l’accès, et tester la fuite avant le déploiement. Parce que les objectifs d’accomplissement de la tâche ne donnent aucun signal contre la divulgation excessive, le caractère approprié doit être imposé comme une contrainte plutôt que supposé.

Sources

• Anmol Goel et Iryna Gurevych, “Capable but Careless: Do Computer-Use Agents Follow Contextual Integrity?”, arXiv, 22 juin 2026 : arxiv.org/abs/2606.23189
• Helen Nissenbaum, “Privacy as Contextual Integrity”, Washington Law Review 79, n° 1 (2004), à l’origine du cadre, développé par la suite dans Privacy in Context (Stanford University Press, 2010) : Washington Law Review
• Écrits connexes sur la sécurité des agents : deux entrées non fiables, les invites d’approbation ne sont pas une autorisation et l’agent invisible