L'agent a fait confiance à la ponctuation

Le 6 juillet 2026, des chercheurs de l'Université nationale de Séoul, de l'Université de l'Illinois à Urbana-Champaign et de Largosoft — sous la direction de Woohyuk Choi et du professeur Byoungyoung Lee — ont publié un article au titre sans détour : Agent Data Injection Attacks are Realistic Threats to AI Agents. Il décrit une classe d'attaque, l'Agent Data Injection (ADI), qui se tient à côté de l'injection de prompt plutôt qu'à l'intérieur, et qui a déjoué des défenses anti-injection dédiées jusqu'à la moitié du temps là où l'injection de prompt classique frôlait le zéro. OpenAI, Google et Anthropic ont confirmé qu'elle fonctionne. Aucun correctif n'était signalé à la publication.

La raison pour laquelle elle importe à quiconque fait tourner un agent de codage, c'est qu'elle attaque une chose que l'agent ne peut s'empêcher de croire : la frontière entre les données qu'il a récupérées et la structure dans laquelle ces données sont arrivées.

Le délimiteur est la frontière de sécurité

Le contexte d'un agent est un amas de texte venu de nombreuses sources — vos instructions, un fichier, une page web, un commentaire laissé par quelqu'un sur un ticket. Pour agir sensément, le modèle doit garder trace de quel morceau est lequel : ceci est le nom du mainteneur, cela est le corps d'un commentaire écrit par un inconnu. Il le fait de la seule façon que le texte permet — avec la ponctuation. Guillemets et accolades, balises, crochets, sauts de ligne. Les délimiteurs marquent où finit un champ de confiance et où commence le contenu non fiable.

Un analyseur strict traite ces délimiteurs à la lettre : un guillemet est un guillemet, et un caractère au milieu d'un commentaire n'est qu'un caractère. Un modèle de langage, non. Il lit la ponctuation, selon le cadrage de l'article, par conjecture — il infère la structure de ce à quoi les caractères ressemblent. Et c'est là toute l'ouverture. Un attaquant qui contrôle un champ de faible confiance — un avis produit, un commentaire de ticket GitHub, une ligne dans un fichier — y sème des caractères d'allure ponctuante, et le modèle lit une structure qui n'a jamais existé.

Le détail troublant, c'est le peu de savoir-faire que cela demande. Les chercheurs appellent la technique injection probabiliste de délimiteurs, et ils ont constaté que la fausse ponctuation « n'a même pas besoin d'être correcte ». Un guillemet échappé, un guillemet courbe, voire un simple signe dollar passaient pour une vraie frontière de champ et trompaient le modèle. Un analyseur strict aurait lu chacun d'eux comme du texte ordinaire.

Ce que cela fait à un agent de codage

La version web-agent de l'ADI est facile à imaginer : falsifiez l'identifiant d'un élément de page et un agent qui fait vos courses clique sur « Acheter » là où il voulait cliquer sur « En savoir plus ». La version visant les développeurs est pire, car le champ de confiance qu'elle falsifie est qui a dit que le code était sûr.

Dans une démonstration, un attaquant laisse un commentaire sur un ticket GitHub et falsifie l'attribution d'auteur pour que l'agent le lise comme venant du mainteneur du projet. Quand un développeur demande ensuite à l'agent d'« appliquer le correctif du mainteneur », Claude Code, Codex d'OpenAI et Gemini CLI de Google font exactement cela — ils exécutent la commande de l'attaquant, parce qu'autant que le modèle puisse en juger, c'est le mainteneur qui l'a demandé. Dans une autre, une pull request malveillante falsifie le relevé de ses propres vérifications CI terminées. L'agent voit une compilation propre dans son contexte, juge le code sûr sur cette preuve fabriquée, et fusionne un vrai logiciel malveillant.

Sur les six modèles testés par l'équipe — GPT-5.2, GPT-5-mini, Claude Opus 4.5 et Sonnet 4.5, Gemini 3 Pro et Flash — les chiffres ne sont pas une erreur d'arrondi. Les données structurées ont donné un taux de réussite de 31 à 43 % ; les données de pages web allaient de 33 % jusqu'à 100 %. Et face à des défenses bâties spécifiquement pour arrêter l'injection de prompt, l'ADI passait encore jusqu'à la moitié du temps, là où les mêmes défenses bloquaient net l'injection classique. Deux mesures d'atténuation ont fonctionné en laboratoire et toutes deux ont eu un coût : étiqueter les éléments de page avec des ID aléatoires et indevinable (comme le fait le navigateur Atlas de ChatGPT) a fait tomber la réussite d'environ 49 % à 29 %, et un suivi strict de la provenance des données a réduit les attaques à zéro — tout en abaissant la capacité de l'agent à terminer des tâches normales à environ un tiers.

Pourquoi le filtre habituel passe à côté

