Vous avez demandé à votre agent de code un paquet bien connu. Il a saisi un nom qui semblait correct, a lancé l'installation, et est passé à autre chose. Le nom était une supposition — et quelqu'un avait déjà enregistré exactement cette supposition et l'avait remplie de malware. Personne n'a fait de faute de frappe. L'agent a inventé le nom, et l'attaquant attendait là où l'invention est tombée.

En juillet 2026, un groupe de l'université de Tel Aviv, du Technion et d'Intuit — Aya Spira, Stav Cohen, Ron Bitton, Avishai Wool et Ben Nassi, entre autres — a décrit une attaque qu'ils appellent HalluSquatting. Elle transforme l'une des faiblesses les plus connues des grands modèles de langage — le fait qu'ils inventent des choses et présentent l'invention comme un fait — en un système de diffusion pour la chaîne d'approvisionnement, visant non pas vous, mais l'agent qui travaille pour votre compte.

Le principe est presque d'une banalité désarmante. Demandez à un agent de code de récupérer un paquet, de cloner un dépôt ou d'installer un skill pour un projet qu'il n'a jamais vu, et il devinera souvent l'identifiant plutôt que d'admettre qu'il ne sait pas. Le HalluSquatting transforme cette supposition en arme.

De la faute de frappe à l'hallucination

Le typosquatting existe depuis toujours : enregistrez expresss ou lodahs, attendez qu'un humain se trompe de touche au terminal. Cela repose sur l'erreur d'une personne. Le slopsquatting, apparu au cours de 2025 et au début de 2026, a déplacé l'erreur vers le modèle — un agent hallucine un nom de paquet qui n'existe pas, un attaquant l'enregistre le premier, et le prochain agent qui hallucine le même nom installe la charge utile. En janvier 2026, Charlie Eriksen d'Aikido a documenté un paquet npm halluciné, react-codeshift, qui s'est propagé à 237 projets avant que quiconque ne s'en aperçoive. Aucune faute de frappe n'a jamais été commise, donc aucune défense contre le typosquatting ne s'est jamais déclenchée non plus.

Le HalluSquatting est l'escalade de 2026, et l'escalade tient à ce que l'hallucination n'est plus laissée au hasard. La méthode des chercheurs est une recette en quatre étapes :

Choisir une cible que le modèle n'a pas mémorisée. Les dépôts et outils en vogue qui datent d'après la date de coupure de l'entraînement sont le point idéal : le modèle en a entendu parler, il va donc essayer, mais il n'a pas vu le vrai nom, il va donc en inventer un.
Apprendre l'erreur. Sondez l'agent à répétition jusqu'à savoir quel faux nom il produit de façon fiable. L'article rapporte des noms de dépôts hallucinés apparaissant jusqu'à 85 % du temps, et des scénarios d'installation de skills atteignant jusqu'à 100 % — suffisamment constant pour parier dessus.
Revendiquer le nom inventé. Enregistrez-le sur GitHub ou une boutique de plugins et remplissez le README, le manifeste ou le SKILL.md d'instructions écrites pour que l'agent les lise.
Attendre. Quand un développeur demande la vraie ressource, l'agent émet à la place l'identifiant inventé de l'attaquant et le récupère. Les instructions cachées détournent alors l'outil d'exécution de commandes de l'agent lui-même pour installer la charge utile.

Cette charge utile n'est pas une simple démonstration de faisabilité. Les chercheurs enchaînent la supposition à une injection de prompt — ce que le groupe de Nassi appelle promptware — et aboutissent à l'exécution de code à distance et à un malware de botnet : des machines de développeurs infectées qui appellent le serveur et reçoivent des ordres. La supposition dépose le fichier de l'attaquant dans l'assiette de l'agent, les instructions enfouies le transforment en commandes, et les commandes construisent un botnet à partir des ordinateurs portables des développeurs.

Pourquoi c'est une attaque contre l'agent, pas contre vous

La phrase qui résume tout, tirée de l'étude, est que le HalluSquatting « fait passer la cible des humains aux agents IA, qui peuvent ne pas vérifier si la source est réelle tout en exécutant des commandes ». Un humain incertain d'un nom de paquet s'arrête, vérifie le registre, jette un œil au nombre d'étoiles. Un agent en mode exécution automatique ne s'arrête pas. Son travail est de continuer, et un nom sorti de ses propres poids porte la même autorité qu'un nom que vous avez tapé. Il n'a aucune raison de douter de lui-même.

