Le local n'est pas plus sûr : l'injection indirecte frappe LLM locaux et cloud

De quoi s’agit-il ?

Le 8 juin 2026, l’équipe de recherche sécurité et vie privée de Brave (Ali Shahin Shamsabadi, Hamed Haddadi et Artem Chaikin) a publié Indirect Prompt Injection remains a fundamental security challenge for AI, révélant la même classe de faille dans deux produits situés aux extrémités opposées du spectre de déploiement : Mozilla Tabstack, une API cloud d’exécution web pour agents IA, et Cotypist, un assistant d’autocomplétion entièrement sur appareil pour macOS. Les deux ont été notifiés en divulgation responsable avant publication ; Tabstack a confirmé un correctif le 1ᵉʳ juin 2026, vérifié indépendamment par Brave.

L’information centrale est la comparaison, pas chaque bug pris isolément. L’injection de prompt indirecte — des instructions glissées dans un contenu que le modèle est légitimement invité à lire — est souvent perçue comme un problème de cloud et de Web ouvert que les modèles sur appareil éviteraient. Le constat de Brave est que le modèle local a lui aussi été détourné. La vulnérabilité ne dépend pas de l’endroit où s’exécute le modèle.

Comment ça marche

L’injection indirecte fonctionne parce qu’un système intégrant un LLM compose, dans une même fenêtre de contexte, des instructions de confiance (développeur/utilisateur) et des données externes non fiables, sans mécanisme robuste pour préserver la frontière entre les deux. L’attaquant ne touche jamais l’interface de prompt ; la charge arrive dans une page, un document ou un résultat d’outil que le système va ensuite ingérer.

Côté cloud, Brave a confié à l’endpoint d’automatisation de Tabstack une tâche banale — résumer cette page — sur une page qu’elle contrôlait. La page portait des instructions en texte invisible (blanc sur blanc / caractères de largeur nulle) : présentes dans la couche texte, invisibles pour un humain. L’agent n’a jamais résumé la page. Il a exécuté les étapes cachées dans l’ordre — navigation vers un formulaire contrôlé par l’attaquant, remplissage avec le prompt et tout l’historique de conversation, puis soumission, exfiltrant ces données. Sa propre trace de raisonnement montre qu’il a traité les instructions de la page comme une continuation légitime de la tâche ; il n’a jamais signalé de conflit ni demandé de confirmation. Aucune charge exploitable n’est reproduite ici — c’est le mécanisme qui compte.

Côté appareil, des instructions intégrées à un document local ont orienté l’autocomplétion de Cotypist vers des suggestions choisies par l’attaquant, au risque de faire apparaître les identifiants de l’utilisateur en ligne. Le rayon d’impact est plus réduit : une autocomplétion système ne peut pas mener d’actions autonomes, et son mode tab-pour-accepter conserve une frappe humaine entre une complétion injectée et sa réalisation. L’agent cloud façonne ce que le modèle fait ; l’assistant local façonne ce que le modèle dit. Conséquences différentes — défaillance structurelle identique.

C’est le même schéma que Brave avait démontré contre Perplexity Comet en août 2025, où un texte caché dans un commentaire Reddit pilotait l’agent à travers des sessions authentifiées pour exfiltrer une adresse e-mail et un code à usage unique. Un an plus tard, la leçon s’étend désormais au déploiement local.

Pourquoi c’est important

À retenir pour les praticiens : reformuler la question. La bonne question n’est pas « ce système utilise-t-il une API cloud ? » mais « ce système compose-t-il des instructions de confiance avec du contenu non fiable dans une fenêtre de contexte partagée ? » Si oui, il porte un risque d’injection indirecte — la forme du risque dépend de l’architecture, mais sa présence, non.

Cela compte parce que « nous exécutons le modèle en local » est de plus en plus présenté comme une garantie de sécurité et de confidentialité. Face à ce modèle de menace, ce n’en est pas une. Un modèle sur appareil, plus petit, est souvent moins capable de distinguer une instruction malveillante d’une instruction de confiance, pas plus. L’hébergement local change le point d’entrée de l’attaquant (un fichier local plutôt que le Web ouvert) et le rayon d’impact (ce que le modèle dit vs ce qu’il fait de façon autonome) — il ne ferme pas la brèche. À noter : l’endpoint d’automatisation de Tabstack expose un paramètre garde-fou en langage naturel, non activé par défaut : la configuration courante est donc la configuration vulnérable.

Défenses

Brave présente la mitigation comme une défense en profondeur doublée d’une conception sécurisée au niveau système. Les contrôles concrets, cohérents avec les recommandations de sa recherche sur Comet :

• Séparer instructions et données, et se méfier de la sortie du modèle. Transmettre le contenu des pages/documents comme explicitement non fiable, distinct de la requête de l’utilisateur — et traiter les actions proposées par le modèle comme potentiellement dangereuses, non comme des commandes autorisées.
• Vérifier l’alignement des actions sur l’utilisateur. Contrôler indépendamment que chaque action proposée correspond à la requête réelle de l’utilisateur avant exécution, plutôt que de supposer le plan bénin parce que le modèle l’a produit.
• Conditionner les actions sensibles à une interaction explicite. Navigation vers des domaines authentifiés, soumission de formulaire, envoi de données sortantes, envoi d’e-mail : exiger une confirmation humaine délibérée juste avant l’action, quel que soit le plan préalable.
• Isoler le mode agentique et appliquer le moindre privilège. Ne pas laisser une navigation ordinaire glisser vers un agent pleinement privilégié. Restreindre les outils, domaines et données accessibles à la tâche ; un assistant qui ne fait que résumer n’a pas besoin d’accès aux identifiants ou inter-sites.
• Ne pas s’appuyer sur l’hébergement local ou des garde-fous optionnels comme contrôle. Le déploiement sur appareil ne remplace pas ces frontières, et un garde-fou livré désactivé par défaut ne protège personne. Appliquer par défaut séparation structurelle, moindre privilège et contrôle des flux d’information.

Statut

Produit	Hébergement	Vecteur d’injection	Impact	Divulgation	Statut
Mozilla Tabstack	Cloud (/v1/automate)	Texte invisible sur une page web	Exfiltration de l’historique de conversation vers un formulaire pirate	2026-05-13	Corrigé le 2026-06-01 (vérifié)
Cotypist	Sur appareil (macOS)	Texte dans un document local	Autocomplétion manipulée ; risque de fuite d’identifiants	2026-06-01	Confirmé par l’éditeur le 2026-06-02

Les deux constats renforcent un point unique que les défenseurs doivent intégrer : l’injection de prompt indirecte est un problème de composition de contexte inhérent à l’architecture actuelle des LLM, et il ne peut pas être pleinement résolu en changeant l’endroit où s’exécute le modèle. Les correctifs ferment des instances ; ce sont les contrôles structurels ci-dessus qui réduisent la classe.