Agents d'IA locaux : privés, mais sont-ils sûrs ?

Faire tourner l'IA sur son propre ordinateur tient vos données à l'écart des fournisseurs de cloud, mais ne vous met pas à l'abri. Dès qu'un agent d'IA local peut lire vos fichiers, ouvrir votre messagerie et lancer des commandes, quiconque peut placer du texte sous ses yeux peut tenter de le diriger, et c'est un problème de sécurité que la confidentialité seule ne règle pas.

Cet article explique pourquoi particuliers et entreprises installent l'IA sur leurs propres machines, ce qui a mal tourné avec un agent local populaire, et comment profiter de la confidentialité sans ouvrir de porte dérobée.

Pourquoi faire tourner l'IA en local ?

Pour la confidentialité et le contrôle. Un modèle qui tourne sur votre appareil n'envoie pas vos prompts, documents ou code à un fournisseur. Des applications de bureau comme Jan, alternative gratuite et open source à ChatGPT, permettent de télécharger des modèles ouverts et de les exécuter localement.

Il y a aussi une raison professionnelle. Le Work Trend Index 2024 de Microsoft et LinkedIn a montré que 78 % des personnes qui utilisent l'IA au travail apportent leurs propres outils. Certaines organisations voient l'IA locale comme un moyen d'offrir l'IA aux équipes sans envoyer les données de l'entreprise à des services extérieurs.

L'IA locale est-elle sûre ?

Une application de discussion locale qui se contente de répondre a une petite surface d'attaque. Un agent local, c'est autre chose. Il agit : il lit des fichiers, navigue, envoie des messages et lance des commandes. Cela rend graves deux risques bien connus.

L'injection de prompt indirecte. Des chercheurs ont décrit en 2023 comment des instructions cachées dans un contenu lu par l'IA, comme une page web ou un document, peuvent prendre le contrôle de son comportement. L'OWASP classe l'injection de prompt en tête des risques des applications fondées sur de grands modèles de langage, et note que les injections indirectes arrivent par des sources externes comme des sites ou des fichiers.

L'autonomie excessive. Le risque LLM06 de l'OWASP nomme les causes profondes des dégâts lorsqu'un agent est induit en erreur : fonctionnalités excessives, permissions excessives et autonomie excessive. Un agent ayant un accès complet à un ordinateur portable cumule les trois.

Les coûts sont réels. Le Cost of a Data Breach Report 2026 d'IBM a établi que les incidents d'injection de prompt visant l'IA d'une organisation ont causé en moyenne 5,89 millions de dollars de pertes.

Que s'est-il passé avec Clawdbot et OpenClaw ?

Début 2026, un assistant d'IA open source, appelé successivement Clawdbot, Moltbot et OpenClaw, est devenu viral parce qu'il pouvait exécuter des tâches tout seul sur l'ordinateur de l'utilisateur. Des chercheurs en sécurité ont vite donné l'alerte. Tenable a décrit comment, parce que l'outil lit e-mails, messages et pages web, des attaquants pouvaient envoyer des messages le poussant à exécuter des commandes non autorisées, et comment les clés stockées par l'agent pouvaient être volées pour prendre le contrôle de comptes.

Le conseil de Tenable était clair : limiter les clés et jetons de l'agent pour n'accorder que l'accès strictement nécessaire et interdire les actions dangereuses ; et, comme l'agent peut être ajouté à des canaux de groupe où il lit des messages non fiables, n'y donner accès qu'à des personnes et canaux de confiance.

Analyse : la leçon n'est pas qu'un outil était mal conçu. Tout agent qui mêle entrées non fiables, données privées et pouvoir d'agir est exposé de la même façon, où qu'il tourne.

Confidentialité ou sécurité : faut-il choisir ?

Non, mais il faut concevoir pour les deux. Le traitement local protège les données du fournisseur. L'isolement et des permissions limitées protègent les données de l'agent. Le cloud n'est pas forcément pire : un service bien géré peut appliquer une surveillance et des correctifs qu'un ordinateur personnel n'a jamais. Le bon choix dépend des données, de la tâche et de qui entretiendra l'installation.

