Le Google Threat Intelligence Group et Mandiant décrivent, dans un rapport publié le 2 novembre 2026, le « LLMJacking » : des criminels volent des clés d'API et des accès cloud pour consommer des modèles d'IA aux frais de l'entreprise victime. Dans certains incidents, les frais ont dépassé 100 000 dollars en un jour. Un risque de sécurité de l'IA pour toute entreprise qui paie une API de modèle.
Le terme désigne le détournement d'accès à de grands modèles de langage (LLM, large language models). Le rapport est signé par le Google Threat Intelligence Group (GTIG), la cellule de renseignement sur les menaces de Google, et par Mandiant, son service de réponse aux incidents. Le magazine suisse ICTjournal l'a relayé le 5 novembre 2026.
Ce que Google a réellement observé en 2026
Les constats viennent d'interventions de Mandiant chez des clients attaqués en 2026. Selon le rapport, les victimes se trouvent en Amérique du Nord, en Amérique du Sud et en Asie-Pacifique. Elles relèvent de la finance, du commerce de détail, de la technologie et des transports. Le rapport ne mentionne aucune victime en Europe.
Les montants sont des maxima constatés, pas des moyennes. Dans certains incidents, les frais frauduleux ont dépassé 100 000 dollars en une seule journée. Chez certaines organisations, le cumul a atteint 1 million de dollars avant la révocation des accès. Google ne publie ni le nombre d'incidents traités ni le montant moyen.
Deux cas sont détaillés. Le groupe que Google nomme UNC6993 a tenté de créer des clés d'API supplémentaires dans les projets cloud d'une victime. Il a ainsi accumulé plus de 100 000 dollars de frais. Un autre acteur a lancé plus de 500 000 appels d'API en moins de huit heures avec des clés volées. Il alimentait Jet Night, un service de revente d'accès aux modèles. La victime a supporté près d'un million de dollars de coûts de jetons (tokens).
Jet Night vendait un forfait « illimité » à environ 60 dollars par mois. Selon le GTIG, un service comparable coûte d'ordinaire entre 100 et 250 dollars par mois. Pour Google, ce prix montre que l'offre repose sur des clés volées.
Comment les attaquants obtiennent les accès
D'après le rapport, la principale porte d'entrée n'est pas la clé d'IA elle-même, mais l'identité cloud. Les chercheurs citent plusieurs voies observées :
- des identifiants cloud exposés ou volés : identifiants de gestion des accès (IAM), clés de comptes de service, jetons d'accès personnels GitHub, jetons de session ;
- des clés d'API de modèles publiées par erreur dans des dépôts GitHub publics ;
- des interfaces de modèles laissées ouvertes sur internet, comme des serveurs Ollama ;
- une faille de LiteLLM, une passerelle qui route les requêtes vers les modèles (CVE-2026-40217), exploitée pour obtenir des droits d'administrateur ;
- une fausse page de portail qui poussait des utilisateurs à coller leur jeton d'accès, ce qui contournait l'authentification à plusieurs facteurs.
La validation des clés volées se fait en silence. Un groupe envoyait des requêtes limitées à un seul jeton (max_tokens=1). Ce volume minime échappait aux alertes de volume anormal des outils de surveillance.
Une entreprise sans projet d'IA reste exposée. Dans plusieurs incidents, les services de modèles n'étaient pas activés au moment de l'intrusion, selon Mandiant. Les attaquants les ont activés eux-mêmes, par exemple Amazon Bedrock ou l'API Gemini. Une fois ces services activés, la facture peut grimper en quelques minutes ou quelques heures.
Les accès volés sont ensuite revendus. Le GTIG appelle « LLM Mixers » ces passerelles clandestines qui regroupent les identifiants dérobés. Elles répartissent les requêtes entre plusieurs comptes de victimes et facturent l'accès à leurs propres abonnés.
Ce qui relève de la projection
La suite du rapport est une prévision, pas un constat. Le GTIG s'attend à ce que les criminels privilégient le LLMJacking plutôt que le minage de cryptomonnaie sur des machines détournées (cryptojacking). La raison avancée : la revente via les LLM Mixers rapporte vite et beaucoup. Google estime aussi que les attaquants affineraient leur recherche automatique de jetons exposés et de failles dans les passerelles de modèles. Le rapport ne chiffre pas cette tendance.
Ce dossier touche la sécurité des comptes et de la facturation. Il diffère des questions de sécurité des modèles d'IA eux-mêmes, qui portent sur leur comportement.
Sécurité de l'IA en entreprise : les points à vérifier
L'Office fédéral de la cybersécurité (OFCS) rappelle sur sa page de protection de base que la cybersécurité est une mission de la direction. Il cite parmi les mesures clés le règlement des responsabilités dans le cloud et l'authentification à plusieurs facteurs. Les recommandations de Google pour le LLMJacking déclinent ces principes. Le tableau les reprend point par point.
| Point | Recommandation de Google | Question à se poser |
|---|---|---|
| Gestion des clés | Gestionnaire de secrets centralisé, rotation automatisée, recherche de secrets dans le code | Une clé d'API traîne-t-elle dans un dépôt, un fichier de configuration ou un script ? |
| Droits minimaux | Refuser toute permission non requise, y compris l'accès aux services de modèles | Qui peut activer un service d'IA dans nos projets cloud ? |
| Portée des clés | Clés limitées par modèle, par environnement (test ou production) et par volume | Une clé de test peut-elle appeler le modèle le plus cher ? |
| Plafonds de dépense | Quotas par modèle et plafonds de dépense | Un plafond bloque-t-il l'usage, ou se contente-t-il d'alerter ? |
| Alertes | Traiter toute activation non autorisée d'un service de modèle comme un événement critique | Une alerte part-elle à l'activation d'Amazon Bedrock ou de l'API Gemini ? |
| Authentification | Authentification à plusieurs facteurs résistante à l'hameçonnage | Les consoles cloud et les comptes de développeurs l'exigent-ils tous ? |
| Passerelles | Corriger vite les passerelles de modèles comme LiteLLM | Notre passerelle est-elle à jour contre la faille CVE-2026-40217 ? |
Un plafond de dépense n'arrête pas tout
La documentation Google Cloud sur les budgets avec plafond de dépenses en montre les limites. Un plafond ne couvre qu'un seul projet et un seul service à la fois. Les services éligibles sont l'API Gemini, Gemini Enterprise Agent Platform (anciennement Vertex AI), Cloud Run et Cloud Run Functions. Des alertes partent à 50, 80 et 100 % du montant.
Le blocage n'est pas instantané, prévient Google. Tout dépassement dû au délai de calcul reste facturé. Les coûts réels peuvent mettre plus de 24 heures à apparaître dans les rapports de facturation. Google conseille donc de fixer le plafond un peu sous la limite absolue. Un budget configuré en « alertes uniquement » ne suspend aucun service.
Les journaux doivent aussi être activés. Sur Google Cloud, les appels aux modèles figurent dans les journaux d'accès aux données, désactivés par défaut, précise le rapport. Sans eux, les appels frauduleux aux modèles n'apparaissent pas dans les journaux. Le rapport recommande enfin de surveiller les requêtes minuscules du type max_tokens=1, signe possible d'un test de clés volées.
Ce qu'on ne sait pas encore
- Le nombre total d'organisations touchées : Google ne le publie pas, ni pour le monde ni pour l'Europe.
- Les indicateurs de compromission complets : le GTIG les réserve aux utilisateurs inscrits de sa plateforme ; le rapport public ne cite que les domaines jet-night.com et newapi.pro.
Sources
- Google Threat Intelligence Group et Mandiant, « The Rise of LLMJacking », 2 novembre 2026
- ICTjournal, « Des cybercriminels détournent des accès LLM et font exploser les factures cloud », 5 novembre 2026
- Google Cloud, documentation « Gérer les budgets avec plafond de dépenses »
- Office fédéral de la cybersécurité, « Protection de base : protégez votre entreprise ou votre autorité »
