LLM-jacking : protéger les accès aux modèles d’IA en entreprise

Le 4 octobre 2026, Numerama revient sur le LLM-jacking. Cette pratique détourne l’accès à des modèles d’IA ou les ressources qui les font fonctionner. Des rapports de Google et de Sysdig documentent plusieurs formes d’abus. Pour une entreprise qui déploie l’IA, la protection des comptes et des serveurs devient aussi importante que le choix du modèle.

Ce que Google a observé

Le rapport du Google Threat Intelligence Group publié le 8 septembre 2026 décrit le vol d’identifiants et la vente de comptes d’IA compromis. Il signale aussi des intrusions qui permettent d’utiliser les ressources cloud d’une victime. Les observations proviennent notamment des interventions de Mandiant et du suivi de plateformes et de forums clandestins.

Un compte volé ouvre l’accès à un service payant

L’attaquant peut exploiter des identifiants de connexion ou une clé d’API. Cette clé permet à un logiciel d’appeler un service d’IA. Selon Google, certains voleurs d’identifiants ciblent désormais les fichiers de configuration des assistants de développement. L’abus peut donc partir d’un poste de travail et dépasser le simple compte utilisé dans un navigateur.

Des ressources cloud peuvent aussi être détournées

Google décrit également une intrusion au cours de laquelle un attaquant a déployé une infrastructure d’IA non autorisée dans l’environnement cloud de sa victime. Ce scénario engage la capacité de calcul de l’entreprise. La sécurité du modèle ne remplace pas celle des droits d’accès à cet environnement.

Un modèle hébergé en interne reste une cible

Dans un rapport publié le 17 juin 2026, Sysdig relate une observation du 12 juin. Un attaquant utilisait un serveur Ollama mal configuré pour alimenter un outil offensif automatisé. Le serveur répondait sur une interface publique sans authentification. L’affaire illustre un détournement de capacité déjà disponible chez la victime.

Ce cas concerne une exposition de configuration. Il ne démontre pas que tous les modèles hébergés en interne seraient vulnérables. Il montre surtout qu’un service d’IA accessible depuis Internet mérite les mêmes contrôles qu’un autre service sensible.

Des observations à interpréter dans leur périmètre

Les deux rapports décrivent des activités observées par leurs équipes de recherche en sécurité. Ils ne mesurent pas la probabilité de subir une attaque pour chaque entreprise française. Les dates des incidents précèdent la reprise du sujet dans la presse du 4 octobre. Le phénomène ne constitue donc pas une menace apparue ce jour-là.

Trois contrôles concrets pour les équipes

Limiter et surveiller les clés d’accès

Dans ses recommandations sur les clés Google et Gemini, Google conseille de limiter les services accessibles à ce qui est nécessaire. L’éditeur recommande aussi des restrictions sur les applications autorisées et un suivi de la consommation. Une clé dont l’usage change mérite une investigation. Une clé compromise doit être révoquée selon la procédure de l’organisation.

Protéger les serveurs de modèles

Sysdig recommande de restreindre l’exposition réseau des serveurs d’inférence. Les accès distants doivent passer par une protection réseau et une authentification adaptées. L’équipe préconise aussi de surveiller les volumes inhabituels de requêtes. Installer un modèle sur ses propres machines ne dispense pas de ces contrôles.

Distinguer une alerte de coût d’un plafond

La documentation Google Cloud sur les budgets précise qu’un budget limité aux alertes ne bloque pas automatiquement la consommation ni la facturation. L’équipe doit vérifier le mécanisme réellement configuré. Recevoir un courriel de dépassement ne signifie pas que le service s’arrête. Cette distinction compte lorsque des accès payants sont détournés.

Sources et prolongement

Sources principales : rapport Google du 8 septembre et observation Sysdig du 17 juin. Les mesures pratiques s’appuient sur les recommandations Google pour les clés API et la documentation des budgets Google Cloud. Le sujet a été repéré dans l’article de Numerama du 4 octobre. L’entretien du Financial Times cité par Numerama reste derrière un accès payant. Ses chiffres ne sont pas repris ici.

Pour approfondir le contrôle des usages, lisez notre article sur l’évaluation britannique de GPT-6 Astra et les limites à imposer aux agents.

David LACOUR accompagne les équipes dans l’apprentissage d’usages de l’IA qui associent autonomie et contrôle. Une formation peut aider à reconnaître les accès sensibles et à coordonner les pratiques avec les responsables informatiques. Échangez sur votre projet de formation.