Comment utiliser des agents d'IA locaux en sécurité ?

1. Séparer la discussion de l'action. Utiliser un simple modèle local pour les questions privées ; n'activer les outils d'agent qu'en cas de besoin.
2. Accorder le moins d'accès possible. Donner à l'agent un dossier de travail, pas tout le disque, et aucun mot de passe ni clé enregistrés dont il n'a pas besoin.
3. L'isoler. Exécuter les agents dans un conteneur ou une machine virtuelle pour qu'un agent trompé ne puisse pas atteindre le reste du système.
4. Garder un humain dans la boucle. Exiger une validation avant qu'il lance des commandes, envoie des messages ou se connecte à Internet.
5. Limiter les entrées non fiables. Ne pas laisser un agent doté d'outils puissants lire des canaux publics ou des e-mails inconnus.
6. Mettre à jour et surveiller. Appliquer vite les correctifs de sécurité et journaliser ce que fait l'agent.
7. Fixer une politique d'entreprise. Si les équipes apportent leur propre IA, leur fournir des outils approuvés et des règles claires plutôt qu'une interdiction qu'elles contourneront.

Pour structurer les systèmes d'IA de sorte qu'une partie compromise ne puisse pas tout atteindre, voir Un grand modèle ou de nombreux agents ?.

Questions fréquentes

L'IA locale est-elle plus privée que l'IA dans le cloud ?

En général, pour les données elles-mêmes : un modèle qui tourne sur votre appareil n'envoie pas vos prompts ni vos fichiers à un fournisseur. Mais confidentialité n'est pas sécurité. Un agent qui accède à vos fichiers, à votre messagerie et à la ligne de commande peut encore être piégé pour les divulguer.

Qu'est-ce que l'injection de prompt indirecte ?

C'est une attaque où des instructions sont cachées dans un contenu que l'IA lit, comme une page web, un e-mail ou un fichier. L'OWASP classe l'injection de prompt comme le premier risque des applications fondées sur de grands modèles de langage.

Qu'est-il arrivé avec Clawdbot et OpenClaw ?

L'agent open source appelé successivement Clawdbot, Moltbot et OpenClaw a suscité des alertes de sécurité début 2026. Tenable a décrit des injections de prompt indirectes via e-mails, messageries et pages web, ainsi que des vols de clés d'API, et conseillé de n'ouvrir l'agent qu'à des personnes et canaux de confiance.

Comment faire tourner un agent d'IA local en sécurité ?

Lui donner le moins de droits possible, l'exécuter dans un conteneur ou une machine virtuelle isolés, exiger votre accord avant qu'il lance des commandes ou envoie des données, le tenir à l'écart des contenus non fiables si possible et le maintenir à jour.

Références

1. Jan, Open-source ChatGPT replacement — Exemple d'application de bureau gratuite et open source qui exécute des modèles d'IA localement.
2. Tenable (2026), Agentic AI Security: How to Mitigate Clawdbot, Moltbot, OpenClaw Vulnerabilities — Injection de prompt indirecte par e-mails, messages et pages web ; clés exposées ; conseil de n'ouvrir l'accès qu'aux personnes et canaux de confiance.
3. Greshake et al. (2023), Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection — L'article de recherche qui a décrit l'injection de prompt indirecte.
4. OWASP (2025), LLM01:2025 Prompt Injection — Définit l'injection de prompt directe et indirecte, y compris les instructions cachées dans des sites ou des fichiers.
5. OWASP (2025), LLM06:2025 Excessive Agency — Causes profondes : fonctionnalités, permissions et autonomie excessives.
6. IBM (2026), AI-powered adversaries and the enterprise risk challenge (Cost of a Data Breach Report 2026) — Les incidents d'injection de prompt ont entraîné en moyenne 5,89 millions de dollars de pertes.
7. Microsoft and LinkedIn (2024), AI at Work Is Here. Now Comes the Hard Part (Work Trend Index) — 78 % des utilisateurs d'IA apportent leurs propres outils d'IA au travail.