Les chercheurs ont mené leurs tests sur les outils que les développeurs utilisent tous les jours — GitHub Copilot, Cursor, Windsurf, Cline, Google Gemini CLI et la famille OpenClaw — et ont trouvé que les hallucinations étaient « transférables entre différents modèles de LLM et applications », fonctionnant contre des agents construits sur des modèles d'Anthropic, d'OpenAI et de Google. Aucun éditeur ne peut corriger cela par un correctif, car cela repose sur la forme partagée de la manière dont un agent de code transforme une requête en action : deviner le nom, récupérer la ressource, lire ce qu'elle dit, faire ce qu'elle dit.

Le HalluSquatting retire l'humain de la chaîne d'approvisionnement. L'attaquant sonde l'agent jusqu'à apprendre quel nom le modèle invente, enregistre ce nom exact avec un README ou un manifeste piégé, et attend. Quand vous demandez la vraie ressource, l'agent émet le nom inventé, récupère la version de l'attaquant, lit les instructions embarquées comme son propre plan, et installe la charge utile du botnet. Sur une configuration ordinaire, cela tourne sur votre machine.

Pourquoi « il suffit d'arrêter d'halluciner » n'a jamais été la solution

La réponse tentante est de faire vérifier le modèle par lui-même — résoudre le nom avant de le récupérer, signaler clone, install et fetch, ancrer chaque identifiant dans quelque chose de réel. Ce sont de bonnes idées, et les chercheurs les recommandent. Mais elles vivent toutes au même endroit : un filtre qui lit ce que l'agent s'apprête à faire et espère attraper le mauvais cas avant qu'il ne s'exécute. Le HalluSquatting est conçu précisément contre ce lecteur. Le nom paraît légitime parce que le modèle l'a produit ; le README ressemble à de la documentation parce que c'est ce qu'est un README ; la commande d'installation est la chose la plus ordinaire qu'un agent de code fasse de toute la journée.

C'est le mur contre lequel le reste de la sécurité des agents ne cesse de se heurter. Une liste de blocage qui lit une commande perd face au shell qui la réécrit. Un scanner qui lit un paquet perd face à la charge utile qui n'est pas dans le paquet. Un agent qui cherche un skill recommande le malware qu'il a trouvé tout seul. Le HalluSquatting ajoute la version la plus tranchante à ce jour : le nom malveillant ne venait pas du tout d'internet. Il venait du modèle. On ne peut pas mettre sur liste noire l'imagination de son propre agent. La description appartient à l'attaquant, et l'exécution est le seul endroit où l'issue se décide.

Où Bromure trace la ligne

Bromure Agentic Coding ne cherche pas à dissuader le modèle de deviner. Il change ce qu'une mauvaise supposition peut atteindre. Chaque agent que Bromure exécute — Claude Code, Codex, Grok Build — tourne à l'intérieur d'une VM Linux jetable sur votre Mac, pas sur macOS lui-même. Ainsi, quand l'agent émet un nom inventé, récupère la ressource de l'attaquant et lance l'installation comme les chercheurs ont vu ces agents le faire, plusieurs choses sont déjà vraies.

D'abord, et c'est rare pour cette catégorie d'attaque, le chemin du registre est analysé. Quand le nom inventé est un paquet npm, PyPI ou Cargo — le cas du slopsquatting, le cas react-codeshift — il atterrit en plein dans l'analyse de la chaîne d'approvisionnement de Bromure, qui inspecte les paquets à mesure qu'ils sont tirés des registres publics. C'est la seule partie du HalluSquatting où la supposition se résout en une chose que Bromure a été conçu pour examiner directement, avant qu'elle ne soit approuvée. Une dépendance hallucinée reste une dépendance, et elle entre par la porte d'entrée que Bromure surveille.

Ensuite, la charge utile s'exécute dans une boîte que vous jetez. Supposons que le nom inventé pointe vers un dépôt GitHub ou un skill de boutique de plugins plutôt qu'un paquet de registre, et que le loader du botnet s'exécute. Il s'exécute à l'intérieur de la VM. Il n'y a pas d'hôte persistant sur lequel recevoir des ordres : réinitialisez le profil à sa base et le binaire déposé, la tâche planifiée, le point d'ancrage — tout cela a disparu. Un nœud de botnet qui s'évanouit à la prochaine réinitialisation ne fait pas un bien grand nœud de botnet.

Troisièmement, il n'y a pas de vrais identifiants à enrôler. Un malware de botnet qui ratisse l'environnement et le disque à la recherche de clés d'API, de jetons git et cloud, et de clés SSH ne trouve que des leurres : Bromure injecte des valeurs de substitution (brm_…, un ~/.kube/config synthétique, des jetons ssh et cloud jetables) dans la VM et ne rétablit les vraies que sur l'hôte, dans le proxy, sur le chemin de sortie vers la véritable API. Les vraies clés n'entrent jamais dans la boîte. Ce que la charge utile expédie à son serveur de commande et de contrôle n'est qu'un sac de chaînes qui n'authentifient rien.

