En bref : le risque des LLM sur appareil lié à l'inférence omnivore et aux endpoints locaux joignables depuis le navigateur
- Le mythe de la confidentialité : Le marketing produit présente l'inférence sur appareil comme une victoire pour la confidentialité, puisque le prompt n'atteint jamais le cloud. En réalité, il s'agit d'un modèle omnivore avec un accès au système de fichiers, au presse-papiers, au navigateur et à des outils, à une seule prompt injection de devenir un opérateur à l'intérieur de votre appareil.
- L'exposition : Chrome a téléchargé silencieusement un modèle Gemini Nano d'environ 4 Go sur des appareils sans invite de consentement claire en mai 2026, la prompt injection occupe la position LLM01 du OWASP Top 10 pour les applications LLM, et la sécurité côté client de cside surveille quels scripts tiers et extensions peuvent atteindre un endpoint de modèle local depuis le navigateur.
- Fixez les limites : Si votre déploiement d'IA locale ne dispose pas de permissions explicites, d'une télémétrie minimale, d'un isolement réseau de l'endpoint du modèle et d'une visibilité sur les scripts du navigateur, vous livrez un processus local privilégié doté d'une porte d'entrée publique. Fixez les limites avant que le modèle ne devienne une infrastructure d'arrière-plan.
Peu de temps ? Découvrez le blocage de Magecart et de skimmers dans le navigateur par cside. Elle couvre tout ce qui suit en un seul déploiement.
L'inférence d'IA sur appareil s'intègre aux systèmes d'exploitation, aux navigateurs et aux outils de productivité. Ce changement modifie le modèle de sécurité. Les données sensibles peuvent rester plus près de l'utilisateur, mais le modèle se rapproche aussi des fichiers, de l'état du navigateur, du contenu du presse-papiers et des outils système locaux.
Deux événements de mai 2026 montrent pourquoi ce sujet est désormais urgent. Le chercheur en sécurité Alexander Hanff a rapporté que Google Chrome téléchargeait un modèle Gemini Nano d'environ 4 Go vers les appareils sans invite de consentement claire. À la même période, les intégrations navigateur de Claude Desktop ont attiré l'attention, car les ponts locaux du navigateur peuvent élargir ce qu'un assistant IA est en mesure d'atteindre.
L'inférence sur appareil en elle-même n'est pas le problème. Les modèles locaux puissants exigent la même discipline de sécurité que tout processus local privilégié : permissions explicites, limites strictes sur les entrées, télémétrie auditable et visibilité au niveau du navigateur.
Ce que change l'inférence omnivore
« Inférence omnivore » est une expression utile pour décrire ce problème. Les modèles locaux gagnent en valeur parce qu'ils peuvent consommer davantage de contexte : fichiers, données du presse-papiers, historique de navigation, contenu visible des pages, processus en cours d'exécution et état de l'appareil.
Ce contexte rend l'assistant utile. Il en fait aussi une cible de grande valeur.
Lorsqu'un modèle local fonctionne avec des permissions étendues, un attaquant n'a plus besoin de voler directement la source de données. Il peut tenter d'orienter le modèle pour qu'il lise, résume, transforme ou envoie ces données à sa place.
Le navigateur est le point d'entrée évident
Le navigateur est l'endroit où de nombreuses entrées non fiables rencontrent des outils locaux privilégiés. Une page malveillante, une extension de navigateur compromise ou un script tiers chargé via une attaque de la chaîne d'approvisionnement peuvent tous devenir une entrée du modèle.
Si un LLM local expose un endpoint local ou un pont navigateur sans autorisation forte, tout JavaScript côté client devient un risque. Un script pourrait tenter d'interroger le modèle, lui demander de résumer un contexte local sensible, ou le pousser vers un appel d'outil que l'utilisateur n'a jamais voulu.
C'est pourquoi la sécurité côté client fait partie intégrante de la sécurité de l'IA locale. Les équipes de sécurité doivent savoir quels scripts s'exécutent dans le navigateur, ce qu'ils chargent, et s'ils tentent un comportement en dehors de leur rôle attendu.
Pourquoi la prompt injection a un rayon d'impact plus large en local
La prompt injection est le risque classé au premier rang de l'OWASP Top 10 pour les applications LLM. Dans un chatbot cloud, une injection réussie peut manipuler la sortie, divulguer un contexte accessible ou contourner des contrôles de politique.
Sur un modèle local, l'impact peut être plus large. Si le modèle a accès au système de fichiers, au navigateur, à l'exécution de commandes ou à des outils réseau, l'attaque passe de « que peut dire le modèle ? » à « que peut faire le modèle ? ».
L'accès aux outils transforme le modèle en opérateur
L'accès aux outils est la ligne qui compte vraiment. Lire un fichier, envoyer une requête HTTP, cliquer dans un navigateur ou exécuter une commande transforme le modèle d'un générateur de texte en un opérateur.
Une instruction injectée n'a pas besoin d'exploiter directement le système d'exploitation. Elle doit seulement atteindre une interface de modèle de confiance qui dispose déjà de la permission d'agir.
Les propres documents Mythos Preview d'Anthropic montrent à la fois la promesse défensive et le risque. Project Glasswing est construit autour de l'utilisation d'un raisonnement de classe Mythos pour trouver et corriger des vulnérabilités graves. Dans le même temps, Anthropic a noté qu'une capacité renforcée de correction de vulnérabilités implique aussi une capacité d'exploitation renforcée. Des articles sur les tests de Mythos ont décrit un chaînage autonome d'exploits en conditions contrôlées, y compris des travaux d'évasion de navigateur et de bac à sable.
Tous les modèles locaux ne se transforment pas en plateforme d'exploitation, mais les limites de permissions comptent davantage à mesure que les capacités augmentent.
Comment la télémétrie des LLM locaux peut tout de même divulguer des données sensibles
L'inférence sur appareil est souvent présentée comme un gain de confidentialité. Le prompt, le fichier ou le document brut n'a pas besoin de circuler vers un endpoint de modèle cloud. Pour les équipes de la santé, du droit, de la finance et de l'ingénierie d'entreprise, c'est un bénéfice réel.
Mais local ne signifie pas silencieux.
La télémétrie, les journaux de diagnostic, les métriques de performance du modèle, les vérifications de mise à jour, les rapports de plantage et les métadonnées d'intégration peuvent tout de même quitter l'appareil. Ces flux sont souvent traités comme des données opérationnelles, et non comme des données sensibles.
L'ombre portée de l'inférence locale
Un modèle qui lit des documents privés ou des dépôts de code peut produire des traces sensibles même lorsque les prompts bruts restent locaux. Les messages d'erreur peuvent contenir des extraits. Les schémas d'utilisation peuvent révéler une activité. Les charges utiles de diagnostic peuvent inclure des noms de fichiers, l'état des extensions, des catégories de prompts ou des données de routage du modèle.
Les outils d'inférence locale ont déjà fait l'objet d'un examen concernant la télémétrie d'usage et les paramètres de confidentialité par défaut. Pour les équipes soumises à réglementation, la télémétrie nécessite une classification, des contrôles de conservation et un chemin d'audit. Elle ne peut pas être traitée comme un simple bruit de fond inoffensif.
L'avantage pour la confidentialité reste réel
L'inférence sur appareil résout un problème authentique. Les données sensibles n'ont pas besoin d'être envoyées à une API d'inférence tierce pour chaque tâche. Cela réduit l'exposition aux politiques de conservation du cloud, aux compromissions côté fournisseur, au vol d'identifiants API et à l'interception du trafic du modèle.
Pour les produits de sécurité, cela crée une option de conception puissante. Un modèle local peut inspecter du code, des scripts, l'activité du navigateur et le comportement des endpoints sans envoyer chaque artefact à un fournisseur.
Le modèle de confidentialité est solide lorsque l'implémentation est disciplinée. Il s'effondre lorsque les téléchargements sont silencieux, que les intégrations s'installent sans intention claire de l'utilisateur, que la portée de la télémétrie est floue, ou que des endpoints locaux sont accessibles depuis du contenu navigateur non fiable.
Ce que peut faire la sécurité endpoint alimentée par LLM
L'inférence sur appareil ouvre aussi une voie défensive que les outils endpoint traditionnels peinent à égaler. Les systèmes à signatures détectent des motifs connus. Les heuristiques signalent des caractéristiques suspectes. Les deux approches peuvent manquer des attaques nouvelles, obfusquées ou en plusieurs étapes.
Un modèle local qui comprend le code peut raisonner sur l'intention. Il peut inspecter un script et se demander ce que ce script cherche à accomplir, pas seulement s'il correspond à un indicateur connu.
| Capacité | AV/EDR traditionnel | Sécurité endpoint alimentée par LLM |
|---|---|---|
| Détection de malwares inédits | Dépendante des signatures | Compréhension sémantique du code |
| Analyse de scripts obfusqués | Heuristiques limitées | Raisonnement au niveau de l'intention |
| Chaînes d'attaque multi-étapes | Analyse événement par événement | Analyse au niveau de la séquence |
| Découverte de zero-days | Majoritairement réactive | Raisonnement proactif sur le comportement |
| Gestion des faux positifs | Réglage de règles | Triage contextuel |
C'est la bonne version de la même architecture. Un modèle de sécurité local peut inspecter les extensions de navigateur avant leur exécution, analyser les scripts tiers pendant l'exécution, et signaler un comportement qui ressemble à de la collecte d'identifiants ou à de l'exfiltration de données.
Ce qui distingue un agent défensif d'un outil d'extraction, c'est la frontière de confiance établie autour des entrées, des outils et des sorties.
Les contrôles que les équipes de sécurité devraient exiger
L'inférence sur appareil a besoin d'un modèle de sécurité avant de devenir une infrastructure d'arrière-plan.
- Permissions explicites. Les modèles locaux ne doivent pas obtenir un accès par défaut aux fichiers, au presse-papiers, au contenu du navigateur ou à l'état des processus. Les permissions doivent être visibles, granulaires et révocables.
- Contrôles solides de l'interface du modèle. Traitez chaque entrée du modèle comme potentiellement adverse. Les défenses contre la prompt injection doivent se situer au niveau de l'interface et de la couche d'outils, pas seulement à l'intérieur du prompt du modèle.
- Limitation de la télémétrie. Maintenez une télémétrie minimale, documentée et auditable. Ne laissez pas les charges utiles de diagnostic transporter des données utilisateur, du contenu de fichiers ou un contexte local sensible.
- Isolement réseau. Les endpoints de modèle local ne doivent pas être accessibles depuis des requêtes navigateur arbitraires. L'endpoint local n'est pas une API publique.
- Visibilité des scripts navigateur. Surveillez les scripts tiers, les extensions et le contenu injecté susceptibles d'interagir avec les outils d'IA locale. Si vous ne pouvez pas faire confiance à l'environnement d'exécution du navigateur, vous ne pouvez pas y exposer en toute sécurité des modèles locaux privilégiés.
Comment cside s'intègre
cside surveille l'environnement d'exécution du navigateur : les scripts qui se chargent, le code qui s'exécute, les domaines qu'ils contactent et les comportements qui changent après le déploiement. C'est important, car le navigateur est l'un des endroits les plus probables où les outils d'IA locale rencontreront des entrées non fiables.
Pour les équipes qui déploient ou évaluent l'IA sur appareil, la sécurité côté client de cside aide à répondre à la question opérationnelle : que se passe-t-il réellement dans le navigateur avant d'atteindre un modèle local privilégié, un flux de paiement, un formulaire de connexion ou une session utilisateur sensible ?
L'inférence sur appareil améliorera les outils de sécurité. Elle créera aussi de nouveaux chemins d'attaque. Le résultat dépendra de la capacité des équipes à établir des limites de permissions et une visibilité à l'exécution avant que les modèles locaux ne deviennent une autre dépendance invisible.