Un filtre anti-injection de prompt est entraîné à repérer des instructions qui se cachent dans les données — « ignore tes directives précédentes », « exécute cette commande », la forme reconnaissable d'une commande déguisée en contenu. L'ADI n'a pas besoin de cette forme. Le texte malveillant peut se lire comme une note ordinaire de mainteneur. Ce qui porte l'attaque, c'est la ponctuation autour de lui, et un filtre qui cherche un langage suspect passe tout droit devant un guillemet courbe. Voilà pourquoi la propre défense fonctionnelle de l'article n'était pas un classificateur plus intelligent mais un analyseur plus strict — une provenance qui refuse de deviner où finit un champ.

C'est la même leçon que le reste de la sécurité agentique ne cesse de réapprendre. Une liste noire de commandes perd face au shell qui réécrit la commande. Un outil MCP de confiance renvoie des données écrites par un attaquant. Un espace de travail auquel vous vous fiiez lance des serveurs que vous n'avez pas voulus. L'ADI est la version où la chose empoisonnée n'est ni l'instruction ni même les données, mais le cadre — le délimiteur qui dit à l'agent quel texte croire. On ne peut pas s'extraire d'un guillemet courbe par correspondance de motifs.

Où Bromure trace la ligne

Bromure Agentic Coding n'essaie pas de faire du modèle un meilleur devineur de l'endroit où finit un champ. Il fait deux choses que le modèle ne peut pas, puis s'assure que lorsque les deux se trompent, les dégâts atterrissent quelque part de jetable.

Premièrement, les délimiteurs falsifiés sont normalisés avant que le texte ne devienne un plan. La détection d'injection de prompt sur l'appareil de Bromure n'est pas seulement un modèle local qui lit l'intention ; elle est associée à un scanner déterministe — le même qui attrape les astuces d'Unicode invisible et d'homoglyphes. Les guillemets courbes se replient en guillemets droits, les caractères confusables et de largeur nulle sont retirés, et un champ dont les délimiteurs ne correspondent pas à la structure canonique est signalé. C'est l'instinct d'analyseur strict que les chercheurs ont trouvé efficace contre l'ADI, appliqué comme une couche sur le texte non fiable que l'agent a récupéré — la même classe d'entrée qu'un CLAUDE.md malveillant ou un commentaire empoisonné — et tout cela reste sur votre Mac.

Deuxièmement, les deux actions que l'ADI veut vraiment s'arrêtent encore à une frontière. Regardez ce que l'attaque cherche à déclencher : exécuter le correctif du mainteneur et fusionner la pull request. Toutes deux sont des actions qui débordent le bac à sable de l'agent — une commande shell, un push vers un dépôt distant. Chaque agent que Bromure fait tourner — Claude Code, Codex, Grok Build — s'exécute dans une VM Linux jetable, et les étapes qui sortent de cette boîte sont celles que Bromure présente pour confirmation. Une attribution falsifiée n'obtient pas d'exécuter une commande automatiquement, et un faux relevé de CI n'obtient pas de fusionner une branche automatiquement, parce que « le mainteneur l'a dit » est précisément le jugement que l'étape de confirmation existe pour recontrôler.

Troisièmement, si une commande s'exécute, elle s'exécute dans une boîte que vous jetez. Supposez qu'un délimiteur soit assez nouveau pour glisser devant le normalisateur et assez convaincant pour passer la revue. La commande s'exécute dans la VM. Réinitialisez le profil à sa base et tout ce qu'elle a déposé — un script, une clé SSH, une tâche planifiée — a disparu. Rien de ce qu'elle a fait ne survit à la fermeture de la fenêtre.

Quatrièmement, il n'y a pas de vrais identifiants à voler. Un « correctif » qui racle l'environnement et le disque à la recherche de jetons trouve les leurres de Bromure — clés AWS synthétiques, un ~/.kube/config jetable, des jetons git et de registre factices (brm_…). Les vrais secrets ne sont substitués que sur l'hôte, dans le proxy, sur le chemin de sortie vers la vraie API. Tout ce que la commande expédie hors de la boîte est un sac de chaînes qui n'authentifie rien, et la connexion qui l'expédie apparaît dans le Journal de sécurité comme un trafic sortant que vous pouvez voir.

Ce que cela délimite

La normalisation et la confirmation sont du confinement, pas un remède pour un modèle qui lit la structure par conjecture. Il vaut la peine d'être précis sur ce que Bromure change et ce qu'il ne change pas.

Le point des chercheurs n'est pas que six modèles partagent un bug. C'est que la façon dont un agent distingue un champ de confiance d'un contenu non fiable — la ponctuation qu'il lit par conjecture — est la même partout où un agent rencontre le monde extérieur, et elle ne sera pas corrigée ce trimestre. Aujourd'hui, le délimiteur falsifié vit dans un commentaire GitHub. Demain, c'est un champ Jira, un trailer de commit, un en-tête sur une page récupérée. Votre agent va lire une frontière tracée par un attaquant, et jusqu'à la moitié du temps il la croira. La question n'est pas de savoir si la ponctuation le trompe un jour. La question est de savoir ce qui s'exécute quand elle le fait : votre machine, vos vrais jetons, et une commande qui s'est poussée elle-même sur main — ou une boîte Linux jetable qui a d'abord normalisé le guillemet, retenu la fusion pour un regard, et n'avait que des leurres à l'intérieur. Bromure en fait la seconde.