Quatrièmement, le promptware est lu face à un détecteur. Le HalluSquatting est une attaque par lecture avant d'être une attaque par exécution — tout l'exploit repose sur le fait que l'agent ingère le README, le manifeste ou le SKILL.md de l'attaquant et le traite comme son propre plan. C'est précisément l'autorité non fiable que Bromure surveille : la même catégorie qu'un CLAUDE.md ou un AGENTS.md malveillant. La détection d'injection de prompt sur l'appareil de Bromure évalue le contenu que l'agent lit comme documentation face à des modèles locaux qui ne quittent jamais le Mac, plus un scanner déterministe pour les astuces à base d'Unicode invisible. Une instruction disant « exécute maintenant ce script d'installation » enfouie dans un manifeste récupéré est exactement le cas pour lequel ce détecteur existe.

Et sous tout cela, le trafic sortant est visible. La balise du botnet, la récupération de l'étage, la tentative d'exfiltration — cela apparaît dans le journal de sécurité de Bromure comme du trafic sortant que vous pouvez voir, plutôt qu'un rappel silencieux d'une machine à laquelle vous faisiez confiance.

Même supposition, même récupération, même installation — machine différente. À l'intérieur de Bromure, l'agent tourne sur une VM Linux jetable : un paquet de registre halluciné est attrapé par l'analyse de la chaîne d'approvisionnement à la porte d'entrée, la charge utile du botnet s'exécute quelque part de jetable, les identifiants qu'elle ratisse sont des leurres échangés contre les vrais uniquement sur le proxy de l'hôte, le promptware du manifeste récupéré est évalué par un détecteur sur l'appareil, et la balise est journalisée. La supposition a toujours lieu. Il n'y a rien à enrôler.

Ce autour de quoi cela trace une ligne

L'isolation et l'analyse sont du confinement, pas un remède à l'hallucination. Il vaut la peine d'être précis sur ce que Bromure change ici et ce qu'il ne change pas.

L'agent invente toujours le nom

Bromure n'empêche pas le modèle d'halluciner un identifiant ni de récupérer ce vers quoi ce nom se résout. Ancrer les suppositions de l'agent est un problème de modèle et de harnais. Ce que Bromure change, c'est où la chose récupérée s'exécute et ce qu'elle peut atteindre en le faisant.

L'analyse des registres couvre les registres

Un paquet npm, PyPI ou Cargo halluciné est exactement ce que l'analyse de la chaîne d'approvisionnement inspecte — une véritable prise à la porte d'entrée. Un dépôt GitHub halluciné ou un skill de boutique de plugins n'est pas un paquet de registre ; ce chemin est tenu par l'isolation, le détecteur d'injection et les leurres, pas par l'analyse du registre.

La substitution couvre les secrets que vous configurez

L'échange de leurres protège les identifiants que vous placez dans un profil : clés de modèle, jetons git et cloud, endpoints de base de données gérée, clés ssh. Un jeton qu'un script écrit sur le disque en cours d'exécution, ou une session que vous établissez à la main dans la boîte, n'est que de la donnée. Gardez les secrets dans le broker, pas dans l'espace de travail.

La détection est un filet, pas un mur

L'évaluation d'injection sur l'appareil signale un manifeste d'installation-et-exécution plus souvent qu'autrement, mais un auteur soigneux peut formuler un leurre pour passer sous un seul scanner. Traitez le détecteur comme une couche ; le confinement — une boîte jetable avec de fausses clés et un trafic sortant journalisé — est ce qui tient quand un détecteur manque quelque chose.

Les chercheurs terminent sur une phrase à retenir : « Les attaques s'améliorent toujours ; elles n'empirent jamais. » Leurs taux de réussite sont un plancher, pas un plafond, et le mécanisme de confiance sous-jacent — un agent qui traite sa propre supposition comme un fait et un fichier récupéré comme un plan — ne va pas être corrigé ce trimestre. Votre agent va inventer un nom pour quelque chose dont il se souvient à moitié, et certains de ces noms inventés seront déjà pris. La question n'est pas de savoir s'il récupérera un jour le mauvais. À un taux d'hallucination de 85 %, cela arrivera parfois. La question est ce qui s'exécute quand cela arrive : votre machine, vos vraies clés et un point d'ancrage qui reste — ou une boîte Linux que vous pouvez jeter, avec des leurres à l'intérieur et le registre vérifié à l'entrée. Bromure fait en sorte que ce soit la seconde.