Ton agent de code fait confiance aux métadonnées. C'est le problème.

Bon. Je vais commencer par le scénario qui fait mal.

Ton agent de code lit un fichier JSON, un DOM de page web, ou une issue GitHub. Quelque part là-dedans, un attaquant a glissé un faux champ qui ressemble à s’y méprendre à une métadonnée légitime — un ID de ressource, une origine de commit, un “posté par le mainteneur”. L’agent ne se fait pas piéger par une instruction. Il se fait piéger par une donnée qu’il croit fiable.

C’est exactement ce que décrit un papier publié début juillet 2026 sur arXiv, autour d’une technique baptisée Agent Data Injection (ADI). Et franchement, c’est plus inquiétant que le prompt injection classique, parce que ça ne demande même pas à l’agent d’exécuter une tâche pilotée par l’attaquant. Ça lui fait juste croire à un mensonge sur la provenance des données.

Le truc c’est que le délimiteur n’a pas besoin d’être exact

La faille technique s’appelle le probabilistic delimiter injection. L’idée : un LLM n’analyse pas une structure JSON ou un DOM comme un parseur déterministe. Il interprète ça de façon probabiliste. Du coup, un délimiteur injecté — genre un guillemet échappé qu’un vrai parseur JSON rejetterait direct — peut suffire à faire croire au modèle qu’il vient de lire une frontière structurelle valide. Résultat : de fausses métadonnées apparaissent comme authentiques aux yeux de l’agent, alors qu’un système classique les aurait recalées à la porte.

Les chercheurs ont testé ça sur trois agents de code — Claude Code, Codex et Gemini CLI — et trois agents web (Claude in Chrome, Antigravity, Nanobrowser). Tous vulnérables, à des degrés divers.

Trois attaques concrètes, pas des scénarios de labo

Ce qui rend le papier utile, c’est qu’il ne reste pas dans l’abstrait. Trois attaques démontrées, directement transposables à un vrai workflow de dev agentique :

• Remote Code Execution via métadonnées forgées. L’attaquant fabrique une origine de commande qui fait croire à l’agent que la commande vient d’un mainteneur du repo. L’agent l’exécute avec la confiance qu’il aurait accordée à un humain de confiance.
• Supply chain attack. L’attaquant fabrique un bloc d’appel d’outil entier — le genre de structure que l’agent utilise pour dire “j’ai vérifié le code, je merge”. Sauf qu’il n’a rien vérifié du tout. Le PR malveillant passe.
• Arbitrary click sur les agents web : un faux élément UI avec un identifiant qui matche un élément réel, pour faire cliquer l’agent sur un bouton sensible sans qu’il l’ait choisi.

Le point commun : dans les trois cas, l’agent ne “désobéit” pas. Il fait exactement ce qu’on lui a appris à faire — faire confiance aux métadonnées de contexte — sauf que ces métadonnées sont fausses.

Les chiffres, tels qu’ils sont dans l’étude

Je ne vais pas transformer ça en mes propres mesures, ce sont celles du papier. Sur des attaques de délimiteurs en JSON, le taux de succès (ASR) tourne entre 31,3 % et 43,3 % selon le modèle — GPT-5.2 à 41,8 %, Claude Opus 4.5 à 34,3 %, Gemini 3 Flash à 43,3 %. Sur du DOM web, ça grimpe carrément jusqu’à 100 % pour certains modèles.

Plus intéressant : au niveau agent complet (pas juste le LLM nu), sur le benchmark AgentDojo, l’ADI atteint 49,1 % d’ASR en baseline — contre 0,2 % pour l’injection d’instructions classique sur le même agent. Autrement dit : les agents actuels ont déjà un peu appris à se méfier des instructions suspectes. Ils n’ont pas encore appris à se méfier des métadonnées.

La revue de 78 études confirme que ce n’est pas un cas isolé

Un deuxième papier, une revue systématique (SoK) qui synthétise 78 études publiées entre 2021 et 2026 sur la sécurité des assistants de code agentiques — en citant nommément Claude Code, GitHub Copilot et Cursor — arrive à une conclusion qui devrait piquer plus fort que n’importe quel chiffre isolé : les attaques adaptatives dépassent 85 % de taux de succès contre les défenses de pointe. Et la plupart des 18 mécanismes de défense analysés dans la revue n’atteignent même pas 50 % d’atténuation face à un attaquant qui s’adapte.

