Quand les agents « computer-use » cliquent sur des pixels périmés : la course écran-action

De quoi s’agit-il ?

Le 25 juin 2026, le chercheur en sécurité Johann Rehberger (Embrace The Red) a publié Computer-Use and TOCTOU: What You Click Is Not What You Get, une analyse d’une classe de conditions de course qui touche tout agent pilotant un écran en le regardant. Le billet reproduit et étend un résultat antérieur : en 2025, Jun Kokatsu a divulgué qu’OpenAI Operator pouvait être amené à cliquer sur une origine arbitraire en exploitant le délai entre ce que l’agent voit et ce qu’il fait (advisory Google security-research).

Le bug sous-jacent est ancien. TOCTOU — time-of-check to time-of-use (CWE-367) — désigne tout système qui valide une condition puis agit comme si rien n’avait changé dans l’intervalle. Les systèmes d’exploitation le combattent depuis des décennies. Les agents « computer-use » le réintroduisent à un nouvel endroit : les pixels de l’écran.

Comment ça marche

Un agent computer-use fonctionne en boucle : il prend une capture d’écran, raisonne sur ce qu’il voit, puis émet une action — cliquer à ces coordonnées, saisir ce texte. Le raisonnement est la vérification ; le clic est l’action. Or l’inférence du modèle prend plusieurs secondes, et l’écran peut changer pendant cette fenêtre. Quand c’est le cas, l’action atterrit sur ce qui se trouve désormais à ces coordonnées, et non sur ce que l’agent croyait y voir.

Rehberger a d’abord confirmé l’effet avec une page triviale : un bouton OKAY remplacé par un autre bouton après deux secondes. Claude Computer-Use a cliqué quand même, de façon fiable. Il a ensuite construit une chaîne réellement nuisible. Outlook (comme d’autres clients de messagerie) prend en charge un lien profond qui ouvre un e-mail entièrement pré-rédigé à partir d’une seule URL — destinataire, objet et corps déjà remplis, ne laissant qu’à cliquer sur Envoyer. La page de phishing de l’attaquant affiche un bouton anodin « Cliquez ici pour continuer » placé aux coordonnées exactes où apparaîtra le bouton Envoyer d’Outlook une fois le brouillon chargé. L’agent, à qui on demande de cliquer Continuer, clique en réalité Envoyer sur un e-mail rédigé par l’attaquant.

Un détail pratique rend la course fiable plutôt que chanceuse : l’attaquant a besoin que l’interface cible finisse de se charger pendant l’intervalle de raisonnement. La preuve de concept de Rehberger utilisait une instruction d’injection demandant à l’agent de calculer d’abord 1+1 via une commande shell — un ralentissement délibéré qui procure les quatre à cinq secondes nécessaires au rendu d’Outlook avant le clic. Autrement dit, la fenêtre temporelle peut être élargie par l’attaquant, pas seulement attendue.

Pourquoi c’est important

Il s’agit d’un problème de député confus au niveau des coordonnées : l’autorité de l’agent est réelle, mais la cible de son action a été silencieusement substituée. Comme le clic est une action véritable et modificatrice d’état — envoyer un message, confirmer un paiement, changer un réglage — un contrôle de sécurité exécuté après coup arrive déjà trop tard. Le même mécanisme produit aussi de simples accidents, pas uniquement des attaques : tout agent agissant sur une image périmée peut opérer sur le mauvais objet dès qu’une page se recompose, qu’une boîte de dialogue surgit ou qu’un contenu se charge tardivement.

Cela généralise la classe plus large du TOCTOU dans les agents jusqu’au pixel. Tout ce qui perçoit le monde, marque une pause pour réfléchir, puis agit sur la perception antérieure est exposé — les agents GUI au premier chef, mais le schéma se répète dans les agents de navigation et à outils.

Défenses

Le correctif est aussi ancien que le bug : re-vérifier au moment de l’action. Capturer la région d’écran pertinente au début du raisonnement, et avant d’exécuter l’action, vérifier que cette région n’a pas changé de façon significative ; si c’est le cas, re-percevoir et re-planifier plutôt que de valider un clic périmé. Anthropic a confirmé à Rehberger qu’il suivait déjà ce risque durant la préversion de Computer-Use, et lorsqu’il a livré Cowork avec computer-use, l’équipe a indiqué qu’elle s’assure désormais que les pixels n’ont pas changé avant une action — exactement ce contrôle de stabilité des pixels.

Superposez d’autres contrôles autour. Traitez les actions à conséquence — envoyer, acheter, supprimer, accorder un accès — comme des points de contrôle exigeant une confirmation ou une nouvelle observation délibérée, et non comme des clics « tire-et-oublie ». Restreignez le périmètre d’action de l’agent : un agent qui n’opère qu’à l’intérieur d’une application connue est plus difficile à rediriger vers un élément attaquant superposé. Réduisez autant que possible la fenêtre entre raisonnement et action, car un intervalle plus long est une course plus large. Et n’oubliez pas le volet injection : la chaîne de Rehberger débutait par une injection de prompt qui à la fois pilotait et ralentissait l’agent, donc le traitement du contenu non fiable et des boucles résistantes aux ralentissements comptent autant que le contrôle visuel.

Statut

La course TOCTOU sur computer-use a été initialement signalée par Jun Kokatsu contre OpenAI Operator en 2025, puis reproduite contre Claude Computer-Use par Johann Rehberger, qui l’a signalée à Anthropic en octobre 2025 ainsi qu’à plusieurs autres éditeurs. Anthropic l’a reconnue, a rappelé que Computer-Use était alors en préversion, et a ensuite ajouté un contrôle de stabilité des pixels dans sa version computer-use de Cowork. Rehberger a publié l’analyse le 25 juin 2026, après l’avoir démontrée à la conférence Real-World AI Security de Stanford. Aucun CVE n’est attaché à la reproduction sur Claude ; le problème d’origine sur Operator est suivi dans un advisory Google security-research. À lire comme un rappel : durcir les agents computer-use, c’est réimporter des décennies de discipline des systèmes d’exploitation — à commencer par ne jamais faire confiance à une vérification effectuée quelques secondes plus tôt.