TOCTOU dans les agents IA : violations d'atomicité entre observation et action
Une vieille faille des systèmes d'exploitation refait surface dans les agents : le monde change entre le moment où l'agent regarde et celui où il agit. Des travaux de 2026 la formalisent pour les agents GUI, navigateur et multi-agents.
De quoi s’agit-il ?
Le Time-Of-Check to Time-Of-Use (TOCTOU, CWE-367) est une classe de bug des systèmes d’exploitation vieille de plusieurs décennies : un programme vérifie une condition, puis agit en conséquence, mais l’état change dans la fenêtre entre les deux — si bien que la vérification était valide au moment où elle a eu lieu et ne l’est plus quand l’action s’exécute. Trois publications indépendantes en 2026 montrent que les agents IA réintroduisent cette faille, et que la fenêtre temporelle est plus large que dans le logiciel classique, car l’agent attend l’inférence du modèle entre la perception et l’action.
Un article de l’UC San Diego, “Temporal UI State Inconsistency in Desktop GUI Agents” (arXiv:2604.18860, 20 avril 2026), la formalise pour les agents « computer-use » sous le nom de Violation d’atomicité visuelle. Un article parallèle, “Atomicity for Agents” (arXiv:2603.00476, février 2026), documente la même faille dans les agents de navigation. Et le chercheur en sécurité Joe Bollen l’a décrite (5 avril 2026) dans l’orchestration multi-agents, contribuant une nouvelle exigence au standard OWASP AISVS.
Comment ça marche
Un agent à boucle capture-et-clic procède ainsi : capturer l’écran (la vérification), envoyer les pixels à un modèle, attendre une décision, puis déclencher un clic à des coordonnées fixes (l’usage). L’équipe de l’UC San Diego a mesuré l’écart entre observation et action — l’écart observation-action — à une moyenne de 6,51 secondes sur de vraies charges OSWorld. C’est une fenêtre énorme pour qu’un processus local non privilégié ou un contenu web dynamique réorganise l’interface après que l’agent a « décidé » mais avant qu’il agisse.
L’article caractérise trois primitives d’attaque, toutes des démonstrations défensives et non des exploits déployables :
# Conceptuel uniquement — illustratif, pas un payload actionnable.
A) Notification Overlay Hijack — superposer un calque sur la cible de l'agent après la capture
B) Window Focus Manipulation — déplacer le focus pour qu'un clic à coordonnées fixes atteigne un autre contrôle
C) Web DOM Injection — muter le DOM sous le curseur sans empreinte visuelle
La primitive B — l’analogue de bureau le plus proche de l’« action rebinding » d’Android — atteint un taux de redirection d’action de 100 % sans aucune trace visuelle au moment de l’observation : la capture sur laquelle l’agent a raisonné paraissait parfaitement bénigne. La faille est indépendante du modèle, reproduite sur les trois modèles de pointe testés par les auteurs (l’article cite Claude Opus 4.6, GPT-4o et Qwen3.6-plus).
La variante multi-agents ne requiert aucune interface. Lorsqu’un Agent de remboursement et un Agent anti-fraude lisent et écrivent le même état de compte en parallèle, un remboursement peut être émis dans les millisecondes avant qu’un gel pour fraude n’intervienne — chaque agent se comporte correctement isolément, mais l’entrelacement laisse la valeur quitter le système. C’est le même danger que le lethal trifecta, vu depuis la couche d’orchestration plutôt que la couche de prompt.
Pourquoi c’est important
Il s’agit d’une vulnérabilité de logique et de temporalité, pas de contenu de prompt ; les défenses habituelles passent donc à côté. Les filtres d’entrée, les hiérarchies d’instructions et les classifieurs de jailbreak inspectent tous du texte ; aucun ne remarque que l’écran a bougé ou qu’un autre agent a écrit en premier. Les tests séquentiels échouent aussi, car le bug n’existe que sous exécution concurrente ou changement d’interface au timing adverse — le système semble fonctionner quand on vérifie l’état final et le journal d’audit.
Le rayon d’impact croît avec l’autonomie. Un agent computer-use qui clique « Confirmer » sur la mauvaise boîte de dialogue, ou un agent de facturation qui paie un compte signalé, produit un effet réel qu’aucune relecture de journaux a posteriori n’annule.
Défenses
Le correctif unificateur est l’atomicité : rendre la vérification et l’usage indissociables.
Pour les agents GUI et navigateur, re-vérifiez le monde juste avant chaque action. La Pre-execution UI State Verification (PUSV) de l’UC San Diego le fait en trois couches — SSIM à pixels masqués sur la cible du clic, diff de capture globale, et diff de capture de fenêtre — et rapporte un taux d’interception d’action de 100 % sur 180 essais adverses, sans faux positif et avec moins de 0,1 s de surcoût. Surtout, aucune couche seule n’a tout intercepté (la primitive d’injection DOM sans empreinte a échappé aux contrôles de pixels), ce qui plaide pour une défense en profondeur entre l’OS et le DOM plutôt qu’un seul détecteur. L’article sur les agents de navigation propose la même forme de mitigation : valider l’état du DOM et de la mise en page juste avant l’exécution. Cela généralise l’idée de « regarder à nouveau avant de valider » derrière la validation des flux d’outils avant commit et les gardes par capture comme SnapGuard.
Pour les systèmes multi-agents, poussez l’atomicité dans la couche d’état : transactions de base de données, verrouillage optimiste ou compare-and-swap, afin qu’une vérification d’autorisation et la mutation qu’elle conditionne ne puissent être scindées par l’écriture d’un autre agent. Ce sont des primitives de concurrence familières, négligées quand les équipes se concentrent sur le comportement du modèle plutôt que sur l’orchestration. Maintenir les agents dans l’Agents Rule of Two limite les dégâts d’une course perdue.
Statut
| Contexte | Publication | Date | Défense proposée |
|---|---|---|---|
| Agents bureau / computer-use | arXiv:2604.18860 (UC San Diego) | 20 avr. 2026 | PUSV (re-vérification UI avant exécution) |
| Agents de navigation | arXiv:2603.00476 | févr. 2026 | Validation DOM/mise en page avant exécution |
| Orchestration multi-agents | Contribution OWASP AISVS (J. Bollen) | 5 avr. 2026 | Atomicité côté état (verrous / CAS) |
Les trois sont des travaux publiés assortis de mitigations fonctionnelles ; aucun ne décrit un 0-day produit non corrigé. Le TOCTOU dans les agents est un risque de conception à anticiper, pas un CVE unique à attendre.