Ça veut dire quoi concrètement ? Que les défenses testées en labo marchent contre l’attaque d’hier. Contre un attaquant qui regarde ta défense et ajuste sa charge en conséquence, elles s’effondrent.

Ce qui marche un peu, ce qui ne marche pas du tout

Le papier ADI a le mérite de tester huit catégories de défense, pas juste d’en vanter une. Voici ce qui ressort, honnêtement.

Ce qui atténue vraiment, avec un vrai coût : le data flow tracking en mode strict (traçage de provenance des données avec politique serrée) ramène l’ASR à 0 %. Mais l’utilité bénigne de l’agent chute de 50 % dans le même mouvement. L’agent sandboxing avec des politiques précises ramène l’ASR résiduel à 22,2 %, ce qui reste non négligeable mais divise le risque par deux.

Ce qui ne sert quasiment à rien : les input guardrails classiques, censés filtrer le contenu suspect en entrée, laissent l’ASR à 50 % — autant dire zéro effet sur l’ADI, alors qu’ils détectent 34,9 % des injections d’instructions classiques. Autrement dit, les garde-fous qu’on connaît bien fonctionnent sur l’ancienne génération d’attaque et sont aveugles à la nouvelle.

Ce qui marche mais casse tout : la randomisation (attacher un nonce aléatoire aux noms de champs) fait chuter l’ASR en JSON à quasi zéro. Sauf que sur du DOM web, si l’attaquant devine correctement le nonce, l’ASR remonte à 60-100 %. Et la sanitisation stricte (retirer les délimiteurs suspects) fait tomber l’ASR à 0-3 %, mais dégrade l’utilité normale de l’agent de 81-85 % à 68-72 %. En clair : tu peux sécuriser l’agent en le rendant à moitié inutile.

Ce que ça change dans un vrai workflow de dev

Le marketing autour des agents parle d’autonomie comme d’une feature : l’agent navigue seul, lit les issues seul, merge seul. Chaque capacité en plus est vendue comme un gain de productivité. Sauf que chaque capacité en plus, c’est aussi une porte de plus pour un contenu non fiable qu’on n’a pas vérifié.

Ce que je retiens pour un usage réel, pas pour un rapport de recherche :

• N’accorde jamais l’autonomie de merge à un agent sans un humain qui relit le diff réel, pas le résumé que l’agent en fait. Le scénario “supply chain attack” du papier repose exactement là-dessus : l’agent affirme avoir vérifié, il n’a rien vérifié.
• Sandbox tout ce qui exécute des commandes. L’agent sandboxing reste la seule défense qui a montré un vrai effet mesuré (22,2 % d’ASR résiduel) sans détruire l’utilité, à condition d’avoir des politiques précises — pas un sandbox vague avec accès réseau libre.
• Allowlist les commandes sensibles, pas les instructions. Le point faible de l’ADI, c’est que l’attaquant forge une origine (“posté par le mainteneur”), pas une commande en soi. Une allowlist qui ignore la provenance déclarée et se fie uniquement à la nature de la commande limite la casse.
• Traite tout contenu ingéré comme non fiable par défaut — issues, PR, pages web, sorties d’outils tiers. Pas seulement le prompt utilisateur. C’est le principe que la plupart des architectures actuelles ne respectent pas encore, selon les deux papiers.
• N’attends pas un garde-fou magique. Les input/output guardrails classiques n’arrêtent quasiment pas l’ADI. Si ton seul filet de sécurité est un filtre de contenu en entrée, tu es exposé.

Ma lecture

La sécurité des agents de code n’est pas un détail qu’on réglera plus tard. C’est structurellement en retard sur l’autonomie qu’on leur donne. Plus un agent peut naviguer, lire, exécuter et merger seul, plus la surface d’attaque grandit — et les défenses qui existent aujourd’hui, testées sérieusement, tiennent soit en cassant l’utilité, soit pas du tout face à un attaquant qui s’adapte.

Ça ne veut pas dire qu’il faut jeter les agents. Ça veut dire qu’il faut arrêter de vendre l’autonomie comme une fonctionnalité sans compter le coût de la surface qu’elle ouvre. Le human-in-the-loop sur les actions sensibles n’est pas une case de compliance à cocher. C’est, à ce stade, la seule chose qui marche vraiment.

Sources

• Agent Data Injection Attacks — arXiv:2607.05120v1
• Prompt Injection Attacks on Agentic Coding Assistants: A Systematic Analysis of Vulnerabilities in Skills, Tools, and Protocol Ecosystems — arXiv:2601.17548