LLMjacking : quand une clé volée se transforme en facture d'IA à six chiffres

Le « LLMjacking » désigne le détournement de l'accès d'une entreprise à des modèles d'IA : quelqu'un récupère vos identifiants cloud ou vos clés d'API, puis consomme ou revend des appels au modèle à vos frais. Le Google Threat Intelligence Group (GTIG) et Mandiant y consacrent un rapport daté du 2 novembre 2026, tiré d'interventions menées en 2026 chez plusieurs fournisseurs de cloud et de modèles.

Pourquoi c'est différent du minage de cryptomonnaie

Le rapport fait la comparaison : le minage clandestin grignote des ressources petit à petit, alors que le LLMjacking fait exploser la facture en quelques heures. Les chiffres avancés par GTIG et Mandiant, issus de leurs propres dossiers :

• plus de 100 000 dollars de frais frauduleux en une seule journée dans certains incidents ;
• jusqu'à 1 million de dollars cumulés dans certaines organisations avant la coupure des accès ;
• plus de 500 000 appels d'API passés par un seul acteur en moins de huit heures.

Par où ils entrent

D'après le rapport, la porte d'entrée dominante n'a rien d'exotique : des identifiants cloud exposés ou volés. Clés de comptes de service, identifiants IAM, jetons d'accès personnels GitHub, jetons de session actifs. Un des groupes observés se contentait de ramasser des clés d'API oubliées dans des dépôts GitHub publics. D'autres ciblent des points d'accès laissés ouverts sur Internet, des serveurs Ollama par exemple.

Un détail compte pour les petites structures : dans plusieurs incidents, la victime n'utilisait pas de service d'IA au moment de la compromission. Ce sont les attaquants qui l'ont activé avec les accès volés. Ne pas faire d'IA dans le cloud ne protège donc pas.

Les accès sont ensuite regroupés par des passerelles de revente, que GTIG appelle « LLM Mixers ».

Ce qu'une petite équipe peut vérifier

Le rapport liste plus de quinze mesures. Celles qui nous semblent accessibles sans équipe sécurité dédiée :

• Plafonds et alertes de dépense. Des quotas par modèle et des plafonds de facturation. C'est la mesure qui limite la casse quand tout le reste a échoué.
• Aucune clé dans le code. Analyse automatique des secrets dans les dépôts, rotation automatisée, gestionnaire de secrets centralisé.
• Moindre privilège. Un compte de service qui n'a pas besoin d'IA ne doit pas pouvoir activer un service d'IA.
• Clés cloisonnées. Une clé par environnement et par modèle, avec ses limites d'usage, pour qu'une clé de test ne donne pas accès aux modèles les plus chers.
• Authentification multifacteur résistante à l'hameçonnage sur les consoles cloud et les plateformes de développement.
• Alerte sur l'activation d'un service d'IA. GTIG recommande de traiter toute activation non autorisée comme un événement critique.
• Passerelles à jour. Les proxys de modèles comme LiteLLM entrent dans la gestion des correctifs ; le rapport cite la faille CVE-2026-40217, exploitée pour obtenir des droits d'administration.

Un indice de détection simple à retenir : des requêtes minuscules, limitées à un seul jeton de sortie, servent souvent à tester la validité d'une clé volée.

Les limites du rapport

Les montants proviennent d'incidents traités par Mandiant, pas d'une étude statistique : ils donnent un ordre de grandeur, pas une fréquence. Les règles de détection fournies visent d'abord les clients de Google Security Operations, même si les journaux à surveiller sont détaillés pour AWS, Azure et Google Cloud. Sur Google Cloud, le rapport précise que la journalisation des appels d'inférence est désactivée par défaut.

Notre lecture

Pour une PME, le risque est d'abord financier, et il se traite avec des réglages qui existent déjà dans les consoles cloud. Trois vérifications à faire cette semaine : un plafond de dépense existe-t-il sur chaque compte, une clé traîne-t-elle dans un dépôt, et qui a le droit d'activer un nouveau service. Si la réponse à la troisième question est « tout le monde », commencez par là.