La surface d’attaque des assistants IA vient de s’élargir en quarante-huit heures avec trois compromissions parallèles : Microsoft 365 Copilot exfiltre emails, fichiers et codes MFA en un clic, LiteLLM laisse des comptes peu privilégiés prendre le contrôle complet d’une passerelle d’IA, et Open VSX héberge des extensions de code trojanisées qui pilotent leur C2 via Solana. Pour les PME-ETI, ces trois incidents convergent sur le même message : les assistants IA déployés en production sont désormais des cibles de premier rang, et la surface qu’ils exposent dépasse largement celle des SaaS traditionnels.
Pourquoi les assistants IA changent la donne défensive
Un assistant IA d’entreprise — Copilot, ChatGPT Enterprise, Claude Cowork, Gemini for Workspace — concentre trois propriétés que les attaquants n’avaient jamais combinées dans un même composant : un accès délégué aux emails, calendriers, fichiers et applications métier ; une capacité d’exécution via fonctions, plugins ou agents ; et une interface naturelle qui accepte des instructions arbitraires venant de tiers (emails reçus, documents partagés, sites web). Le résultat est une chaîne d’attaque où une simple injection de prompt dans un email peut se transformer en exfiltration de boîte mail, en chiffrement de OneDrive ou en pivot vers le SI.
Les trois affaires publiées en quarante-huit heures incarnent ce changement de paradigme, et chacune éclaire un angle différent de la nouvelle surface d’attaque des assistants IA.
Microsoft 365 Copilot SearchLeak : un clic, tout part
L’équipe de recherche publiée le 15 juin a démontré comment une seule interaction utilisateur dans Microsoft 365 Copilot suffit à voler des emails, des fichiers SharePoint et même des codes MFA stockés dans Authenticator. L’attaque combine une injection de prompt indirecte via un document partagé, un détournement de la fonction de recherche intégrée à Copilot, et l’exfiltration des résultats vers un domaine attaquant via un appel d’API légitime.
Le scénario est particulièrement dangereux en PME-ETI parce qu’il ne nécessite ni faille zero-day côté Microsoft, ni élévation de privilèges : un document partagé via Teams ou OneDrive, ouvert ou simplement indexé par Copilot, déclenche la chaîne. Les détections classiques (EDR, DLP) ne voient qu’un trafic Microsoft → Microsoft, et la victime ne perçoit qu’un assistant qui « répond plus lentement » pendant l’exfiltration.
Le rappel pour les défenseurs : un assistant IA est un utilisateur privilégié qu’il faut traiter avec les mêmes contrôles qu’un compte admin. Cela suppose journalisation exhaustive des prompts et des réponses, segmentation des sources de données indexées, et alertes sur tout appel sortant de Copilot vers un domaine non maîtrisé.
LiteLLM : la passerelle d’IA devient le maillon faible
Une chaîne de vulnérabilités publiée par The Hacker News le 15 juin permet à un utilisateur ne disposant que d’un rôle « viewer » de prendre le contrôle complet d’un serveur LiteLLM, la passerelle open source la plus utilisée pour multiplexer les appels vers OpenAI, Anthropic, Azure et les modèles auto-hébergés. L’attaquant peut alors lire toutes les clés API stockées, intercepter les conversations en cours, injecter des réponses et pivoter vers les modèles backend.
L’enjeu pour les PME-ETI est double. D’une part, LiteLLM est devenu le composant par défaut pour les équipes qui veulent unifier leurs coûts IA et appliquer des politiques de quotas. D’autre part, son périmètre d’accès est maximal : il détient les clés racine de tous les fournisseurs et voit passer l’intégralité du trafic d’inférence. Une compromission équivaut à une exfiltration permanente des prompts métier, qui contiennent souvent les données les plus sensibles de l’entreprise.
Le correctif est disponible, mais la leçon dépasse le patch : toute passerelle d’IA doit être traitée comme un HSM logique, isolée sur un VLAN dédié, monitorée en continu, et son interface d’administration ne doit jamais être exposée hors d’un VPN d’admin. La rotation des clés API après mise à jour est obligatoire — l’attaquant a peut-être déjà extrait les secrets pendant la fenêtre d’exposition.
Open VSX GlassWASM : le supply chain attaque les développeurs
Socket Security a documenté le 16 juin une famille d’extensions Open VSX trojanisées qui distribuent GlassWASM, un malware dont la logique métier est compilée en WebAssembly via TinyGo et qui récupère son canal C2 dans les mémos de transactions Solana. Open VSX étant le marketplace utilisé par défaut par les éditeurs alternatifs à VS Code (Cursor, Windsurf, Code-OSS, Eclipse Theia), la portée touche directement les équipes qui ont migré pour profiter d’assistants IA non-Microsoft.
Cette compromission illustre une nouvelle classe de supply chain : l’attaquant ne vise plus seulement npm ou PyPI, mais l’environnement de l’IDE qui héberge l’assistant IA. Une extension malveillante voit passer tout le code, tous les tokens GitHub, et toutes les conversations avec l’assistant IA local — y compris les secrets que le développeur colle dans un prompt sans réfléchir.
Pour les PME-ETI, la mitigation passe par une politique stricte : marketplace approuvé, allowlist d’extensions, vérification de la signature des éditeurs, et inspection du trafic sortant de l’IDE vers des domaines non listés (la C2 Solana est particulièrement furtive parce qu’elle ressemble à du trafic blockchain légitime).
Construire une posture défensive pour les assistants IA
Les trois incidents convergent vers une même architecture défensive, que tout dirigeant d’entreprise doit mettre en place sans attendre :
- Inventaire des assistants IA déployés — Copilot, ChatGPT Enterprise, Claude, agents internes, plugins de navigateur. Un assistant non inventorié est un assistant non gouverné.
- Politique d’accès aux données — limiter ce que chaque assistant peut indexer. Pas de partage par défaut, principe du moindre privilège appliqué aux sources.
- Journalisation des prompts — capter prompt et réponse, conservation 90 jours minimum, alertes sur les patterns suspects (mots-clés d’exfiltration, appels d’outils non standard).
- Passerelles d’IA isolées — LiteLLM, OpenRouter, Anthropic Gateway et équivalents doivent vivre dans un segment réseau dédié avec MFA admin obligatoire.
- Marketplace d’extensions verrouillé — allowlist par IDE, signature vérifiée, blocage d’Open VSX sauf usage justifié.
- Rotation systématique des secrets — toute clé API IA doit être rotable en moins d’une heure ; documenter la procédure et la tester chaque trimestre.
La surface d’attaque des assistants IA n’est plus une menace théorique. Les preuves de concept de la semaine montrent que les techniques sont matures, les exploits sont publics et les défenseurs ont quelques semaines avant que les opérateurs ransomware ne les intègrent à leurs playbooks. Pour aller plus loin sur la gouvernance des agents IA en entreprise, consultez notre framework Zero Trust pour agents IA et notre analyse de 832 comptes décryptés par Anthropic dans des cyberattaques pilotées par IA.