Le LLMjacking consiste à voler les clés API d’IA d’une entreprise pour consommer des modèles de langage à ses frais. Pour une PME, le risque principal n’est pas la fuite de données mais une facture IA qui explose en quelques heures, sans alerte, sur un compte que personne ne surveille.
Le sujet n’a rien de théorique : la plateforme d’hébergement Railway a révélé en novembre que des attaquants ayant volé des secrets clients avaient généré environ 740 000 dollars de consommation IA frauduleuse. Voici comment ces attaques fonctionnent, pourquoi les PME y sont exposées sans le savoir, et ce qu’il faut mettre en place.
Comment fonctionne le LLMjacking
Le terme a été popularisé en 2024 par les chercheurs de Sysdig, qui ont observé des attaquants utiliser des identifiants cloud volés pour activer des modèles d’IA hébergés et en revendre l’accès. Dans le scénario qu’ils décrivent, la victime pouvait supporter plus de 46 000 dollars de coûts de consommation par jour.
Le mécanisme est toujours le même :
- l’attaquant récupère une clé API (OpenAI, Anthropic, Google, Mistral) ou un identifiant cloud donnant accès à un service d’IA managé ;
- il vérifie silencieusement les quotas et les modèles disponibles ;
- il branche la clé sur un proxy qui revend l’accès à d’autres utilisateurs, ou l’utilise pour ses propres besoins (génération de contenu, entraînement d’un modèle concurrent par distillation) ;
- la facture arrive au propriétaire légitime, souvent plusieurs jours plus tard.
Contrairement à un ransomware, rien ne s’arrête dans l’entreprise. Les applications continuent de fonctionner. Le seul symptôme visible est financier, et il apparaît en fin de cycle de facturation, quand le mal est fait.
Où les clés API d’IA fuient en PME
Dans une PME, les clés d’IA sont rarement gérées comme des secrets critiques. Elles ont été créées par un développeur, un prestataire ou un collaborateur curieux, pour un prototype qui est parfois passé en production sans que personne ne le décide vraiment. On les retrouve typiquement à trois endroits.
Dans le code et les dépôts
Une clé copiée dans un fichier de configuration, puis poussée sur GitHub ou GitLab, est repérée par des robots en quelques minutes. Les assistants de code aggravent le phénomène : ils écrivent volontiers la clé en dur pour « faire marcher » un exemple, et l’utilisateur pressé valide sans relire. Nous avons détaillé les méthodes de détection dans notre article sur les secrets exposés sur GitHub.
Chez vos fournisseurs et hébergeurs
C’est la leçon de l’affaire Railway : les attaquants ont exploité une faille d’isolation de la chaîne de build, puis une relation de confiance mal configurée, pour obtenir de quoi déchiffrer les variables d’environnement des clients. Selon BleepingComputer, les jetons de comptes liés de 1 852 utilisateurs ont été exposés, dont des jetons OAuth GitHub et des clés d’agents IA. Votre clé était peut-être bien protégée de votre côté ; elle ne l’était plus chez l’hébergeur.
Dans les outils no-code et sur les postes de travail
Automatisations, extensions de navigateur, plugins d’IDE, fichiers .env sur un portable : chaque outil auquel on confie une clé devient un point de fuite. Un poste infecté par un voleur d’informations (infostealer) exfiltre ces fichiers en même temps que les mots de passe enregistrés dans le navigateur.
Pourquoi une facture IA est un risque de trésorerie
La plupart des comptes API d’IA fonctionnent en paiement à l’usage, avec une carte bancaire enregistrée et, souvent, une recharge automatique. Sans plafond configuré, la limite réelle est celle du fournisseur, pas la vôtre. Les modèles les plus puissants coûtent cher par requête, et un proxy de revente peut envoyer des milliers de requêtes par heure, de jour comme de nuit.
Deux éléments rendent le problème plus délicat pour une PME :
- personne ne regarde la console : le compte a été ouvert par un développeur, la facture part en note de frais ou sur une carte d’entreprise, et la direction financière ne voit qu’un montant agrégé en fin de mois ;
- le remboursement n’est pas garanti : les fournisseurs examinent les demandes au cas par cas. Railway a d’ailleurs annoncé qu’il couvrirait lui-même les frais que les fournisseurs refuseraient de rembourser, ce qui montre que le refus reste une hypothèse sérieuse.
Le référentiel OWASP pour les applications LLM classe ce risque sous « consommation non bornée » (LLM10) : l’absence de limites sur l’usage d’un modèle expose à la fois à l’indisponibilité du service et à ce que l’on appelle le « déni de portefeuille ».
Que faire maintenant
- Inventoriez tous les comptes API d’IA de l’entreprise (fournisseur, propriétaire, carte de paiement associée) et rattachez-les à une adresse générique plutôt qu’à une personne.
- Configurez un plafond de dépense mensuel et des alertes de consommation sur chaque compte, comme le permettent les consoles Anthropic et OpenAI, et désactivez la recharge automatique si elle n’est pas indispensable.
- Remplacez les clés uniques partagées par une clé par projet et par environnement, avec les droits minimaux, afin de pouvoir en révoquer une sans tout casser.
- Révoquez et régénérez immédiatement toute clé confiée à un hébergeur ou à un prestataire qui annonce un incident, même s’il affirme que vos données n’ont pas été consultées.
- Surveillez la consommation comme un indicateur de sécurité : un pic nocturne, un modèle inhabituel ou une nouvelle région d’appel doivent déclencher une alerte et une vérification.
Vos agents IA ou vos applications LLM manipulent des clés à forte valeur ? AIGIL sécurise les agents IA et le code LLM, en production comme en CI/CD.
Une passerelle entre vos applications et les modèles
Au-delà de l’hygiène des clés, la mesure structurante consiste à ne plus distribuer les clés des fournisseurs aux applications. Une passerelle interne (proxy LLM) détient la seule clé réelle, applique des quotas par application et par utilisateur, journalise chaque appel et coupe le trafic en cas d’anomalie. Les applications ne reçoivent qu’un jeton interne, révocable et sans valeur à l’extérieur de votre réseau.
Ce composant doit lui-même être maintenu à jour et isolé : une passerelle vulnérable concentre toutes les clés au même endroit, comme nous l’avions vu avec la faille LiteLLM. Il reste pourtant bien plus simple de surveiller et de durcir un point d’accès unique que des dizaines de clés dispersées dans le code, les outils et les postes.
Enfin, intégrez les fournisseurs d’IA et les hébergeurs de vos applications dans votre suivi des fournisseurs : qui détient vos clés, comment sont-elles chiffrées, et sous quel délai serez-vous prévenu en cas d’incident ? Ces trois questions suffisent souvent à révéler des angles morts que personne n’avait identifiés.
Ce qu’il faut retenir
- Le LLMjacking transforme une clé API d’IA volée en facture, souvent découverte trop tard.
- Les clés fuient autant chez les hébergeurs et prestataires que dans votre propre code.
- Un plafond de dépense et des alertes de consommation sont la protection la moins chère.
- Une clé par projet permet de révoquer vite sans interrompre toute l’activité.
- Une passerelle LLM interne centralise quotas, journaux et révocation.