Le LLMjacking désigne le détournement de l'accès d'une entreprise à des grands modèles de langage (LLM) : un attaquant récupère une clé d'API et consomme à vos frais des ressources de calcul et des services d'IA coûteux. Google a mis en garde contre cette pratique début novembre 2026. La parade tient surtout à la gouvernance : savoir quelles clés existent, où elles vivent, ce qu'elles peuvent faire, et détecter vite leur usage anormal.
Ce qui s'est passé
Selon The Hacker News, Google a averti lundi que des acteurs malveillants détournent les accès d'entreprises à des LLM pour exploiter frauduleusement des ressources de calcul et des services d'IA coûteux.
L'article décrit le LLMjacking comme une forme de « resource hijacking » (détournement de ressources) adaptée à l'ère des LLM. L'attaquant obtient une clé d'API par l'une de quatre voies citées :
- l'hameçonnage (phishing) ;
- une fuite de code source ;
- un environnement mal configuré ;
- du code exposé côté client.
Le texte que nous avons pu lire est court. Il ne donne ni le nombre d'organisations touchées, ni les fournisseurs de modèles visés, ni de montants de pertes. Nous nous en tenons donc à ce qu'il dit, et la partie défensive ci-dessous repose sur des bonnes pratiques de gestion des secrets, présentées comme telles.
Comment ça fonctionne, dans le principe
Une clé d'API de fournisseur de modèle est un secret porteur (« bearer ») : quiconque la détient est traité comme vous par l'API. Il n'y a en général ni second facteur, ni lien avec un poste ou une adresse IP, sauf si vous l'avez configuré.
Le mécanisme est donc proche de celui, connu depuis longtemps, du détournement de comptes cloud pour miner de la cryptomonnaie : l'actif volé n'est pas une donnée, c'est une capacité de calcul facturée à la victime. La différence tient à la nature de la ressource. Un appel à un LLM est payé au volume de tokens, et certains modèles coûtent cher à l'unité. Une clé valide peut donc générer une facture importante sans que rien ne casse côté production.
Les quatre vecteurs cités par l'article correspondent à des situations que l'on retrouve dans beaucoup de jeunes équipes :
- Code côté client : une clé placée dans une application web ou mobile pour appeler le modèle directement depuis le navigateur ou le téléphone est lisible par n'importe quel utilisateur de l'application.
- Fuite de code source : clé commitée dans un dépôt, un notebook, un fichier
.envpartagé, un ticket ou un message. - Environnement mal configuré : variable d'environnement exposée par une page de debug, un bucket ouvert, un journal d'erreurs trop bavard.
- Hameçonnage : vol des identifiants d'un développeur ou d'un compte de la console du fournisseur, qui donne accès aux clés existantes ou permet d'en créer.
À noter : l'article ne détaille pas ce que les attaquants font des accès obtenus, au-delà de l'exploitation de ressources coûteuses. Nous n'en dirons pas plus.
Qui est concerné
Toute organisation qui consomme un LLM par API avec des clés à longue durée de vie. En pratique, c'est le cas de la plupart des startups et scale-ups qui ont intégré un assistant, un agent, un pipeline de RAG ou des outils de développement assistés par IA.
Notre lecture, qui est une hypothèse et non un constat de la source : le risque augmente avec le nombre de clés en circulation. Une équipe qui a laissé chaque développeur créer sa propre clé « pour tester », dans plusieurs fournisseurs, avec des quotas par défaut, a une surface bien plus large qu'une équipe qui passe par une passerelle unique.
Deux conséquences sont à garder en tête, au-delà de la facture :
- Disponibilité : si la clé détournée partage ses quotas avec votre production, l'usage frauduleux peut épuiser vos limites de débit et dégrader votre service.
- Données : selon le fournisseur et sa configuration, une clé peut donner accès à des ressources associées au compte (fichiers téléversés, assistants configurés, historiques). Vérifiez ce que vos clés permettent réellement, au cas par cas.
Comment s'en protéger : gouverner les clés d'IA
Les contrôles ci-dessous sont des bonnes pratiques générales de gestion des secrets, appliquées aux clés de fournisseurs d'IA. Ils ne sont pas tirés de l'alerte de Google.
1. Faire l'inventaire
On ne protège pas ce qu'on ne connaît pas. Listez, pour chaque fournisseur (OpenAI, Anthropic, Google, Mistral, Azure, AWS Bedrock, etc.) :
- les clés actives, leur propriétaire nommé et leur usage ;
- leur date de création et de dernière utilisation ;
- les projets ou espaces de travail auxquels elles sont rattachées.
Toute clé sans propriétaire ou inutilisée depuis plusieurs semaines est candidate à la révocation.
2. Ne jamais exposer une clé côté client
Les appels au modèle passent par votre backend, ou par une passerelle (« AI gateway ») que vous contrôlez. Le client s'authentifie auprès de vous, avec vos mécanismes habituels, et c'est votre serveur qui détient la clé du fournisseur. C'est la réponse directe au quatrième vecteur cité par l'article.
3. Stocker les clés dans un gestionnaire de secrets
Coffre-fort de secrets (Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault ou équivalent), injection à l'exécution, pas de clé en clair dans les dépôts, les images de conteneur ni les fichiers de configuration partagés. Activez un scanner de secrets sur les dépôts et en pré-commit, en vérifiant qu'il reconnaît les formats de clés de vos fournisseurs d'IA.
4. Réduire ce que chaque clé peut faire
Une clé par application et par environnement, jamais une clé partagée entre production et développement. Là où le fournisseur le permet : restriction aux modèles nécessaires, permissions limitées, rattachement à un projet isolé, restriction par adresse IP ou par réseau. Préférez, quand l'offre l'autorise, une authentification par identité de charge de travail (comptes de service, rôles cloud) à une clé statique.
5. Plafonner la dépense
Fixez des limites de budget et de débit par projet chez le fournisseur, avec alertes à des seuils intermédiaires. Un plafond ne bloque pas le vol, mais il borne la perte et transforme un incident silencieux en alerte.
6. Surveiller l'usage
Suivez la consommation par clé et par modèle. Les signaux à regarder : appels à des modèles que vous n'utilisez pas, pics hors des heures d'activité, volume sans rapport avec votre trafic applicatif, provenance géographique inhabituelle si le fournisseur l'expose. Une passerelle centrale simplifie beaucoup cette surveillance, puisque tous les appels y transitent avec votre propre journalisation.
7. Rotation et procédure de révocation
Prévoyez une rotation régulière et, surtout, une procédure écrite pour révoquer une clé en quelques minutes : qui le fait, où, comment redéployer la nouvelle clé sans couper la production. Si la révocation demande une demi-journée de coordination, elle ne sera pas faite à temps.
8. Protéger les comptes de console
Le vecteur hameçonnage vise souvent les comptes humains. Authentification forte résistante au phishing (clés FIDO2, passkeys) et connexion via votre fournisseur d'identité (SSO) sur les consoles des fournisseurs d'IA, avec un nombre limité d'administrateurs.
Comment vérifier chez vous, en une heure
- Ouvrez la console de chaque fournisseur d'IA et exportez la liste des clés. Comptez-les. Identifiez celles sans propriétaire.
- Cherchez dans vos dépôts, y compris l'historique Git, les préfixes de clés de vos fournisseurs.
- Ouvrez votre application web, onglet réseau du navigateur : un appel part-il directement vers l'API d'un fournisseur de modèle ? Si oui, la clé est exposée.
- Vérifiez qu'un plafond de dépense et une alerte existent sur chaque compte de facturation d'IA.
- Regardez la consommation des 30 derniers jours par clé et cherchez ce qui ne correspond à aucun usage connu.
FAQ
Qu'est-ce que le LLMjacking ?
C'est le détournement de l'accès d'une organisation à des grands modèles de langage, le plus souvent via une clé d'API volée, pour utiliser à ses frais des ressources de calcul et des services d'IA. The Hacker News le décrit comme une forme de détournement de ressources adaptée aux LLM.
Comment savoir si ma clé d'API OpenAI, Anthropic ou Google a été volée ?
Comparez la consommation par clé avec votre usage réel : modèles inattendus, pics nocturnes, volumes sans lien avec votre trafic. Vérifiez aussi si la clé apparaît dans un dépôt, un journal ou du code client. En cas de doute, révoquez et remplacez : c'est moins coûteux qu'une enquête.
Que faire si une clé d'API d'IA a fuité ?
Révoquez-la immédiatement chez le fournisseur, déployez une nouvelle clé depuis votre gestionnaire de secrets, puis cherchez l'origine de la fuite pour la corriger. Examinez la consommation depuis la date probable d'exposition et contactez le support du fournisseur au sujet de l'usage frauduleux. Supprimer la clé d'un commit ne suffit pas : l'historique et les copies existantes la conservent.
Un plafond de dépense suffit-il à se protéger ?
Non. Il limite la perte financière, mais ne protège ni la disponibilité de votre service si les quotas sont partagés, ni les éventuelles ressources accessibles avec la clé. C'est un filet, pas un contrôle d'accès.
Sources
- The Hacker News, « Google Warns LLMjacking Attacks Are… », novembre 2026 : https://thehackernews.com/2026/11/google-warns-llmjacking-attacks-are.html
- La communication d'origine de Google n'a pas pu être consultée pour cet article ; le lien sera ajouté une fois identifié.
Si vous voulez savoir combien de clés d'IA circulent réellement chez vous et lesquelles sont exposées, WeeSec réalise des audits de sécurité IA centrés sur ces questions d'accès et de secrets.