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 presse-papiers et des outils système locaux.
Deux événements de mai 2026 montrent pourquoi ce sujet est urgent. Le chercheur en sécurité Alexander Hanff a rapporté que Google Chrome téléchargeait un modèle Gemini Nano d'environ 4GB sur des appareils sans demande de consentement claire. À la même période, les intégrations navigateur de Claude Desktop ont été critiquées parce que les ponts locaux du navigateur peuvent élargir ce qu'un assistant IA peut atteindre.
La conclusion n'est pas que l'inférence sur appareil est mauvaise. La conclusion est que 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é dans la couche navigateur.
Ce que change l'inférence omnivore
"Inférence omnivore" est une expression utile pour ce problème. Les modèles locaux deviennent précieux parce qu'ils peuvent consommer plus de contexte : fichiers, données du presse-papiers, historique du navigateur, contenu visible des pages, processus en cours et état de l'appareil.
Ce contexte rend l'assistant utile. Il en fait aussi une cible de grande valeur.
Quand un modèle local s'exécute avec des permissions larges, un attaquant n'a plus besoin de voler directement la source de données. Il peut tenter de pousser le modèle à lire, résumer, transformer ou envoyer 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 compromise ou un script tiers chargé par une attaque de chaîne d'approvisionnement peut 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 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 adoptent un comportement hors de leur rôle attendu.
Pourquoi la prompt injection a plus d'impact en local
La prompt injection est le risque numéro un 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 critique. Lire un fichier, envoyer une requête HTTP, cliquer dans un navigateur ou exécuter une commande transforme le modèle de générateur de texte en 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 a déjà le droit d'agir.
Les documents Mythos Preview d'Anthropic montrent à la fois la promesse défensive et le risque. Project Glasswing vise à utiliser un raisonnement de classe Mythos pour trouver et corriger des vulnérabilités graves. En même temps, Anthropic a noté qu'une meilleure capacité de correction des vulnérabilités implique aussi une meilleure capacité d'exploitation. 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 sandbox.
Cela ne signifie pas que chaque modèle local est une plateforme d'exploitation. Cela signifie que les limites de permissions comptent davantage à mesure que la capacité du modèle augmente.
Comment la télémétrie des LLM locaux peut encore exposer 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 d'aller vers un endpoint de modèle cloud. Pour les équipes santé, juridiques, financières et d'ingénierie d'entreprise, c'est un vrai bénéfice.
Mais local ne veut pas dire 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 crash et les métadonnées d'intégration peuvent encore quitter l'appareil. Ces flux sont souvent traités comme des données opérationnelles, pas comme des données sensibles.
L'ombre 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 diagnostics peuvent inclure des noms de fichiers, l'état d'extensions, des catégories de prompts ou des données de routage du modèle.
Les outils d'inférence locale ont déjà été examinés pour leur télémétrie d'usage et leurs paramètres de confidentialité. Pour les équipes réglementées, la télémétrie doit avoir une classification, des contrôles de conservation et un chemin d'audit. Elle ne peut pas être traitée comme un bruit inoffensif.
Le gain de confidentialité reste réel
L'inférence sur appareil résout un vrai problème. 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 cloud, aux compromissions côté fournisseur, au vol de clés 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 endpoint sans envoyer chaque artefact à un fournisseur.
Le modèle de confidentialité est solide lorsque l'implémentation est disciplinée. Il se rompt 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 la sécurité endpoint avec LLM peut faire
L'inférence sur appareil ouvre aussi une voie défensive que les outils endpoint traditionnels égalent difficilement. Les systèmes à signatures détectent des modèles connus. Les heuristiques signalent des caractéristiques suspectes. Les deux peuvent manquer des attaques nouvelles, obfusquées ou multi-étapes.
Un modèle local qui comprend le code peut raisonner sur l'intention. Il peut inspecter un script et demander ce que ce script cherche à accomplir, pas seulement s'il correspond à un indicateur connu.
| Capacité | AV/EDR traditionnel | Sécurité endpoint avec LLM |
|---|---|---|
| Détection de nouveaux malwares | Dépendante des signatures | Compréhension sémantique du code |
| Analyse de scripts obfusqués | Heuristiques limitées | Raisonnement sur l'intention |
| Chaînes d'attaque multi-étapes | Analyse par événement | Analyse au niveau de la séquence |
| Découverte de zero-days | Surtout 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 avant leur exécution, analyser les scripts tiers pendant le runtime et signaler un comportement compatible avec le vol d'identifiants ou l'exfiltration de données.
La différence entre un agent défensif et un outil d'extraction tient à la frontière de confiance autour des entrées, des outils et des sorties.
Les contrôles que les équipes de sécurité doivent 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 avoir 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 forts de l'interface du modèle. Traitez chaque entrée du modèle comme potentiellement adversariale. Les défenses contre la prompt injection appartiennent à l'interface et à la couche d'outils, pas seulement au prompt du modèle.
- Limites de télémétrie. Gardez une télémétrie minimale, documentée et auditable. Les diagnostics ne doivent pas transporter des données utilisateur, du contenu de fichiers ou un contexte local sensible.
- Isolation réseau. Les endpoints locaux du modèle ne doivent pas être accessibles depuis des requêtes arbitraires du navigateur. L'endpoint local n'est pas une API publique.
- Visibilité des scripts navigateur. Surveillez les scripts tiers, extensions et contenus injectés qui peuvent interagir avec les outils IA locaux. Si vous ne pouvez pas faire confiance au runtime du navigateur, vous ne pouvez pas exposer en sécurité des modèles locaux privilégiés.
Comment cside s'intègre
cside surveille le runtime du navigateur : les scripts chargés, le code exécuté, les domaines contactés et les comportements qui changent après déploiement. C'est important parce que 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, cside client-side security 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 checkout, 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 nouvelles voies d'attaque. Le résultat dépendra de la capacité des équipes à construire des limites de permissions et une visibilité runtime avant que les modèles locaux deviennent une autre dépendance invisible.
